Value added testing (VAT)
- 1. Value Added Testing (VAT)
- 2. Testing is a time boxed effort, just that the time is mostly reduced. Why VAT 1. How often does Client delivery get delayed to accommodate entire Testing time?
- 3. Does Development time ever get reduced? Why VAT 2. Are the Testing estimates untouched / unaltered / utilized completely?
- 4. Test automation is only automating a crude approximation of one aspect of testing. Why VAT 3. Are all internal QA bugs fixed by Development before the delivery?
- 5. If each side of brain can control different types of thinking, why cant each eye handle different tasks that of Maker and Checker? Why VAT 4. Does an untested case get logged by the client and a tested case fails at client site and we are sure that the code is 100% bug free?
- 6. DST : You cant stop time but you can certainly advance it. VAT: You cant test everything, but you can certainly test what is good enough. Why VAT 5. Post-delivery, does the (quality / quantity ) of documentation get questioned frequently and get referred in the future?
- 7. Testers are paid to play with the product Why VAT 6. Does the testing team by itself inform that the estimates are very high for Testing?
- 8. It's a common misconception that a process can only be controlled by documented plans. Why VAT 7. Proportionate amount of testing is completed in the first few days of Testing phase?
- 9. it isn't the number of bugs that matters, it's the effect of each bug Why VAT 8. How often there are no lags in the preceding phases, leading to cascading delay in Testing?
- 10. The world is full of uncertainty, not only the code. Why VAT 9. How often is Testing skipped partially / completely due to exhaustive Programmer testing?
- 11. Apple shipped the first version of HyperCard with about 500 known bugs and Windows 3.1 was shipped with 5000 known bugs! Why VAT 10. Are known defects published to the client?
- 12. Fix a product before it is broken; never introduce a bug. Why VAT If the answer to any of the previous questions is NO,NEVER or SELDOM, there is definitely scope for VAT.
- 13. Every 8th line of code has a chance of picking up a new defect Value Added Testing ( VAT) VAT is to identify and agree how much testing is good enough and test within the available time limit or in a truncated time frame and still deliver the best without a compromise on quality. It requires an unorthodox approach to the entire testing life cycle which questions and validates every single process / sub –process in the testing lifecycle, enhances it further, alters or skips sub-process or the entire process as required by the product / project and also revisits the estimate at intermediate stages to see if there is a possible reduction. In simple terms, VAT is not just good testing; it is good enough testing which would save time and cost to the company in multiple ways.
- 14. Every piece of software is unique, and testing needs to vary dramatically from project to project. A graphical representation
- 15. Choosing the right bugs and right quality to ship with is the key. Could we term it as Sprinkle model? Similarly, we need to “cover” the product with “enough” amount of test cases
- 16. It is impossible to test a program completely How to do VAT Identify Value Added(VA) and NonValue Added(NVA) activities. Eliminate NVA. Situational approach. Decide ALAP, deliver ASAP. Decide how much is “good enough”.
- 17. Testing is a way to measure quality; it is not a remedy by itself. Few illustrations NON-VALUE ADDED Detailed documentation VALUE ADDED Lean/Light weight documentation 4 eyes principle ( for certain tasks) 2 eyes principle ( for certain tasks) Proportionate headcount Realistic headcount Enforced automation Possible automation ASAP / ALAP ALAP / ASAP Conventional Agile / Waterfall Flexible model ( Sprinkle ? ) Test all scenarios Test required scenarios Manager : Subordinate(s) Mentor: Mentee(s)
- 18. Documenting is not testing. It is one of the chief distractions to testing. Documentation Selective documentation. Checklist / Traceability matrix. Light weight video recording tool. Additional test cases. Expedite testing. Lean test documentation.
- 19. Everybody Tests, not just the designated testers. 4 eyes or 2 eyes Need based review. Peer testing ( Unit testing level ) Hybrid unit test cases and test cases. Agreed programming standards.
- 20. Businesses does not want testing. They want systems that work well enough to make money. Sometimes that requires more testing, sometimes less, sometimes none at all. Headcount No project requires fixed number of headcount. More testing does not mean increased quality. Less number of testers would improve the quality of Unit Testing.
- 21. Imagine a bug and find it Automation Testing is a thought process; involves learning and discovery. Automate only whatever is possible. Compliment it with manual testing. Better not to entirely delegate to machines.
- 22. Nothing works all the time ASAP / ALAP Early involvement of testers not always required. Late involvement could save time and rework. Decide as late as possible; Deliver as fast as possible. Need based involvement / Situational practice is crucial
- 23. It is impossible to test a program completely Full / Partial coverage Cannot test everything, test what is good enough. Wanting the product to work in deployment or preventing it from being deployed is the key. Impossible to find all the bugs in the code. Impossible to know whether all bugs are found. Possible to prevent coding errors and have limited coverage.
- 24. ON time delivery is as important as ONE time delivery ( less number of fixes post-delivery ) Mentor : Mentee Brain dump of successful testers is not available. Testing is not clerical activity, it’s a subtle art to be learnt. Mentors are also concerned about mentee development
- 25. True certification of a tester is the respect of respectable people Explaining testing is a big subject… 20% of the code causes 80% of the problem; identify it. Some shortcuts to find killer bugs in initial days: Rule of thumb, Educated guess, Intuitive judgment Common sense. Apply DMAIC
- 26. Testers have to be the Master of messy thinking And finally, an analogy Testing is like marriage. You meet the product (person), try to understand it better, change the test cases according to the requirement, try to validate it day by day and get familiar with it. Problems are either fixed or accepted and tester has fairly reasonable idea how the product will react. The product behaves as expected and the tester lives happily ever after.
- 27. TESTER needs to DEVELOP an eye for detail Thank you, http://www.linkedin.com/in/haridhvar