Using Business Decisions to Drive Your Testing Coverage

[article]
Summary:

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.

How to Practically Address Project Decisions

I am starting on a new, small agile project. The ScrumMaster and lead developer are in one location, and a few developers and the tester are in another location across the world. Then there is me, the test manager, and the shadow of a test plan. The Scrum board is up with three columns: “In sprint,” “In progress,” and “Done.” Sprint 1 is nearly done and sprint 2 is picking up steam when management says, “Go, go, go—before Christmas!”

One of the first project decisions I addressed was the definition of done. In this context, we have promised that done includes “reviewed,” “ready for test,” and “tested.” Defects and change requests move across the Scrum board in the same way. So I approached the ScrumMaster, and we discussed how the tool could be used to provide the information to support this decision. This might seem elementary, but without it, the customer wouldn’t know a thing about the stories. More subtly, we can now show this to the customers at end-of-sprint. The checkboxes and note fields all build up to informing both management and customers, and thereby increasing decision coverage.

In this context it’s a business decision to approve the test plan. We have some constraints on budget, staff location, and shipment date that we need to balance while still building good-quality software. One of my suggestions will be to focus on the whole team approach:

  • Developers adding unit test case headlines to the story
  • Testers adding test case headlines to the story
  • QA adding reviews to the story
  • Another team member adding requirement trace to the story

The customer’s business is to process cases efficiently, so in the end, they want a case-handling tool. This will be turned into requirements, user stories, project request, and, finally, an agile project with demos and a “go live” in the end. But before that business decision is made, IT operations wants to know how the new solution will affect the existing operational agreements. Let’s see how we can test that. . . .

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.