The post A Context-Driven Approach to Automation in Testing appeared first on Rapid Software Testing.

Why? Part of the reason is surely that many projects are flying blind, without sufficient awareness of the status of the product and the problems in it. And why is that? Part of the reason is that the craft of testing is stuck in ideas that were out of date 30 years ago, and are even more out of date today.

Want to reframe your ways of thinking about the craft? Join Michael for a whirlwind tour through some of the principles and tactics of Rapid Software Testing.  Here’s Michael Bolton’s talk for Quality Jam 2017

Rapid Software Testing (RST) is an approach to software testing developed by James Bach and Michael Bolton. The approach is targeted towards the fastest, least expensive testing that still completely fulfills testing’s mission — to reveal the status of the product through critical thinking, exploration, and experimentation. While process models, artifacts, and tools have roles to play, RST puts the mindset and the skill set of the individual software tester at the center of testing work.

Despite the name, Rapid Software Testing isn’t just testing with a speed or sense of urgency; it’s mission-focused testing that eliminates unnecessary work, tells the story of the product, and constantly asks what testing can do to help speed the project as a whole—no matter what the development model might be.

The post A Ridiculously Rapid Introduction to Rapid Software Testing (video) appeared first on Rapid Software Testing.

The post How to Evolve a Context-Driven Test Plan appeared first on Rapid Software Testing.

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.

The post Is RST compatible with our context? appeared first on Rapid Software Testing.

A skilled tester should be able do that at any stage—as soon as there’s something to test—with any kind of product, whether it’s a compiled program, a component, a function, source code, a specification, a requirements document, a feature idea, a model, a diagram… Any of these products may have observable, describable problems associated with them.

https://www.developsense.com/blog/2015/09/oracles-from-the-inside-out/

The post Oracles from the Inside Out appeared first on Rapid Software Testing.

https://www.satisfice.com/download/rst-appendices

The post RST Appendices appeared first on Rapid Software Testing.