DevelopsenseLogo

Premises of Rapid Software Testing, Part 1

In February of 2012, James Bach and I got together for a week of work one-on-one, face-to-face—something that happens all too rarely. We worked on a number of things, but the principal outcome was a statement of the premises on which Rapid Software Testing—our classes and our methodology—are based. In deference to Twitter-sized attention spans like mine, I’ll post the premises over the next few days. Here’s the preamble and the first three points:

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. They have been shaped by the influence of two thinkers above all: Cem Kaner and Jerry Weinberg, both of whom have worked as programmers, managers, social scientists, authors, teachers, and of course, testers.

(We do not claim that Cem or Jerry will always agree with James or me, or with each other. Sometimes they will disagree. We are not claiming their endorsement here, but instead we are gratefully acknowledging their positive impact on our thinking and on our work. We urge thinking testers everywhere to study the writings and ideas of these two men.)

1. Software projects and products are relationships between people, who are creatures both of emotion and rational thought. Yes, there are technical, physical, and logical elements as well, and those elements are very substantial. But software development is dominated by human aspects: politics, emotions, psychology, perception, and cognition.

A project manager may declare that any given technical problem is not a problem at all for the business. Users may demand features they will never use. Your fabulous work may be rejected because the programmer doesn’t like you. Sufficiently fast performance for a novice user may be unacceptable to an experienced user.

Quality is always value to some person who matters. Product quality is a relationship between a product and people, never an attribute that can be isolated from a human context.

2. Each project occurs under conditions of uncertainty and time pressure. Some degree of confusion, complexity, volatility, and urgency besets each project. The confusion may be crippling, the complexity overwhelming, the volatility shocking, and the urgency desperate.

There are simple reasons for this: novelty, ambition, and economy. Every software project is an attempt to produce something new, in order to solve a problem.

People in software development are eager to solve these problems. At the same time, they often try to do a whole lot more than they can comfortably do with the resources they have. This is not any kind of moral fault of humans. Rather, it’s a consequence of the so-called “Red Queen” effect from evolutionary theory (the name for which comes from Through the Looking Glass): you must run as fast as you can just to stay in the same place. If your organization doesn’t run with the risk, your competitors will—and eventually you will be working for them, or not working at all.

3. Despite our best hopes and intentions, some degree of inexperience, carelessness, and incompetence is normal. This premise is easy to verify. Start by taking an honest look at yourself. Do you have all of the knowledge and experience you need to work in an unfamiliar domain, or with an unfamiliar product? Have you ever made a spelling mistake that you didn’t catch? Which testing textbooks have you read carefully? How many academic papers have you pored over? Are you up to speed on set theory, graph theory, and combinatorics? Are you fluent in at least one programming language? Could you sit down right now and use a de Bruijn sequence to optimize your test data? Would you know when to avoid using it? Are you thoroughly familiar with all the technologies being used in the product you are testing? Probably not—and that’s okay.

It is the nature of innovative software development work to stretch the limits of even the most competent people. Other testing and development methodologies seem to assume that everyone can and will do the right thing at the right time. We find that incredible. Any methodology that ignores human fallibility is a fantasy.

By saying that human fallibility is normal, we’re not trying to defend it or apologize for it, but we are pointing out that we must expect to encounter it in ourselves and in others, to deal with it compassionately, and make the most of our opportunities to learn our craft and build our skills.

I’ll continue with more Rapid Software Testing premises tomorrow.

Subscribe to the Newsletter

15 replies to “Premises of Rapid Software Testing, Part 1”

  3. Another great article Michael and I am looking forward to the rest of it.

    Michael replies: Thanks, John.

    You are making some really good points and the following especially is meaningful for me at the moment and within the craft of testing given the exposure the latest ISO software testing standard appears to be getting.

    “Other testing and development methodologies seem to assume that everyone can and will do the right thing at the right time. We find that incredible. Any methodology that ignores human fallibility is a fantasy. By saying that human fallibility is normal, we’re not trying to defend it or apologize for it, but we are pointing out that we must expect to encounter it in ourselves and in others, to deal with it compassionately, and make the most of our opportunities to learn our craft and build our skills.”

    I keep hearing the same questions time and time again.

    When do you expect to finish testing?
    What have you got left to test?
    Why did you miss that?

    That paragraph above sums up the why.

    I hope you do not mind but I am going to ‘borrow’ that and use with the teams I work with.

    You’re absolutely welcome to do that. That’s why I post this stuff.

    There are answers to those questions.

    1) “Since you’re in charge of the shipping decision, you’re also in charge of deciding whether you have enough information to make that decision. We could test forever, but you probably don’t want us to do that; you probably have a shipping date in mind. Let’s talk about what you’d like us to look at, and what we all think are risks worth considering, and we’ll work together to make sure you’re getting the information you need as it’s being revealed.”

    2) I’d offer some of the ideas that I’ve offered before: http://www.developsense.com/publications.html#GotYouCovered, http://www.developsense.com/publications.html#CoverOrDiscover, http://www.developsense.com/publications.html#AMapByAnyOtherName.

    3) “Do you mean ‘how did we all miss that?’ Here are some possible answers: http://www.developsense.com/blog/2011/01/youve-got-issues/“.

    Reply

  4. […] the other morning, I came across Michael Bolton’s excellent articles on the premises of Rapid Software Testing (RST).  RST is something that I’ve been keenly interested in, but haven’t had the […]

    Reply

  5. For 3. ….some degree of inexperience, carelessness, and incompetence is normal…

    are you referring to biases…not sure.

    Reply

  6. I felt, by runthrough this article i have acquired good epistemology and i have pored what is happing in the Software Development. Really good point of your third step about Despite our Best hopes. Your words really hits my mind and started to think over it. How should i optimize and improve my testing activites and I learnt to be fanasty while testing the product. Thanks for beset of Elaboreted Rapid testing article.

    Reply

  8. […] Premises of Rapid Software Testing part 1 (engagement with software development), part 2 (the nature of testing as an investigative activity) and part 3 (our relationship to our clients) by Michael Bolton – “1) Software projects and products are relationships between people, who are creatures both of emotion and rational thought… 4) A test is an activity; it is a performance, not an artifact… 6) We commit to performing credible, cost-effective testing, and we will inform our clients of anything that threatens that commitment.” […]

    Reply

  9. […] in it;  and reporting on all of those things. The premises of rapid software testing are listed here; a framework for describing rapid software testing is […]

    Reply

  10. […] The premises of rapid software testing are listed here; a framework for describing rapid software testing is here. 2. Automate or not to […]

    Reply

  14. Hey Michael,

    Thanks for putting together this post on Premises of Rapid Software Testing.It is a great read. I particularly find your thoughts about occurrence of each project under conditions of uncertainty and time pressure interesting.
    Keep up these insightful posts.

    Cheers!

    Michael replies: Thanks for the kind words, Geoffrey.

    Reply

Leave a Comment