TL;DR
In the previous post, we gave you an exercise on Beizer Testing Levels. We will introduce you to software testing based on the remarkable book, Introduction To Software Testing by Paul Ammann and Jeff Offutt.
How would you explain to the client what is level 2 software testing organization, and what are the disadvantages of that level?
It seems that your development organization process is centered around found bugs. The bug management system is a tester’s central tool, and there is a lot of open bug reports. Some of those are one year old. These are the clues that the primary goal of your test team is to find bugs. Bug pile in the bug management system is an indication that everything that tester submits is a bug. And that way of working clogged your development pipeline. Developers must investigate bugs that are not important in the context of a release. There is no bug severity risk analysis.
What is level 3 software testing organization, and what are the benefits of that level?
In level 3 software testing organization, we think about the risks for our product. Risk is the probability that there will be an event that works against our product value. The value of risk severity is determined by how much product value is affected by this risk. By organizing a test mission using risk analysis output data, we could direct our testing effort so product value risks could be prevented, or if the risk is fulfilled, we have a mitigation plan.
Give an example of a workshop that could help the development team to move towards the level 3 software testing organization. Which workshop would not help?
Risk storming (MoT) is a workshop organized around a board game for risk management. The game has three phases:
- Think about product quality aspects using Test Sphere Cards
- Write on post-it risks related to those quality aspects.
- Use the rest of the Test Sphere Card deck (feelings, heuristics, patterns, techniques) to come up with a test idea that could mitigate those risks.
- The last part is the test plan matrix table. We have a mission (why and which risks) with product coverage and resources (tools and people) used with our test strategy.
