Meet Rapid Software Testing

Rapid Software Testing is a testing methodology defined by James Bach, Michael Bolton, and Paul Holland. This methodology focuses on the skillset and experience of the tester alongside with some rules and techniques to achieve a cost efficient quality assessment of a product. It is based on heuristics, fallible methods of solving a problem of making a decision. That’s the main reason why the methodology empowers the tester, which is the one deciding how and when to use the heuristics. It also focuses on the story of the testing journey, giving as much importance to explaining how the test was, what has been found and what is missing to verify than the test itself.

In this video, James Bach briefly explains its details

Personally, I agree with most of the ideas from RST. I truly believe the future of the industry would be empowering testers as high skilled professionals, and relying on automation for the most repetitive, tedious and error prone tasks. Some ideas resonate with the Quality Assistance approach as well (although it relies on teaching the developers how to be a great tester, so it can get feedback sooner).

I also find Exploratory Testing as one of the most challenging intellectual activities I’ve ever practiced. It allows me to use my knowledge of the product, the technologies involved, how the team works and my guts to dive deep in a product and get a story about the current state of its Quality. Its heuristic techniques and tips have enhanced my exploratory testing exercises, as well as making me realize some potential scenarios while developing automated verifications.

There is a lot of documentation online about this methodology (way more than we can tackle in one blog post), so I’ll try to follow up the subject on following entries. It is going to be a subjective interpretation, what I’ve learned from it and how I apply it. Feel free to use the following resources to learn about it, although it heavily relies on practice so I encourage you to give it a go. Luckily, you don’t have to change neither the process or the technologies, so you won’t need any management approval to start applying this methodology!

I want to finish with some quotes from James Bach about Software testing, life, and everything else.

“In general it can vastly simplify testing if we focus on whether the product has a problem that matters, rather than whether the product merely satisfies all relevant standards”

“That’s what training testers is all about. Not only have these ideas, but to explain and defend these ideas.”

“A lot of people think ‘Oh testing is all repetition’. It is kinda like sex, if it’s not fun, you’re not doing it right. You’re doing it wrong. If you approach testing not as the most challenging intellectual exercise you’ve ever done in your life, you don’t understand testing. Because that’s what it is.”

I hope you’ve found this as interesting as I do, and rest assured that I’ll dig deeper on the subject. That’s the best way to force myself to summarize the information I know, and it is an invaluable way to gather some precious documentation for the future.