RST Methodology: “Responsible Tester”

In Rapid Software Testing methodology, we recognize three main roles: Leader, Responsible Tester, and Helper. These roles are situational distinctions. The same person might be a helper in one situation, a leader in another, and a responsible tester in yet another.

Responsible Tester

Rapid Software Testing is a human-centered approach to testing, because testing is a performance and can only be done by humans. Therefore, testing must be traceable to people, or else it is literally and figuratively irresponsible. Hence, a responsible tester is that tester who bears personal responsibility for testing a particular thing in a particular way for a particular project. The responsible tester answers for the quality of that testing, which means the tester can explain and defend the testing, and make it better if needed. Responsible testers also solicit and supervise helpers, as needed (see below).

This contrasts with factory-style testing, which relies on tools and texts rather than people. In the Factory school of testing thought, it should not matter who does the work, since people are interchangeable. Responsibility is not a mantle on anyone’s shoulders in that world, but rather a sort of smog that one seeks to avoid breathing too much of.

Example of testing without a responsible tester: Person A writes a text called a “test case” and hands it to person B. Person B reads the text and performs the instructions in the text. This may sound okay, but what if Person B is not qualified to evaluate if he has understood and performed the test, while at the same time Person A, the designer, is not watching and so also isn’t in position to evaluate it? In such a case, it’s like a driverless car. No one is taking responsibility. No one can say if the testing is good or take action if it is not good. If a problem is revealed later, they may both rightly blame the other.

That situation is a “sin” in Rapid Testing. To be practicing RST, there must always a responsible tester for any work that the project relies upon. (Of course students and otherwise non-professional testers can work unsupervised as practice or in the hopes of finding one more bug. That’s not testing the project relies upon.)

A responsible tester is like being the driver of an automobile or the pilot-in-command of an aircraft.


A helper is someone who contributes to the testing without taking responsibility for the quality of the work AS testing. In other words, if a responsible tester asks someone to do something simple to press a button, the helper may press the button without worrying about whether that has actually helped fulfill the mission of testing. Helpers should not be confused with inexperienced or low-skilled people. Helpers may be very skilled or have little skill. A senior architect who comes in to do testing might be asked to test part of the product and find interesting bugs without being expected to explain or defend his strategy for doing that. It’s the responsible tester whose job it is to supervise people who offer help and evaluate the degree to which their work is acceptable.

Beta testing is testing that is done entirely by helpers. Without responsible testers in the mix, it is not possible to evaluate in any depth what was achieved. One good way to use beta testers is to have them organized and engaged by one or more responsible testers.


A leader is someone whose responsibility is to foster and maintain the project conditions that make good testing possible; and to train, support, and evaluate responsible testers. There are at least two kinds of leader, a test lead and a test manager. The test manager is a test lead with the additional responsibilities of hiring, firing, performance reviews, and possibly budgeting.

In any situation where a leader is responsible for testing and yet has no responsible testers on his team, the leader IS the acting responsible tester. A leader surrounded by helpers is the responsible tester for that team.


7 thoughts on “RST Methodology: “Responsible Tester”

  1. I’m the lone Responsible Tester on my team. I struggle a lot with when/how best to use Helpers. I related very strongly to your post on Omega Testers, especially points 1 & 2

    1. Anything you do means something else won’t get done.
    2. You feel too busy to plan and prepare.

    The developers on my team are willing to be helpers, which is great. But I have not yet mastered how best to utilize the help. Every time we get to a point where I need the help, it feels like a double burden because now I have to figure out how to help the helpers be productive.

    [James’ Reply: I thought I listed ideas in my Omega Tester article about how to use helpers. If that isn’t enough for you I will happily blog about that. Let me know.]

  2. Hi James,

    Very nice post, thank you for putting up such an explanation of a situation which I faced just one month earlier. After reading this post, I have appropriate words of explaining my desired role to the Management.

  3. In any situation where a leader is responsible for testing and yet has no responsible testers on his team then they are goosed. As leader your main role is to make sure you have the people to execute tests without having to constantly support them. No people then you are not a leader you are a tester.

    [James’ Reply: It’s difficult but not outrageous. If you look carefully at my definitions it all hangs together.

    A test leader, unlike a responsible tester, has two special responsibilities that a responsible tester does not have: to create responsible testers and to create an environment where testing can be successful. The first is people leadership, the second is leadership of a different kind called “problem-solving leadership.” Among others things, it means managing upward to set expectations and get support.

    Now, if a test leader has only helpers, then one thing he wants to do is turn somebody into a responsible tester. If that is not feasible, perhaps because the helpers are part-time, then the test lead plays the role of responsible tester BUT STILL manages upward and creates the environment needed for testing to succeed. This is what I call the Omega Tester.

    A helper does not necessarily need support. A helper may be self-sufficient– except the helper is not accepting responsibility to do a good job of testing, as such. That means the lead simply has to bite the bullet and personally assure that the right testing happens. Otherwise, it wouldn’t get done, and yet only one person is blamed: the test lead.]

  4. The definition of three roles here is very similar to the definition of three roles in Scrum, i.e. the product owner, the team, the scrum master.
    The responsible tester is like “the team” in that this role is responsible for the quality of his work;
    the helper is, in one case like a “Scrum Master” (I would rather call it “Test Master” in an agile testing environment) in that this role supports the team with their work either by providing actual help or by coaching; in the other case like “the chicken” (see “pig and chicken” story in Agile world) who wants to say a word in a testing project but not responsible for the final quality of testing;

    [James’ Reply: (I hate that pig and chicken story. What tripe!) No, I don’t think a Scrum master is like a helper. When I speak of a helper I’m speaking of someone who does testing but is not a tester.]

    the leader is like the “Product Owner” (I call it “Test Owner” in a test project) who is responsible for leading the team to the right direction and makes sure that the team is doing the right things.

    [James’ Reply: The product owner’s job is not leading the team, though. The product owner is not necessarily even technical.]

    I see two definitions “a test leader” and “a test manager”. Different organizations may use these two words and other similar words like “a line test manager” or “a test project leader”, etc. with different meanings. Too many definitions from different sources make people a little bit confusing.

    [James’ Reply: Yes, there are two ways of thinking about it, but both of them are the same from the point of view of Rapid Testing methodology.]

  5. I guess Xiaomei Tai went completely wrong in describing ‘Product Owner’! In agile, product owner is simply the end user or stake holder of the project, no where closed to ‘owning’ the project in any sense or ‘leading’ the project.

    I prefer not to compare leader,responsible tester and helper with any of the existing roles since the meaning James try to emphasis comes with a different background altogether and it is mixed with some of the conventionally existing definitions. It is interesting to look at in its own merit.


  6. Another great post with much food for thought. I try to have practical test case review in pairs in my team, the author of the test case and another tester in parallel with Product Owner review as a second layer of review.

    Ultimately, I see I’m going to have to bite the bullet and take your course ASAP if I want to really progress. Thanks

Leave a Reply to Jonathan Ross Cancel reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.