Customer, Developer, Tester

An interesting question that sometimes emerges for teams using XP practices is whether Testers (should you be lucky enough to have them) are Customers or Developers. There is a slight catch in the question itself. Customer and Developer are roles, not jobs, or people. A person can adopt either role. However a person should not adopt both roles at the same time. That said there is a clear distinction between the activities performed by the two roles which might best be defined as Customer determines ‘what’ and Developer determines ‘how’.

In XP Customers define the requirements (in the form of user stories and supporting detail), prioritize stories, and participate in functional testing. The Customer defines scenarios which verify that the story is ‘done, done’. In contrast Developers provide estimates and build the solution that passes the acceptance tests. Crossing the streams – Customers indicating how they want something built or Developers defining what to build always ends in a loss of the insights each specialism provides and should be avoided. Trying to decide how and what at the same time also leads to poor solutions. Often as the requirement is built around a proposed, often non-optimal solution, obscuring the true need. Other times we try to automate existing process based of manual or legacy practices over defining what the need is. Try to seperate defining what from how.

With this understanding testers naturally fit within the Customer role – because they work on defining tests for what the system does and have responsibility for confirming them. This means that for testers, understanding the domain of the system-under-test becomes a key responsibility to help them fulfill their role.


About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • electric winch

    OK,That is right

  • massager

    Yes,I think so
    It may be

  • massager

    Yes,I think so
    It may be

  • Andrew

    The problem is, everyone* thinks they know better than the actual people who use the software. Even hinting that QA is a customer rather than an extension of development only complicates the matter more.

    I know that seems jaded, but I’ve seen it far too many times in large companies.

    * Obviously not everyone, but enough people out there to practically qualify as “everyone”.

  • Ian Cooper


    I’m not seeing the identification of tests as part of the end product as a reason to put Testers in the Developer role.

    Part of the issue here may be a natural tendency by developers to downgrade tester’s roles. Andrew effectively demonstrates this by asking why is the tester challenging what the developers have built?

    By making testers Customers and asking them to help the customer define requirements we ask them to become experts in what the software is supposed to do. This helps them undertake activities like exploratory testing.

    The BA role is difficult in many organizations, because many are not subject matter experts but simply capture requirements from the customers and write them in documents. In most cases that would be better handled by writing scenarios that could be used for tests. In that case the line between a tester and a non-SME BA becomes very blurred. BAs might be offended by that position, but they should not be. Raising QA to customer improves the authority of the role instead of downgrading them.

  • Seve Py

    I would classify Testers as Developers. The test plans and tests that testers produce are as much a part of the end product and the code a coder produces. Test plans are not the definition of the requirements of an application, they are a reflection. They help interpret a customer’s requirement into a course of events or behaviours as applicable to a given software design in the exact same way as a developer assesses how a requirement might be met in the perspective of the software system. (Participating in that design is always favourable.)

    A B.A. on the other hand is a proxy portal to the Customer, hence is a customer. Their job is to assess the business requirements of a customer and ensure what the testers and developers propose does actually meet what the Customer has in mind. That plus a good deal of haggling between both parties.

  • Ian Cooper


    I am using Customer in the XP sense. So a Customer is not always a real user, but is often a proxy for them. Often this makes sense as the jobs within customer such as product owner, subject matter expert, or tester can require skill sets that end users do not have.

    A tester acting as a Customer needs to reach out the real user, subject matter expert, or product owner for the acceptance criteria. They should not ‘make them up’ any more than developers should. By reaching out they gain domain knowledge which contributes to a better product.

    So in your case the tester is still a Customer, but he’s not reaching out to the right person to understand what acceptance is when he is testing.

  • Matt Baker

    This issue always brings out strong opinions! I agree that you should have some testers act in the customer role but others still closer to the code. That’s not to say these ‘closer to the code’ testers should be developers, however. In fact, I agree with Ian that you should never perform functional testing on something that you wrote yourself. That is unless you’re really good at forgetting things over the course of a week or two and wait that long to test it, but then you lose the feedback loops XP provides, which defeats the purpose.

    The major trap you can fall into as a tester who knows a great deal about the HOW is that you end up testing the how too much and putting the WHAT off to the side; or worse yet, assuming the HOW really does satisfy the WHAT.

    Testers that challenge the how do the greatest good on a team, even if they’re challenging the perfect implementation: it can always be more perfect.

  • Gareth Evans

    In that case Andrew, it should be the BA’s who are your “customer” rather than the testers, seeing as the BA’s have gathered the requirements for the project – this also helps if you have decent requirement documentation written by the BA in the first place.

  • Andrew


    I have to disagree (with a caveat).

    A QA Tester should care about the technical requirements, but they are not a customer because at the end of the day (or project) they are not the ones using the software. The biggest problem QA departments have is when they THINK they are a customer, but since they in reality don’t act like one, they completely miss what is important to the real end users. So what you get is a product that technically might be fine (when I hit the button, it does what it says on the tin), but from a usability standpoint it’s crap.

    The caveat is, if a QA department works very closely with the end users, this can largely be avoided. When I say “end users” I mean the actual end users of the product, not some high level manager who doesn’t know jack but says stuff like “Oh, the people on the floor really want feature X” even though they couldn’t give a crap about it when all they want is for the Tab Indexes to actually work.

    An example I can give is that we currently are testing some software we built for a particular industry, one of our junior testers is not, nor has he ever been part of that industry, yet he’s trying to act like a customer and saying stuff like “I don’t think this window/label/popup/etc. should say ‘X’, I think it should say ‘Y'”. Whereas all I care about is, if he hits a button, does it do what it should. Window text, labels, etc. are all in the realm of our BAs who work very closely with our real customers so any comments where he’s trying to put himself in the seat of the customer is completely useless and in this case, actually counter productive.