Rapid Software Testing Training

Rapid Software Testing (RST) is a context-driven methodology for testing any product that includes or involves complex logic (which generally means software). Through interactive discussion and hands-on activities, we challenge assumptions and expose common misconceptions about testing practices. Then we show you a clear and powerful way to think about testing (using heuristic models) that allows you to test responsibly and systematically, so that you focus on business risk and do the deep testing that your project needs.

  • Works for any part of the industry. The RST methodology has been applied to regulated medical devices and government agencies, as well as video game companies and Silicon Valley startups. It’s also been applied to embedded systems and the Internet of Things. The methodology is not tied to any one industrial context.
  • Works for all team members. Although the material has a technical slant, we show how people with almost any educational background can contribute to excellent testing. We use open-ended exercises, so both experienced testers and new testers find the class a rewarding experience.
  • Works for testing specialists or part-timers. The class focuses on testing skills that are applicable to testing specialists as well as developers, designers, business analysts, product owners or domain experts who may perform roles other than testing.
  • Compatible with Agile, DevOps, or even Waterfall. We focus on universal skills and heuristics of test design and test strategy— which apply to any type of development process you may be using. And because the class is context-driven, we help you determine what testing practices are right for your company, rather than imposing “one best way.”
  • Compatible with automation. While we say that testing cannot be automated, we also say that testing benefits through the proper application of many different kinds of tools, including those that simulate users and perform automatic checks.
  • Taught with integrity. Because our classes are only taught by people who control the methodology, you are getting the training directly from the source. Our instructors don’t just read slides, but rather tell stories and answer questions based on original thought and experience. We are fully answerable for what we teach.
  • Join the community. Attendees of RST qualify to join the RST Slack workspace, where students can interact and ask questions of the instructors. We do what we can to make the lessons of the class work for you.

What Our Training Is Trying To Achieve
Most of our training is focused on tactical software testing. Thus, our primary goal is to help you learn how to test a product when you have to test it right now, under conditions of uncertainty, in a way that stands up to scrutiny. It’s about how to find bad bugs before it’s too late.

A secondary goal is to help you think and talk like a testing expert, so that you can proceed with confidence and 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 few days of training. What we can do in the time available is expose you to certain realities about the complexity of software, 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.

The Origins of RST
RST was founded in response to the same challenges addressed by Agile software development. Through the 1990s, talk about development and testing was dominated by heavyweight approaches to process modeling and documentation, oriented towards large enterprises and testing consultancies. The revolution in software development, originating in Silicon Valley, showed that there were other ways to respond to the needs of businesses and organizations who needed software developed and tested quickly.

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 his training 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 training material, 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 RST methodology. Over the years, he helped to refine it, 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 a human 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.

Our classes are 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 experiences.

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

What We Mean By “Rapid”
We aren’t talking about typing or clicking faster. It’s about applying the tester’s mindset and skill set to solve testing problems better while you’re under pressure. This means basically five things:

  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. 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.
Who Should Take This Training
Rapid Software Testing is for you if you take testing seriously and want to have pride in your work.

  • If you are new to testing, we will show you the true basics of testing and provide exercises that help you discover your testing talents.
  • If you are an experienced tester, we 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 or coach 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, we 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.
What Our Training Is Compatible With
RST is a context-driven methodology. This means the our training is not specifically about testing in an Agile, DevOps, Lean, Waterfall, or regulated context; nor do we cover any one testing tool you might use to simulate users or support any other aspect of testing. But we do help you incorporate these things into testing by putting you in control of the process, so that you solve the problems that actually exist in your context.

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 any of our classes. It will make you harder to control.

What Specific Classes Do We Offer
All the classes we offer are variants or follow-ons to the main RST class:

  • Rapid Software Testing Foundation (RSTF) also known simply as RST, Rapid Software Testing Foundation is the original class that teaches the RST methodology. It is a three-day event taught in a classroom (no online version). It walks through the core skills and heuristics of RST.
  • 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) presents the mechanics of  focuses more of the mechanics of managing 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.
How Students Should Prepare What Students Should Bring
Bring a computer. You will be doing testing.

Reports from Students

Jari Laakso (Tester, Manager)
“James is the toughest teacher I have ever seen and the better you do, the more he will push you. This is because he wants you to learn… He has incredible skills to read people and activate their minds. Getting an answer from him is sometimes difficult, but if you are persistent enough, he will make you answer your own question! Like I noted earlier, this training gives you much more than you will ever imagine. You will understand event reporting on a whole new level after the course.”

Bill Matthews (Testing Consultant)
“I’ve attended a number of training courses and learning events over the years but, to date, the Rapid Software Testing course is the only one that utilises Socratic teaching methods and for many attending this course this was the first time they had encountered this teaching method…”

Noel Wurst (Sr. Manager Influencer Relations/Corp. Communications at Tricentis)
“Our initial responses to the confusing and uncomfortable exercises given on Day 1 were to often stare unproductively at our screens, hoping something would come to us. But, on Day 2 and 3, when these exercises had grown even more confusing and complex, this silent uneasiness had vanished. We eagerly embraced that confusion by asking great questions to learn more about the application and its users. We sought out the ideas of others in the room, and we formed groups made up of numerous skillsets and backgrounds.”

Kevin McKay (Senior Software Tester)
“If you participate in this course, don’t expect to sit back and have knowledge poured into you as this is truly an interactive learning experience. You will be challenged by puzzles, questioned on what you think you know and on what you know you know and be surprised at the answer(s). You may even see a little magic happen!”