Exploring the Question “What Is It We Understand We Are Testing For?”

Conventionally in Software Test Engineering, we dedicate a lot of time and effort on the front end to determining, organizing, documenting, and communicating how software should be tested. This goes for activities like developing traceability matrices, determining code paths, developing test plans (or test cases) based on outcomes, inputs, and use cases. With approaches that focus on testing as just a task (or collection of tasks), it can be easy to overlook the potential for issues that result in operational churn, creep, delay, rework, or missed opportunities for coverage.

This can also make it a challenge to estimate or track progress accurately, especially when we dedicate additional resources to attempting to redefine or rediscover what additional effort will be needed to get the task completed. Similarly, common "Best practice" approaches and approaches that serve as a response to as many envisioned use cases or failure scenarios as possible often run the risk of similar issues.

There is a simple tool anybody can use to understand better what information we can expect to produce from testing, why that information may be important, and how to direct efforts to satisfying the former as serviceably and efficiently as possible. It looks a lot like engineering on its own: it uses our knowns to discover and demystify our unknowns. It is free and easy to use.

This presentation will focus on the question What is it we understand we are testing for? Using real-world examples, it will outline what makes this question a valuable one to ask and how to use it to develop a better understanding of what our mission in Software Testing is.

• Other