Rapid Software Testing Archives — 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.