RST is a context-driven methodology. This means the our classes are not specifically about testing in an Agile, DevOps, Lean, Waterfall, or regulated context; nor does it incorporate any specific testing tool you might use to simulate users or support any other aspect of testing. But we do help you apply these things in testing by putting you in control of the process, so that you solve the problems that actually exist in your context.
The key issue is responsibility. As a tester, responsibility means making independent professional judgments to apply practices and tools to uncover every important problem on your particular project. Responsibility means doing deep testing when project and product risk warrant it. Applying some practice such as “unit testing” or “behavior-driven development” responsibly means choosing it when it fits your context, and not because you heard that Facebook and Google do it, or because you are ordered to do it. Using automation responsibly includes considering approaches outside of automation when they are more effective, more efficient, or when they address problems that automation ignores. Responsibility means that when you say “probably nothing will go badly wrong” you are not just guessing.
RST does not tell you what to do. It is instead a framework for responsible and literate consideration of what to do. The instructors of RST have 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 methodology is not compatible with: fake testing. Yes, there are some organizations that maximize paperwork on purpose and encourage shallow test scripts that they know rarely find bugs. “Factory-style” testing often amounts to fake testing, because it looks reasonable on its face, despite failing to achieve its apparent purpose. Some companies—large testing outsourcing companies are famous for this—even do that is a business model to maximize billable hours. 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 an RST class. It will cause you to ask uncomfortable questions.
Here are some additional details about how RST compares to some other popular methodologies of testing out there.
