In a business setting, software testers have a great challenge: to articulate how they support the business lines. One way to approach this is by addressing the business decisions—and there are plenty around. Use them to drive your testing activities and increase the business decisions being covered by testing.
This is not about coverage or the 100 percent. It’s about the business, as always. In a business setting, software testers have a great challenge: to articulate how they support the business lines in making a business. One way to approach this is by addressing the business decisions—and there are plenty around. Use them to drive your testing activities and increase the business decisions being covered by testing.
One of the most common business decisions supported by testing activities is "go live." For some contexts this will be when all the test cases are passed and all the defects are closed. Agile contexts will focus on when the stories in the sprint are “done-done.” In both delivery models, the “go” decision is not made by the testers, even if there are still outstanding issues and defects they worry about. The testers need to provide information to project management or the steering committee for the final call.
Then, business management makes the call—and sometimes the call confuses the tester. Sometimes it’s even contrary to the tester’s notion of quality, code coverage, and passing criteria. I have experienced a large-scale internal upgrade of the complete enterprise stack being postponed due to risks outside the project. I have seen the best laid testing plans set aside because, to the business, the Christmas sales were seen as more important than the project currently in progress. I have seen service-level agreements determined priority patches being turned down by the customer due to “other business" happening on the preproduction environment. Yes, often “other business” matters more to the business than the actual testing.
What Matters to the Business?
It has nothing to do with branch decisions, decision tree coverage, or the like. Those techniques are mostly useless to management, and at best only a minor part of the testing solution. The business is about making money, making a difference, and solving a business problem. So as part of the solution, we must reframe our testing approach into a business mindset.
Any time there is a business decision to be made, there is an opportunity for testers to provide information. Look through your project delivery model to see where the decision points are. Some are more subtle than others. These questions could be a starting point:
- Are we ready to release the solution?
- Do we comply with the explicit requirements?
- Are we ready to start user acceptance testing with the client?
- Are we on top of things, and is testing on track?
- Is this story done?
- Is this actually a minimum viable product?
- Are we out of encouragement, coffee, and chocolate?
- What are the errors we need to know about before shipping?
What Matters to Testers?
Great software testing focuses on "what if." What happens if I press this button? What issues can we find if we . . . ? What happens if the interfaces are down, the system is updated, or the trash lid is turned 5 degrees? But it is equally important that great software testing is balanced with "does it matter"—who is affected, what is the effect, are there major hiccups—while keeping a keen eye on scope, time, and thoroughness. Focus your second eye on the decisions in the project. List them and find a way to answer them, and from there you can start to reframe your testing toward the business decisions being made, both large and small.