Since there is not enough time and resources to test everything, what should I test?
Almost every software development effort has to answer this question. Many, if not most, leave the answer to chance. Inspections and reviews are often cut short or even eliminated due to time pressures. It is left to the developers to decide what gets unit-tested and how. A set of developers or independent testers decide which functions get tested during the function test. The system testers decide what and how they will test.
If you don’t want to leave your product’s outcome to chance, there is a more disciplined approach that can help. Risk-based testing helps identify which parts of the product have the most influence on the business. It strategizes a plan to maximize the effectiveness of the testing. It makes visible what is and is not being tested and what the potential risk is for each important aspect of the product. In short, it better enables a project team to make informed decisions.
Risk-based testing does not impose any specific testing methodologies or techniques. It is merely a guide to help decide and make visible what gets tested, how much it gets tested, when it gets tested, and what the associated risk is. It will help you understand what impacts any last minute changes to the test schedule may have on your project risk.
Risk-based testing doesn’t need to be complex or burdensome. For the most part, it is practical, intuitive and straightforward.
It is not intended for everyone. The less disciplined and mature processes will get much less good out of it than projects that employ and track specific test techniques and stages. It is a poor choice if you really don’t want to make your strengths and weaknesses visible. For those that want to get the most out of their testing and are willing to employ a little discipline, here are the steps that will help you accomplish that:
1. Identify each important component of the system.
2. Determine relative importance of each component.
3. Determine the risk assessment for each component.
4. Identify quality characteristics for the product.
5. Determine relative importance of quality characteristics for each component.
6. Identify list of potential test activities.
7. Determine testing depth by test activities for each component and quality characteristic.
8. Indicate test techniques used by each test activity.
9. Assign responsible parties/owners for each test activity.
10. Indicate expected “risk after mitigation”.
11. Re-determine “risk after mitigation” for any in-process changes to tests and schedules.
No individual should be doing this process alone. Input is required from the customer, test, development, marketing, management, and all other parties involved in the development and use of the system. It may be necessary for an individual to put together some initial information which can then be used by the group as a starting point for discussions, negotiations, and a work in progress that can be refined to its final form.
If you found this post helpful, you may be interested in my Mastering Business Analysis course. Among many other subjects, risk-based testing is covered in detail in the course. Click here to get more information on what is covered in this program.