A secondary goal is to help you think and talk like a testing expert, so that you can gain the credibility you need to be allowed to do your job without interference.
Of course, we can’t achieve these goals just by immersing you in a three-day class. What we can do in the time available is show you how to think about testing, show you what the necessary testing skills look like, and help you to continue building those skills when you go back to work.
RST was created originally by James Bach, based on his experiences at Apple Computer and other Silicon Valley technology companies during the 80’s and 90’s. The first version of the class was called Market-Driven Software Testing, in 1995. James then created a class on risk-based testing, as well as the industry’s first exploratory testing class. In 2001, he combined these classes and formalized the methodology, renaming it to Rapid Software Testing.
In 2004, Michael Bolton brought his experience as a developer, tester, documenter, and program manager to the class, adding new exercises, puzzles, and themes. Michael’s work in commercial and financial services software added and influenced ideas on the role of formality and documentation, and in 2006 he became a co-author of the class and the methodology. Over the years, he helped to refine RST, sharpening the vocabulary, and introducing the crucial distinction between checking—a part of testing that can in principle be done by machinery—and testing—which requires both the explicit and tacit knowledge of the tester.
Paul Holland (from embedded systems and telecommunications), Huib Schoots (financial services), and Griffin Jones (medical devices and other regulated domains) each brought their ideas, experiences, and teaching styles into the mix. Each one of our instructors benefits from the work of the others, and each teaches his own personal variant of RST.
The class is based on the humanistic and systems thinking approach to engineering and science promoted in the works of Gerald M. Weinberg, Cem Kaner, and Billy Vaughan Koen, as well as sociologist Harry Collins, family therapist Virginia Satir, and Nobel laureates Herbert Simon, Richard Feynman, and Daniel Kahneman. We are not saying that these people endorse RST, but simply that if you admire their work, you will find much that resonates in the Rapid Software Testing methodology and classroom experience.
RST is also based on and related to Lessons Learned in Software Testing: A Context-Driven Approach, by Cem Kaner, James Bach, and Bret Pettichord
- Stop doing things that aren’t helping. Each tester should control his own work and be accountable for it, rather than mindlessly following process models perpetuated by people who are more impressed by paperwork than by the actual process of testing.
- Focus on product risk. One size of testing does not fit all. Do deeper testing where it is needed, and do shallow testing or no testing at all when potential product risk is low.
- Use tools to speed up the work. Testers do not necessarily need to write code, but they do need powerful tools. Whether you create the tools yourself or enlist the help of others, you can apply tools, including automated checking, to all aspects of the testing process
- Explain your testing and its value. When you explain the importance of your testing clearly and quickly with a focus on value, your clients and teammates will perceive that your time is well spent, and therefore rapid.
- Grow your skills so that you can do all of the above. We offer no pill you can swallow that allows you to do these things. But we do show you how to grow your skills, and in what specific directions to grow them. By developing judgment and a wide knowledge of different techniques, tools, and processes, you can choose a fast way to test that still addresses all the business needs.
- If you are new to testing, RST will show you the true basics of testing and provide exercises that help you discover your testing talents.
- If you are an experienced tester, RST will help you put words to the tacit skills you have gained over time and provide exercises that help you refine them. You will appreciate that RST is a practitioner-centered methodology– you are in control of it.
- If you are a technical tester, you will learn how your technical knowledge and ability to write code can supercharge the testing process.
- If you are a developer who does some testing, your deep knowledge of product internals is both a crucial resource and a potential liability. You’ll learn how to improve the intrinsic testability of the product and how to manage your biases.
- If you manage people who test, you have the power to steer them and create an environment to help them do their most effective work. You will learn what good testing looks like, how to judge the progress of testing, and how to set high, yet reasonable expectations for the testing process.
- If you are a domain expert who does some testing, RST will help you apply your deep knowledge of how the product is used and who uses it. You’ll learn how to find better bugs during acceptance testing—and help others do it too.
- If you work with people who test, you will gain an appreciation for the challenges of testing, discover how you can support the testing process, and learn what good testing can do for you.
The instructors have the experience with a wide range of contexts, and can help you customize the material to fit your needs. So, we have lots of ideas for how to apply automation to testing, or how to test well in a documentation-heavy project.
There is one thing in particular that RST is not compatible with: fake testing. Yes, there are some organizations that maximize paperwork and shallow test scripts that rarely find bugs. We call this approach “factory-style” testing. Some—like large test outsourcing companies—even do that as a business model. Such companies don’t want to test more efficiently, because that would reduce their billable hours. They want to look productive to people who don’t understand deep testing. If you work for such a company, your boss will be very annoyed with you if you attend RST. It will make you harder to control.
- What is testing and how it must fit the project context
- How mental models and critical thinking form the basis of all testing
- How to deal with overwhelming complexity or confusion
- How to recognize problems despite ambiguous or missing specifications
- How to survey a product to prepare for deep testing
- How to create tests: heuristics, risks, procedures, coverage, oracles
- How tools help magnify and manage testing
- How to know when you’ve tested enough
- How to analyze test results and report evidence in a compelling way
- The Heuristic Test Strategy Model and many other specific heuristics for testing
- Testability advocacy
- Bug reporting and advocacy
- Concise test documentation
- Session-based test management
- Ways to evaluate testing
- How to talk to management about testing
- Test coaching and facilitation
- Testing in a regulatory environment
- Testing in production
- Test data generation and combinatorial testing
- Rapid Software Testing Applied (RSTA) focuses less on the explaining and demonstrating the concepts and skills of RST, and more on experiencing the core elements of it. RSTA includes long exercises where you will test part of a real product, followed by debriefings. The class is taught in an online format (nine webinars over three days) or in a classroom 2-day or 3-day format. RST is not a prerequisite for RSTA. In fact, the two classes can be taken in either order.
- Rapid Software Testing Management (RSTM) is a free-form class for managers, coaches, and leaders who seek to apply Rapid Software Testing methodology or are otherwise working to improve testing in their organizations. RST is ideally a prerequisite for RSTM, but this is not a hard and fast requirement.
- Session-Based Test Management (SBTM) is like RSTA but focuses on how to manage testing using test sessions and associated session reports. This is a method of organizing testing, developed by James and Jonathan Bach, which suits organizations that demand metrics or otherwise wish for high accountability in the test process.
But if you want to do something that will give you a special edge in the class, you can review any of these materials…
You can look at our stuff:
- Lessons Learned in Software Testing: A Context-Driven Approach, by Cem Kaner, James Bach, and Bret Pettichord
- Secrets of a Buccaneer-Scholar, by James Bach
- Rapid Software Testing Appendices
- Rapid Software Testing Public Slides
Or try these books that have inspired our work:
- Introduction to General Systems Thinking, by Gerald M. Weinberg
- Perfect Software and Other Illusions, by Gerald M. Weinberg
- Thinking Fast and Slow, by Daniel Kahneman
- Exploring Science, by David Klahr
- Discussion of the Method, by Billy Vaughan Koen
- The Pleasure of Finding Things Out, by Richard Feynman
- The Sciences of the Artificial, by Herbert Simon
Or try these videos:
We use software in the class that runs only on Windows. But as long as enough people bring Windows laptops, we will be okay. We are experimenting with testing things in the Cloud, but Internet access in hotels can be unreliable.