James Bach, co-author of the Rapid Software Testing (RST) methodology, recently spoke with SD Times about the practice, what benefits can be derived from it, and how organizations can adopt it for their own use.
SD Times: What is Rapid Software Testing?
James Bach: Rapid Software Testing is a methodology for the responsible testing of software. But it is not the kind of methodology that comes encased in rules and templates. It is rather a mind-set (a way of thinking, an ethics, and an ontology of testing) and a skill set
(things that you know how to do, such as performing a heuristic risk analysis.)
What sets Rapid Software Testing apart from other testing methodologies?
RST is humanist. It focuses on people who do testing (whether or not they are full-time testers) and the mission they pursue. It puts the tester in complete control of the testing process. Other methodologies focus on artifacts. For us, artifacts are a side effect of being a responsible tester.
A tester practicing RST is always ready to explain, defend, and otherwise be fully accountable for his work. That’s a big part of this methodology, whereas it seems to me that most testers using other methodologies have no idea how to respond to criticism of the practices they follow.
RST has a theory of learning built into it. It’s an inherently exploratory approach to testing, based on the tester’s emerging mental model of the product, user, and risks. By contrast, look at the V Model: no learning, there. If you use the V Model for testing you are assumed to already know everything at the start of the project. That’s a fairy tale.
RST is “ownable.” When you practice RST, you are practicing your version of RST, which you can change or extend however you like. Whether your version of RST is “really RST” or not is something that emerges from community discussion.
Having said that, there are heuristic models within RST that inform specific ways of testing and specifically what to test. I think RST is the only testing methodology which explicitly addresses heuristics as well as carving out a specific role for tacit knowledge.
What are the benefits of Rapid Software Testing?
It allows you to test honestly, responsibly, and be accountable for your work. Also, I call it “rapid” mainly because it encourages NOT doing things that waste time. It’s light on paperwork (unless paperwork is really needed). We are skeptical of any practice that is performed just because “some expert said so.”
Are there any tools needed for Rapid Software Testing, or is it more of a process/mindset?
I use all kinds of tools. But there is no specific tools required for it. I suppose the most popular tool we use is a mindmapper.
What sort of organizations or groups would be most well-suited to successfully implement Rapid Software Testing? In other words, is it easier to implement this if an organization already has a certain type of technology or process in place?
Success in RST requires personal and corporate responsibility. In other words: a craftsmanship culture. It also requires the organization to care about testing.
These turn out to be rare situations. Many companies seem happy to have people doing testing who can’t or don’t answer for their work. In many cases, startups really don’t have to care much about testing, so doing it in a shallow fashion with simplistic “unit tests” or other automation seems good enough.
Testing shares the same kind of problem that preventative health care and fire safety professionals have; if there is no huge disaster for a while, people stop putting energy into systems that keep disasters from happening. Testing is very much like insurance. You don’t buy insurance because you want some sort of profit; you buy it because you want to prevent a loss. It’s defensive thinking, and many people in the technology business would rather speculate than be safe and responsible. Thus RST requires a sense of corporate and technical stewardship. Without that culture, why work so hard to be a good tester? Why not write some test cases and call it a day?
Are there any challenges organizations will face when transitioning to Rapid Software Testing? How can they overcome those challenges?
Changing to Rapid Software Testing usually means de-emphasizing and defetishizing artifacts. Stop counting test cases! Stop graphing test cases! Test cases are not the point. Instead, ask “Who is responsible for testing this?” (If the answer is “everyone,” then I predict the truth is that no one is taking responsibility.) Then ask for a test report. The test report must be made ina fashion that bears upon the needs of the business. This brings up another challenge. Although RST is a personal discipline, to implement on a corporate level, it requires corporate leadership. Management must insist on literate test reporting, and that means they must know how to listen to and interpret a test report. So there is management training that will be needed.
How does Rapid Software Testing fit in with the more modern development methodologies that are focused on iterating faster and faster, and which often try to squeeze testing out of the process?
The grumpy dad answer to that is Rapid Software Testing doesn’t fit in with irresponsibility and fantasy logic. I am a tester, so my job is to be honest. The 737 Max is grounded right now and Boeing will suffer billions in losses at least partly because no responsible adult gave the right kind of warning to management. Or maybe they did give it and it was ignored. Why didn’t the right thing happen? Perhaps because they wanted to “fit in” to the reckless plan for fast-track certification. Maybe fitting in is not the most important thing. Agile and DevOps were not created by people who sought to fit in, either.
HOWEVER, while fitting in to unreasonable practices and schedules is not our goal, we believe that the fastest good testing — the kind that would fit in to an aggressive production schedule — rests on skills, tools and testability. The RST answer is to develop all those things. We think this calls for at least SOME fairly sophisticated testing people, rather than enthusiastic part-timers who just write masses of automated test cases and hope for the best.
Modern software development is under the control of people. They can and should do whatever they think is right. RST is a mindset and skillset so that these people can think straight and take responsibility for whatever testing they do.
