Common search engine questions about testing #4: “How is software testing done?”

This is the fourth of a ten-part blog series in which I will answer some of the most common questions asked about software testing, according to search engine autocomplete results (thanks to Answer The Public).

In this post, I ponder the question “How is software testing done?” (and the related questions, “What are software testing methodologies?”, “What is the software testing life cycle?” and “What is the software testing process?”).

There are many different ways in which software testing is performed, by different people in different organizations with different ideas about what constitutes “good testing”. Don’t be fooled into believing there is “one way” to do testing! There is certainly no single, approved, credible and official way to perform testing – and this is actually a good thing, in my opinion.

So, the question should perhaps be “How might software testing be done?” and, in answering this question, the idea of context is paramount. James Bach defines “context” (in Context-Driven Methodology) as follows:

When I say “context” I mean the totality of a situation that influences the success or failure of an enterprise.

(and Dictionary.com similarly offers “the set of circumstances or facts that surround a particular event, situation, etc.”) The first principle of Context-Driven Testing says “The value of any practice depends on its context.” The way you would approach the testing of a medical device (where a defect could result in loss of life) is likely quite different to how you would test a website for a local business, for example. The context is different – and the differences are important.

While there may be books or certifications that propose a “testing process” or methodology, you should consider the context of your particular situation to assess whether any of these processes or methodologies have valuable elements to leverage. Remember that testing requires a broad variety of different skills and activities: working with other people, formulating hypotheses, creating & changing strategies, critical thinking & evaluation, finding the right people when you need help, assessing what all this might mean for risk and then finding ways to relate this information in compelling and credible ways. What we need is a way of thinking about testing that is flexible enough to cover such a range of skills and activities across many different contexts.

The following from context-driven-testing.com puts it well, I think:

Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of context-driven testing is project-appropriate application of skill and judgment. The Context-Driven School of testing places this approach to testing within a humanistic social and ethical framework.

Ultimately, context-driven testing is about doing the best we can with what we get. Rather than trying to apply “best practices,” we accept that very different practices (even different definitions of common testing terms) will work best under different circumstances.

Bearing the above in mind, the only software testing methodology that I feel comfortable to recommend is Rapid Software Testing (RST) developed by James Bach and Michael Bolton. RST isn’t a prescriptive process but rather a way to understand testing with a focus on context and people:

[RST] is a responsible approach to software testing, centered around people who do testing and people who need it done. It is a methodology (in the sense of “a system of methods”) that embraces tools (aka “automation”) but emphasizes the role of skilled technical personnel who guide and drive the process.

Rather than being a set of templates and rules, RST is a mindset and a skill set. It is a way to understand testing; it is a set of things a tester knows how to do; and it includes approaches to effective leadership in testing.

https://rapid-software-testing.com/about-rapid-software-testing/

RST is therefore quite different from some of the prevalent processes/methodologies that you might come across in searching for resources to answer the question of how testing is done, such as ISTQB and TMap. These systems are often referred to as “factory-style testing” and an excellent summary of how RST differs from these can be found at https://www.satisfice.com/download/how-rst-is-different-from-factory-style-testing

Given how different your context and testing mission is likely to be on different projects in different organizations at different times for different customers, the way “testing is done” necessarily needs to be flexible and adaptable enough to respect these very different situations. Any formal process or methodology that seeks to prescribe how to test is likely to be sub-optimal in your particular context, so I suggest adopting something like the mindset proposed by RST and adapting your approach to testing to suit your context.

You can find the first three parts of this blog series at:

• Why is software testing important?,
• How does software testing impact software quality? and
• When should software testing activities start?

I’m providing the content in this blog series as part of the “not just for profit” approach of my consultancy business, Dr Lee Consulting. If the way I’m writing about testing resonates with you and you’re looking for help with the testing & quality practices in your organisation, please get in touch and we can discuss whether I’m the right fit for you.

Thanks again to my patient and dependable review team (Paul Seaman and Ky) for their helpful feedback on this post.

Advertisement