DevelopsenseLogo

The Rapid Software Testing Namespace

Just as no one has the right to tell you what language to speak at home, nobody outside of your project has the authority to tell you how to speak inside your project. Every project develops its own namespace, so to speak, and its own formal or informal criteria for naming things inside it.

Rapid Software Testing is, among other things, a project in that sense. For years, James Bach and I have been developing labels for ideas and activities that we talk about in our work and in our classes. While we’re happy to adopt useful ideas and terms from other places, we have the sole authority (for now) to set the vocabulary formally within Rapid Software Testing (RST).

We don’t have the right to impose our vocabulary on anyone else. So what do we do when other people use a word to mean something different from what we mean by the same word?

We invoke “the RST namespace” when we talk about testing and checking, for example, so that we can speak clearly and efficiently about ideas that we bring up in our classes and in the practice of Rapid Software Testing. From time to time, we also try to make it clear why we use words in a specific way.

For example, we make a big deal about testing and checking. We define checking as “the process of making evaluations by applying algorithmic decision rules to specific observations of a product” (and a check is an instance of checking). We define testing as “the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.” (and a test is an instance of testing).

This is in contrast with the ISTQB, which in its Glossary defines “test” as “a set of test cases”—along with “test case” as “a set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.”

Interesting, isn’t it: the ISTQB’s definition of test looks a lot like our definition of check. In Rapid Software Testing, we prefer to put learning and experimentation (rather than satisfying requirements and demonstrating fitness for purpose) at the centre of testing. We prefer to think of a test as something that people do as an act of investigation; as a performance, not as an artifact.

Because words convey meaning, we converse (and occasionally argue, and sometimes passionately) the value we see in the words we choose and the ways we think of them. Our goal is to describe things that people haven’t noticed, or to make certain distinctions clear, with the goal of reducing the risk that someone will misunderstand—or miss—something important.

Nonetheless, we freely acknowledge that we have no authority outside of Rapid Software Testing. There’s nothing to stop people from using the words we use in a different way; there are no language police in software development. So we’re also willing to agree to use other people’s labels for things when we’ve had the conversation about what those labels mean, and have come to agreement.

People who tout a “common language” often mean “my common language”, or “my namespace”. They also have the option to certify you as being able to pass a vocabulary test, if anyone thinks that’s important. We don’t.

We think that it’s important for people to notice when words are being used in different ways. We think it’s important for people to become polyglots—and that often means working out which namespace we might be using from one moment to the next.

In our future writing, conversation, classes, and other work, you might wonder what we’re talking about when we refer to “the RST namespace”. This post provides your answer.

Subscribe to the Newsletter

19 replies to “The Rapid Software Testing Namespace”

  1. “So we’re also willing to agree to use other people’s labels for things when we’ve had the conversation about what those labels mean, and have come to agreement.”
    I wonder if “agreement” is really necessary, or simply “understanding”?

    As I understand it, shallow agreement can sometimes occur when 2 parties attempt to communicate but use labels without shared meaning. Avoiding shallow agreement doesn’t necessarily require that both parties agree (have the same opinion) about the labels and their meaning, but simply that both parties understand (perceive the intended meaning) of the labels and their meanings. This shared understanding (comprehension) can sometimes allow communication to proceed.

    I’m reminded of the debate “stopping heuristic” explained to me by Doug Hoffman at the last CAST. I wrote about it in a comment here: http://www.shino.de/2014/02/04/shallow-disagreements/.

    Reply

  2. Just a quick observation:

    “This is in contrast with the ISTQB, which in its Glossary defines testing as… oh dear, it doesn’t define “testing”.”

    Actually, they do. It is the 6th item on page 46 of the Glossary you linked:

    “testing:
    The process consisting of all lifecycle activities,
    both static and dynamic, concerned with
    planning, preparation and evaluation of software pr
    oducts and related work products to determine
    that they satisfy specified requirements, to demons
    trate that they are fit for purpose and to detect
    defects.”

    Michael replies: Well, there’s a screwup. I’ve fixed the offending passage. Thank you.

    Reply

  4. Michael I have been thinking and thinking about this post past 24 hours.

    I see this as a white flag, which I cannot raise right now. I have put everything on line for making things right here.

    Here in Pakistan (not India) we are just a handful of Context Driven Testers, practitioners and trainers, and we face a huge amount of “Mindset” and “Trending” resistance from folks who are either make shift testers or are certified from somewhere. We also face resistance on organization culture and practices they carry out. It is hard to call everyone on a meetup. You must have heard about a few in the past. There is me, Majd Uddin, Faiza Yousuf, Asim Kazmi, Ahmed Mubbashir and a couple of more who are raising the voice. Rest are just doing the jobs or running after test automation to get a higher salary.

    The “mingling” of definitions is the key factor why we face questions about “Automation”, “Checking”, “Bug / Defect” and even testing!

    You would not believe that in my last interview I was rejected because the guy who was a certified tester said that “Product element” heuristic is bookish and tell me something practical! I never answered any of his following questions, because he was only seeking definitions.

    Michael replies: Did he give you a chance to show him how you use it in practice? No? In other words, he dismissed the idea because he had a theory about it, and didn’t want to see it used in practice. Okay. You don’t want to work for someone like that.

    I will keep this “namespace” in my mind but over here it is not the time to play on the back foot 🙂

    Don’t play on the back foot. Try bringing samples of your work with you. Be prepared to spout their silly definitions right back at them—and be ready to explain the problems with them, and how you can offer help in solving those problems. Be so good they can’t ignore you.

    Respect and love!
    Arslan

    Reply

  5. Since Michael linked ISTQB glossary here..

    Page 7, “0.1 Purpose of this Document”, paragraph 3:
    In compiling this glossary, the working group has sought the views and comments of a broad spectrum of opinion in industry, commerce and government bodies and organizations, with the aim of producing an international testing standard that would gain wide acceptance.

    Does such a statement pass a basic credibility test? How a bunch of arguable* definitions is equated with activity of testing? If anything, testing produces knowledge and awareness, and these are already universally and internationally standardized.
    * Those are arguable definitions. Just one example:
    Page 9, Accessibility testing: Testing to determine the ease by which users with disabilities can use a component or system. – In fact, accessibility testing is the opposite – it’s a discovery of accessibility barriers (established industry term) that make difficult or impossible for people with disabilities to get things done with the software. As for the “ease” (don’t you think it’s too vague for people arguing for clear definitions?), accessibility levels have well-developed system of A, AA, AAA heuristic compliance criteria.
    So what’s the point of memorizing some made up stuff that’s not aligned with government and industry regulations?

    Reply

  6. I have difficulty in taking strong definitions from one namespace and applying (is merging a better word?) them into another namespace.

    Michael replies: You’re not alone.

    For example, my current client has a goal of automating as much of the testing as possible. I would like the team to first adopt the RST distinction between checking and testing, and work this understanding into the test cases the QA team is writing. I’m hoping in this way we can highlight what checks are valued in our testing, and use those as a springboard into an automation project.

    From what I’ve read on yours and James’s blogs, a check can best be performed by a machine and, if possible, should be automated. Is that assertion accurate in RST Namespace?

    A check is an observation linked to a decision rule, such that both the observation and the decision rule can be performed and applied algorithmically. That doesn’t make machines “best” at checking, since “best” is relative to some purpose and some set of criteria; but it certainly is the case that machines can do checking very quickly, precisely, tirelessly. A check shouldn’t be automated unless there’s a perception of value in performing the check. (Just because you can program a check doesn’t mean you should.)

    However, in the namespace of my client, any manual task a tester performs is considered “automatable” and a wild goose chase is underway for a miracle robot tester that perfectly emulates our work. Before any meaningful work can be done, the way we (my client, the QA team, and I) talk about automation needs to change.

    Not necessarily. The way you think about it has to change, for sure. Our contention is that changing the way you talk about it may help the way that you think about it.

    Automation is one of dozens of examples where namespace plays a key role, and where words and meanings can vary greatly between testing groups. Do you have any advice or resources you could recommend on how to navigate between multiple namespaces?

    Nothing guaranteed, but mostly this: just keep talking. Keep seeking precision in discourse. Trace the chain of logic in arguments (or the logical fallacies in them). Beware of shallow agreement (the trap of believing that people agree because they’re using the same words). Feel free, if you think it might help, to refer to our stuff (Testing and Checking Refined; On Testing and Checking Refined; Versus != Opposite; Harry Collins and the Motive for Distinctions; Testers, Get Out of the Quality Assurance Business; “Manual” and “Automated” Testing). Watch for the problems caused by misapprehensions, and experiment with talking about the roots of those problems with new language.

    Reply

  8. I am not sure if you realize another aspect of your proposal. In your post you are objecting to the ISTQB claiming a ‘common language’. Would it be OK if ISTQB also defined their own namespace?

    Michael replies: I do realize that part of the proposal, and the answer to your question is Yes. It’s okay for people to make reasonable claims.

    When you define namespaces, it seems like you are giving sanction to other namespaces (as long as they don’t claim a common language). If you look at the contemporary development community, their understanding of testing is flawed. By creating a namespace, it almost seems, as long as the other party does not claim a common language, there is no issue.

    I disagree. Namespaces don’t solve the problem of the ISTQB’s shallow notions of testing, but they’re not supposed to do that. Declaring a namespace in this way implies that you are willing to take responsibility for it, and that other interpretations exist—at which point we can start highlighting the differences.

    I think both ISTQB and the development communities understanding of testing is incorrect. An alternative to creating a namespace is to just inform them that they are incorrect or to invite/be open to debate. Of course, that won’t work. To me, it doesn’t matter/it won’t stop me from telling them that they are incorrect whether they have a common language or not. I realize that it would be odd for you to proclaim RST is better than the other approaches.

    I think it is better than other approaches when your goal is to do the fastest, least expensive testing that you can do while being entirely accountable and being able to stand up to scrutiny. I think it is better than other approaches when we put people (not tools, not the process model, not the documentation) at the centre of testing. But notice a couple of subtle things in there: we argue from first premises that no particular practice we espouse is best; that the desirable factors will vary in importance in context. And notice that I can say I think that’s the best approach (for specific purposes, tailored to context, so far as I know, so far, for now, and open to discussion) without declaring that it is the best approach (full stop).

    Note: I am not saying that you intended to give sanction to other approaches.

    Reply

  12. Enjoyed reading the blog. Agree with the idea of Rapid Software testing. In order to deliver software at high speed Testing requires to be changed dramatically. Liked the way you have given various examples. Real time successes & challenges of best practices involve a mix methodologies, organized, and a measure of progress in delivering quality software.You can also meet a group called **** which involves eminent people from industry analyst firms, forturne 500 companies and testers with deep domain knowledge, getting together to explore software testing trends in quality engineering to deliver speed@quality.

    Michael replies: Thank you for the compliments. Pro tip: don’t include “seo” in your email address if you want me to publish the name of your group.

    Reply

  13. […] Since many people believe testing is easy, some testers or technical people we meet also feel that test management is easy and that anyone can do it. Most of the people who say such things do not really understand what they mean by testing or test management. It is very important to understand what we mean when we use these terms. In the words of Michael Bolton,”Words are powerful tools for understanding and clarifying ideas, but like all tools, they must be used skillfully to achieve their purposes and to avoid trouble.” The authors of this article mostly use the vocabulary of the Rapid Software Testing Namespace. […]

    Reply

  17. […] Colin’s blog Rob Lambert’s blog Cultivated Management blog Michael Bolton’s blog Pink, Daniel H. (2010-01-13). Drive: The Surprising Truth About What Motivates Us. Canongate Books Johanna Rothman Jerry Weinberg’s Perfect Software and Other Illusions about Software Testing The Association for Software Testing The authors of this article mostly use the vocabulary of the Rapid Software Testing Namespace. […]

    Reply

  19. Hi, I Read your blog and I feel it is a very wonderful, informative blog .
    There are a lot of good information on this blog, I’d like to Share and I think people will get a lot of support from this blog.

    Thank you for sharing this informative blog, please keep up and share some unique posts with us in the future.

    redacted

    Michael replies: Thank you for the kind words. Those kind words aren’t quite enough to pay for free advertising on my site, though.

    Reply

Leave a Comment