Quality of Testing Vs. Quantity of Testing
A lesson I learned from working in many projects as a tester or testing team leader is to focus on the quality of testing rather than the quantity of testing. It is a big mistake to measure testing effort and whether testing is good or bad by looking only to the number of test cases, number of issues found, number of testing hours or number of testers. Consider the following scenarios:
- Writing too many but incorrect test cases.
- Missing many valid issues.
- Overwork testing team all days and nights (including weekends).
- Involving all project team in test conduction (even non testers).
All the above scenarios are about quantity. Therefore, they will not lead to a high quality software. However, what if we focus on quality in each scenario to become like this:
- Writing less number but correct test cases.
- Finding valid issues.
- Giving testers the rest they need.
- Involving only testers in test conduction.
Sure the above quality scenarios are much more beneficial and will lead into developing high quality software.
All the best…
3 Comments
ahmad
about 9 years agoThank you
ReplyAnwar Bosbool
about 9 years agoYou are welcome Ahmad.
ReplyBernard Homès
about 9 years agoAgreed, what you need to focus is on somethong which is of value to the stakeholders, such as requirements covered. In fact test cases (i.e. passed, failed or skipped) should not be reported at all to most stakeholders. It only tends to prove that your test team has worked. What is really useful to report are things such as: - whether a defect is closed (and the time it took to close it), - how many bugs have been opened/closed per period of time, - how many requirements have been covered and proven tested correctly, - how much testing still needs to be done (based on the rate of requirements coverage), and how much will it cost, - what has affected the testing (late delivery by development, bad quality of deliverables, incorrect test environment, etc.), - ... to name but a few.
Reply