Rapid Software Testing

What Is Testing? A Conversation with James Bach and Michael Bolton

Mary Alton — Tue, 03 Feb 2026 22:36:10 +0000

Podcasts on Quality Assurance and Testing

In this episode, I [@alexusadays] sat down with James Bach and Michael Bolton to answer a deceptively simple question:
What is testing?

A lot of people still reduce testing to “finding bugs.”
But if you take testing seriously, it’s much bigger than that.

We talk about:
What testing actually is (and what it isn’t)
And a bit about the future of testing

This conversation also helped me refine how I describe testing in my own work and writing. Which resulted with this: “As I see it, testing is more than just finding bugs, it is a process of helping improve product quality, assessing compliance with requirements and regulations, and helping to deliver a product that meets or exceeds user expectations.”

If you’ve ever struggled to explain what testers really do — this episode will give you better words and a sharper model.

YouTube: @alexusadays

The post What Is Testing? A Conversation with James Bach and Michael Bolton appeared first on Rapid Software Testing.

Video Highlights from RST Online Classes

Mary Alton — Sun, 16 Oct 2022 11:55:45 +0000

RST Peer Advisor Marius Francu has created a YouTube playlist of insights from the online RST Explored and RST Applied classes. For those who haven’t yet taken a class, these offer a little taste of some of the lessons that you might learn. For those who have taken the class, they can be helpful reminders of some of the important points.

Go to the RST YouTube Channel

Responding to a Critique of Taking Testing Seriously

Michael Bolton and James Bach respond to Oleksandr Bolzhelarskyi.

https://www.linkedin.com/posts/oleksandr-bolzhelarskyi_ive-finished-reading-taking-testing-seriously-activity-7424284118802354176-nV5E?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAJyE3QBSjMd-wGkGZkMdD7Kj6HO2zB_CI4

Responding to a Critique of Taking Testing Seriously

Michael Bolton and James Bach respond to Oleksandr Bolzhelarskyi. ...

Michael Bolton - Why Take RST Classes?

"Now that there's a book — Taking Testing Seriously: The Rapid ...

How to Report AI-Assisted Work

James and Michael discuss their system for reporting on the status of ...

Technical Work is All About Learning - Conversations on Taking Testing Seriously

In this video, James Bach and Karen N. Johnson are discussing about ...

The Book is Out

So strange when an idea becomes a real thing.

What is Normal? - Conversations on Taking Testing Seriously

In this video, James Bach and Karen N. Johnson read from our soon to ...

On Magic Boxes and Magic - Conversations on Taking Testing Seriously

In this video, James Bach and Michael Bolton read from our soon to be ...

James Christie Conversation regarding Testing and Audits with James Bach and Michael Bolton

"Following the happy path is a foreign concept to good, experienced ...

What Are We Thinking in the Age of AI? And are we still thinking like testers? - Michael Bolton

It’s the topic that’s on everyone’s lips… AI… We’re all aware by now, ...

Testing & Automation in the Age of AI: Hype, Hope, or Headaches - Questions Time - Michael Bolton

It’s the topic that’s on everyone’s lips… AI… We’re all aware by now, ...

Michael Bolton - On testing and testing like a user

#testing #qa #agile #user_testing #rst #context_driven_testing

Conversation #1: Checking, Testing, and Mutation

My son likes to talk to me while we drive. I discover he knows more ...

The post Video Highlights from RST Online Classes appeared first on Rapid Software Testing.

Rapid Testing Guide to Making Good Bug Reports

Mary Alton — Sun, 16 May 2021 02:38:49 +0000

Bug reporting is central to testing. The bug report, whether oral or written, is the single most visible outcome of testing. And the quality of your reports is probably the single most important factor that determines your credibility as a tester. This document describes bug reporting from the perspective of Rapid Software Testing methodology. Throughout this guide I will distinguish between what is expected of “supporting testers” (anyone helping the test effort temporarily or intermittently but not committed to the testing role or perhaps even that project) and “responsible testers” (those who assume the role of tester on a project and commit themselves to doing that job well over time).

https://www.satisfice.com/download/rapid-testing-guide-to-making-good-bug-reports

The post Rapid Testing Guide to Making Good Bug Reports appeared first on Rapid Software Testing.

Investigating Bugs: A Testing Skills Study

Mary Alton — Sun, 16 May 2021 02:30:26 +0000

Back in the year 2000, a company hired me to help them develop a professional testing culture. As part of that process, I found a team of highly regarded testers and studied their approach to bug investigation. Part of what I learned is that the method they told me they were using was not the method they were actually using. The true method was much better, but they didn’t know how to explain it.

https://www.satisfice.com/download/investigating-bugs-a-testing-skills-study

The post Investigating Bugs: A Testing Skills Study appeared first on Rapid Software Testing.

Reframing Requirements Analysis

Mary Alton — Sun, 16 May 2021 02:28:40 +0000

REQUIREMENTS REVISITED In generally accepted software development practice, requirements analysis is supposed to happen before design, and design is supposed to happen before coding and testing. Some kind of document is supposed to come out of requirements analysis. The IEEE 830-1993 Recommended Practice for Software Requirements Specifications includes a list of quality attributes for requirements: correct, complete, unambiguous, consistent, ranked for importance, verifiable, modifiable, and traceable. The specification is supposed to guide the engineering activities that follow. The so-called generally accepted practice, however, isn’t generally practiced.

https://www.satisfice.com/download/1115

The post Reframing Requirements Analysis appeared first on Rapid Software Testing.

Test Framing

Mary Alton — Sun, 16 May 2021 02:16:09 +0000

To test is to tell three parallel stories: a story of the product, a story of our testing, and a story of the quality of our testing. James and I believe that test framing is a key skill that helps us to compose, edit, narrate, and justify the story of our testing in a logical, coherent, and rapid way.

https://www.developsense.com/blog/2010/09/test-framing/

The post Test Framing appeared first on Rapid Software Testing.

Session Based Test Management Report Checklist

Mary Alton — Fri, 14 May 2021 18:47:46 +0000

Test session reports are a part of session-based test management. This is a checklist for helping you make a good test session report.

https://www.satisfice.com/download/sbtm-session-report-checklist

The post Session Based Test Management Report Checklist appeared first on Rapid Software Testing.

Exploratory Testing

Mary Alton — Fri, 14 May 2021 18:45:05 +0000

Do you perform any exploratory testing on APIs? How do you do it?

Here’s an in-depth version of the reply I gave, with the benefit of links to deeper material.

To begin: application programming interfaces (APIs) are means by which we can use software to send commands to a product to make it do something. We do perform some testing on APIs themselves; interfaces represent one set of dimensions or factors or elements of the product. In a deeper sense, we’re not simply testing the APIs; we’re using them to control and observe the product, so that we can learn lots of things about it.

Now, there’s a problem with the first question: it implies that there is some kind of testing that is not exploratory. But all testing is exploratory. The idea that testing isn’t exploratory comes, in part, from a confusion between demonstrating that a product can work and testing to learn how it does work, and how it might not work.

https://www.developsense.com/blog/2018/07/exploratory-testing-on-an-api-part-1/

The post Exploratory Testing appeared first on Rapid Software Testing.

Oracles from the Inside Out

Mary Alton — Fri, 14 May 2021 18:39:54 +0000

In Rapid Testing (and, we believe, in all worthwhile testing) learning about the product and finding problems that matter are central to the mission. In the role of a tester, I support the business and development team by finding and describing things I believe to be important problems that might threaten the value of the product.

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.

Test Cases and Coverage

Mary Alton — Fri, 14 May 2021 18:37:31 +0000

At the beginning of the project, you don’t yet know how to test it. To develop a relevant test strategy, you must learn the product. There may be many ways for you to learn about the product—by attending meetings, talking to people, reviewing project plans, studying designs or sketches. You may even have an opportunity to work with the product directly; with a previous version; with a mockup or prototype; or with a part of the product.

Without a good deal of that learning, you cannot know what test cases should describe or contain—so instead of the typical fine granularity of test cases, consider the broader notion of coverage areas.

https://www.developsense.com/blog/2018/06/test-cases-and-coverage/

The post Test Cases and Coverage appeared first on Rapid Software Testing.

Breaking the Test Case Addiction

Mary Alton — Fri, 14 May 2021 18:33:52 +0000

Testing, as we’ve pointed out (many times), is not test cases; testing is a performance. Testing, as we’ve pointed out, is the process of learning about a product through exploration and experimentation, which includes to some degree questioning, studying, modeling, observation, inference, etc. You don’t need test cases for that.

https://www.developsense.com/blog/2019/01/breaking-the-test-case-addiction-part-1/

The post Breaking the Test Case Addiction appeared first on Rapid Software Testing.

How to Evolve a Context-Driven Test Plan

Mary Alton — Fri, 14 May 2021 18:30:41 +0000

This is a process guide for creating a good test plan within the RST methodology. It consists of seven tasks. The tasks can be performed in any order, or simultaneously and iteratively.

https://www.satisfice.com/download/building-a-context-driven-test-plan

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

Heuristic Test Strategy Model

Mary Alton — Fri, 14 May 2021 18:25:41 +0000

The HTSM (v.5.7.5) is a set of guideword heuristics designed to help you think better about test strategy. It includes four focus areas: test techniques, project elements, product elements, and quality criteria categories. You can use it casually or rigorously. It is pretty generic to any kind of software. I’d encourage you to modify this to fit the context of your own organization.

https://www.satisfice.com/download/heuristic-test-strategy-model

The post Heuristic Test Strategy Model appeared first on Rapid Software Testing.

RST Overview a video with James Bach

Mary Alton — Thu, 13 May 2021 20:53:13 +0000

This video describes the general structure of the Rapid Software Testing methodology.

The post RST Overview a video with James Bach appeared first on Rapid Software Testing.

A Context-Driven Approach to Automation in Testing

Mary Alton — Thu, 13 May 2021 20:22:45 +0000

This is a detailed explanation of how automation helps us in software testing. We show that automation can do much more than merely simulating a user who is pressing buttons. A downloadable pdf.

https://www.satisfice.com/download/a-context-driven-approach-to-automation-in-testing

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

Elements of Excellent Testing

James Bach — Fri, 19 Mar 2021 01:44:13 +0000

What skills and tactics are important in testing? Where you start in evaluating the quality of a tester’s work, or of a testing team? Here’s a concise list of the skills, dynamics, and work products of excellent testing, created by James Bach, Jonathan Bach, and Michael Bolton.

https://www.satisfice.com/download/elements-of-excellent-testing

The post Elements of Excellent Testing appeared first on Rapid Software Testing.

Telling the Testing Story

Mary Alton — Sat, 27 Feb 2021 03:10:13 +0000

To test is—among many other things—to construct, edit, narrate, and justify a story. A excellent, expert test report has at least three significant elements that weave around each other like a braid: a story about the product; a story about how we’ve tested it; and a story about the quality of the testing work, and what got in the way of it.

https://www.developsense.com/blog/2018/02/how-is-the-testing-going/

The post Telling the Testing Story appeared first on Rapid Software Testing.

Is RST compatible with our context?

Mary Alton — Fri, 26 Feb 2021 23:03:59 +0000

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.

https://www.satisfice.com/download/how-rst-is-different-from-factory-style-testing

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

The RST Methodology

Mary Alton — Fri, 26 Feb 2021 22:57:22 +0000

We call what we do Rapid Software Testing.

About RST

Why do we test? We test to develop a comprehensive understanding of the product and the risks around it. We test to find problems that threaten the value of the product, or that threaten the on-time, successful completion of any kind of development work. We test to help the business, managers, and developers decide whether the product they’ve got is the product they want.

https://www.satisfice.com/rapid-testing-methodology

The post The RST Methodology appeared first on Rapid Software Testing.

A Rapid Testing Framework

Mary Alton — Fri, 26 Feb 2021 22:52:02 +0000

Here’s a narrative roadmap of many elements of RST. At the top are the premises underlying software development and why we test; below is the “activity vortex”, with the tester and heuristic at the eye of the hurricane.

The post A Rapid Testing Framework appeared first on Rapid Software Testing.

A Ridiculously Rapid Introduction to Rapid Software Testing (video)

Mary Alton — Fri, 26 Feb 2021 22:42:23 +0000

Over the years, we’ve seen the introduction of Structured Programming, Total Quality Management, Agile, Scrum, Devops—and after all this time, projects still stumble and products still drive us crazy.

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.

How RST is Different From “Factory-Style” Testing

Mary Alton — Fri, 26 Feb 2021 17:17:34 +0000

This document lays out, in many dimensions, how RST methodology differs from and contradicts the type of testing advocated by the ISTQB, TMAP, and similar systems. In my opinion, which is informed by decades of watching the industry, working in three different testing consultancies, participation in industry standardization efforts, and many hours of debate with other speakers and writers in the field of software testing, is that the ISTQB and its ilk represent the interests of a small group of large consulting companies that want to encourage grossly inefficient and ineffective testing because that is their actual business model.

https://www.satisfice.com/download/how-rst-is-different-from-factory-style-testing

The post How RST is Different From “Factory-Style” Testing appeared first on Rapid Software Testing.

Testing and Checking Refined

Mary Alton — Fri, 26 Feb 2021 17:14:05 +0000

In RST, we make a distinction between testing and checking. We distinguish between the two to keep humans at the centre of testing work. Tools can be enormously helpful to testers, but there’s more to testing than checking the build; and testing is something that only human beings can do.

Testing is the process of evaluating a product by learning about it through experiencing, exploring, and experimenting, which includes to some degree: questioning, study, modeling, observation, inference, etc. A test is an instance of testing.

Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product. A check is an instance of checking.

A check is a specific part of a test that can be done entirely mechanistically. The check (or some set of checks) is that set of behaviours in the middle of a test that the machine can perform: the key-pressing and mouse-clicking and the looking up of desired results.

Behaviour, in the parlance of Harry Collins and Martin Kusch (The Shape of Actions), is essentially observable, describable physical movement over time. An action, Collins and Kusch say, is behaviour plus intention. A check can be expressed in terms of behaviour, but a check is always embedded in a test of some kind. A test is an action.

All the way through a test, both before and after the check, there is intention to find a problem, to probe a risk, or to become alert to some condition. There is also intention in the design of the check, in the encoding of the check, and in decision-making about when to run the check — or checks. Then the checking happens; that’s the part that the machine handles.

The check — the algorithmic, mechanistic procedure — finishes, producing output that we might call a result. But it’s not the result of the test; the test doesn’t end when the check does. For something to qualify as a test, there has to be human evaluation and interpretation of the output. If the outcome was a failure, or “red”, there’s a problem somewhere in the product, or the check, or the environment, or the relationship between them. That problem must be interprested. If the outcome was a “pass”, or green, no problem was flagged by the check—but for the purposes of a test, that outcome must be interpreted and evaluated critically to avoid being fooled by an unreliable check. Are we satisfied that that check is sufficient to address the risk or concern or condition that we want to be aware of? The check doesn’t incorporate that, but the test does. That is, the intentions before and after the check are required for a test.

https://www.satisfice.com/blog/archives/856

The post Testing and Checking Refined appeared first on Rapid Software Testing.

Exploratory Testing 3.0

Mary Alton — Fri, 26 Feb 2021 17:11:13 +0000

In the beginning, there was testing. No one distinguished between exploratory and scripted testing. Jerry Weinberg’s 1961 chapter about testing in his book, Computer Programming Fundamentals, depicted testing as inherently exploratory and expressed caution about formalizing it. He wrote, “It is, of course, difficult to have the machine check how well the program matches the intent of the programmer without giving a great deal of information about that intent. If we had some simple way of presenting that kind of information to the machine for checking, we might just as well have the machine do the coding. Let us not forget that complex logical operations occur through a combination of simple instructions executed by the computer and not by the computer logically deducing or inferring what is desired.”

https://www.satisfice.com/blog/archives/1509

The post Exploratory Testing 3.0 appeared first on Rapid Software Testing.

RST Appendices

Mary Alton — Fri, 26 Feb 2021 17:07:19 +0000

These are the appendices to the Rapid Software Testing Explored class.
This is a downloadable pdf.

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

The post RST Appendices appeared first on Rapid Software Testing.

The Premises of Rapid Software Testing

Mary Alton — Fri, 26 Feb 2021 17:00:13 +0000

A statement of the premises on which Rapid Software Testing—our classes and our methodology—are based.

These are the premises of the Rapid Software Testing methodology. Everything in the methodology derives in some way from this foundation. These premises derive from our experience, study, and discussions over a period of decades.

https://www.developsense.com/blog/2012/09/premises-of-rapid-software-testing-part-1/

https://www.developsense.com/blog/2012/09/premises-of-rapid-software-testing-part-2/

https://www.developsense.com/blog/2012/09/premises-of-rapid-software-testing-part-3/

The post The Premises of Rapid Software Testing appeared first on Rapid Software Testing.