Download to read offline
Uploaded byNurul Miah
19th Annual European Software Testing Conference
The document summarizes Google's testing philosophy which focuses on quality, speed, and value. Some key points are: 1) Testing is integrated into the engineering process and is everyone's responsibility, not just testers. Developers own the quality of their code. 2) The goal is to find and fix bugs early during development rather than just testing for results. An 80% solution today is prioritized over a 100% solution tomorrow. 3) Automated testing is important so results can be checked by machines, freeing up time to focus on decisions that add more value than repetitive tasks. Quality is emphasized over specific results.
More Related Content
![[HCMC STC Jan 2015] Workshop Of Context-Driven Testing In Agile](https://cdn.slidesharecdn.com/ss_thumbnails/nhatdo-vuduongworkshopcontext-driventestinginagile-150208225650-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to 19th Annual European Software Testing Conference
19th Annual European Software Testing Conference
- 1.
- 2. Google is an Quality must be Value in fixing engineering / Test must be part owned by bugs not finding computer science of engineering centric company engineering them (potential)
- 3. Google Testing Philosophy 20%Time Project Mobility Fail Fast
- 4. No human Results canbe judgement or So important it can’t checked by a Repetitive cleverness is be left to chance machine required C++
- 6. Quality Assurance
- 7. To provide feedback Acts as an enabler on progress To inform To learn! stakeholder decisions
- 8. An 80% solutiontoday instead of 100% solution tomorrow. Markets are moving too fast to provide 100% customer solutions.
- 10. Best timeto find bugs is in development Testing is everyone’s job Developers own quality for every piece of code they touch Person writing the code is the person most qualified to do the testing Minimise platform dependencies Python, C++, Java & JavaScript Involve testers throughout development All code should be structured.
- 12. Likelihood Impact Don’t focus on Focus on RESULTS DECISIONS Create Med / Remove causes Low risks
- 17. A - Attributes “Fast” “Secure” “Stable” “Elegant” C - Components “Search” “Database” “Cart” “Printing” C - Capabilities “Database is Secure” “Search is Fast” Framework for Direct you Replace a calculating risk toward missing Fast to write conventional surface map coverage test plan
- 18. Avoid prose infavour of bulleted lists Don’t bother selling No fluff, not a high school paper (A+B=C) Make it flow, one section leads to another If it isn’t actionable, leave it out The outcome should be test cases
- 20.
- 21. Quality Teach 5% Fail Fast Speed! others Assurance Get Tools & Everyone Read Value in Involved Techniques Tests Code Fixing Bugs Early
- 22. ALBERT EINSTEIN
- 23.
Editor's Notes
- #2 19th Annual European Software Testing ConferenceAttended Google tutorial – How Google Tests SoftwareSeveral keynotes / lectures from other speakers
- #3 All of their testers can write code.
- #4 20% - 1 day a week off to do what they want (sleep, learn, shadow)Mobility – Changing projects keeps people freshFail Fast – Failing is good, if we don’t fail fast that means we are not taking big enough risks.
- #5 When to automateNo point in automating if using it once every 3 weeks or longer.
- #7 Quality – fit for purpose and meets user requirementsAssurance – is the delivery of confidenceGarbage in garbage out. If the requirements, coding and other input are bad then the output will be bad
- #8 Enabler – provide information for decisions to be taken (to release, hold, change etc.)Feedback – provide feedback on the progress e.g. stable, 70% test coverage, etc.Learn – about the product, mistakes, processes, etc.
- #9 Fast paced market and specially with the constant TB + IW releases, we need to try and not deliver everything. Lets focus on what will provide the most benefit and get the product out there fast.
- #11 Developers need to take more responsibility when it comes to testing. Their product, they should know the ins and outs.Provide QA with vital information on what they have built, areas to test, programming languages used.
- #13 Likelihood > Impact– The weight of Likelihood should be > 50% – The weight of Impact should be < 50% impactDecisions > Results– It’s the decisions that will determine the outcome of the results.– Making the correct decisions will be important.Med/Low Risks > Causes– If we can remove causes and create med/low risks than this is good.– Inclusion of some features could create high risks, by removing them we can create a low risk / med risk or by changing it.
- #14 Why are we releasing this now?Why don’t we wait until our toolbar is stable?Why do we need to keep releasing almost every month?Why don’t we have proper priorities?Etc.
- #16 Visualising any kind of work is very useful not just to myself but to others within and outside my team.High priority tasks at the topLower tasks low priority / could do (blue)
- #18 A – Attributes (Adjectives) Attributes are ways a marketer would describe your application, such as "Fast" or "Secure". Attributes in the ACC model allow you to map Capabilities to business requirements.C – Components (Nouns) Components are the 'moving parts' of your application. Typically components are core libraries, data sources, parts of the code base, and so on.C – Capabilities (Verbs) Capabilities are what your application actually does; they are just like features, except they are tied to a specific Attribute and Component pair.
- #23 • Rules -> requirements • Every game starts with learning and agreeing on the rules -> every project starts with defining and agreeing on the requirements