Over the last two days, I’ve published the premises of the Rapid Software Testing classes and methodology, as developed by James Bach and me. The first set addresses the nature of Rapid Testing’s engagement with software development—an ambitious activity, performed by fallible humans for other fallible humans, under conditions of uncertainty and time pressure. The second set addresses the nature of testing as an investigative activity focused on understanding the product and discovering problems that threaten its value. Today I present the last three premises, which deal with our relationship to our clients and to quality.
6. We commit to performing credible, cost-effective testing, and we will inform our clients of anything that threatens that commitment. Rapid Software Testing seeks the fastest, least expensive testing that completely fulfills the mission of testing. We should not suggest million dollar testing when ten dollar testing will do the job.
It’s not enough that we test well; we must test well given the limitations of the project. Furthermore, when we are under constraints that may prevent us from doing a good job, testers must work with the client to resolve those problems. Whatever we do, we must be ready to justify and explain it.
7. We will not knowingly or negligently mislead our clients and colleagues. This ethical premise drives a lot of the structure of Rapid Software Testing. Testers are frequently the target of well-meaning but unreasonable or ignorant requests by their clients. We may be asked to suppress bad news, to create test documentation that we have no intention of using, or to produce invalid metrics to measure progress.
We must politely but firmly resist such requests unless, in our judgment, they serve the better interests of our clients. At minimum we must advise our clients of the impact of any task or mode of working that prevents us from testing, or creates a false impression of the testing.
8. Testers accept responsibility for the quality of their work, although they cannot control the quality of the product. Testing requires many interlocking skills. Testing is an engineering activity requiring considerable design work to conceive and perform. Like many other highly cognitive jobs, such as investigative reporting, piloting an airplane, or programming, it is difficult for anyone not actually doing the work to supervise it effectively. Therefore, testers must not abdicate responsibility for the quality of their own work.
By the same token, we cannot accept responsibility for the quality of the product itself, since it is not within our span of control. Only programmers and their management control that.
Sometimes testing is called “QA.” If so, we choose to think of it as quality assistance (an idea due to Cem Kaner) or quality awareness, rather than quality assurance.
[…] Premises of Rapid Software Testing, Part 3 (Developsense Blog) […]
Very good posts.
I do want to question the use of the word control in point 8 “Only programmers and their management control that.” (QA)
I don’t want to free programmers of the responsibility they have for the work they produce. But they may not always control the quality of it as this would lie with management again. Point 8 should read as well “Progammers accept responsibility for the quality of their work, although they cannot control the quality of the product”.
Michael replies: I accept that programmers can’t control everything about that product, but they certainly have have some level control over the code and the design. Their work is in the product. In a funny kind of way, our best work as testers is invisible in the product—we helped to get the bad stuff found and taken out.
Having said that, I’ve seen that where control really lies is often uncertain. Some Managers don’t understand software engineering well enough to take on this control so it /does/ sit with Programmers. My point is that it sits in context of the company that produces software. Where the control of quality actually sits with and if there is actually control at all is questionable. In my book Control is a gliding slide, same as quality and is a relationship between people, processes and ideas.
Those things may be true, but that’s not the point of our statement. The point is that as testers, we don’t have control; we are faithful extensions of the senses of people who do.
Thanks for sharing as always MB.
Looking forward to the publication of these. It will join other valuable documents of yours and JB’s as I journey through various clients.
[…] Premises of Rapid Software Testing, Part 3 Written by: Michael Bolton […]
“…As testers, we don’t have control; we are faithful extensions of the senses of people who do.”
This is one of the best definitions of what a tester role is about, this is for keeps. Thank you.
Do you remember what article / publication Cem brought forth the idea of QA as quality assistance?
Michael replies: I’m not sure if it’s the earliest citation, but here’s a certain one: The Ongoing Revolution in Software Testing.
I like the premise of providing cost-effective testing but how do you make that argument? RST is the least-expensive testing when compared to the way most companies test?
Probably not. The least expensive testing is no testing at all.
No one can gave a guarantee—we certainly can’t—because there’s no way provide a counterfactual history with any certainty. We can offer a good-faith effort, though. When we see alternative ways of obtaining information, we lean towards the less expensive, the faster, the informal and the more immediate (that is, not just faster, but without mediation, direct). One dominating reason for this: we think it’s a generally a bad idea to commit to a particular formal approach until informal approaches have suggested which formal approach is most appropriate, if indeed a formal approach is necessary at all. We think that it’s generally a bad idea to commit to a particular expensive tool until we’ve tried an inexpensive tool (or no tool at all) to tell us whether the expensive tool is warranted. We think it’s generally a bad idea to commit to a mediated observation when direct observation will do the trick, and we think it’s a bad idea to test slowly until quick testing has suggested where careful testing is necessary.
In our Rapid Software Testing class, James Bach and I talk about quick tests. The course notes are available for free. Fire up Acrobat and search for “Quick Tests”.
Chapter 16 (“Testing without Machinery”) from Jerry Weinberg’s Perfect Software and Other Illusions About Testing is another wonderful example of the kind of approach we believe in.
Chris
Old post, I know.
I usually go with QA = Quality Assessment:
Assess: Verb – To evaluate or estimate the nature of.
What is testing if not assessment?
If you think of testing as quality assessment, I’d be inclined to agree. It’s the quality assurance moniker that doesn’t go down so well for us.
[…] Premises of Rapid Software Testing by Michael Bolton – Part 1 – Part 2 –Part 3 […]