Should Testers/QA be Responsible For Writing Requirements?

I saw a question pop up that I thought should definitely be discussed with a wider audience :slight_smile:

Does anyone have thoughts on if QA should be responsible for writing requirements/user stories?

The original poster felt that there should be “separation of concerns” but that

QA should however examine those stories for scope and testability

I’ve been in two different situations myself

  1. Development team (test included under that) had no say in requirements/user stories. We were just given them and expected to get the solution together.
  2. The development team all sat together to talk to requirements. We were given an overarching goal from higher up and it was our job to work together to fully spec this out into user stories as a team.

So I’ve never been solely responsible for writing requirements but I have been involved in the process.

What about you? Have you ever been solely responsible for writing requirements? If not, how have you been involved in the user story writing process?

  1. A few types of requirements:
  • tacit
  • explicit
  • implicit(some can be part of tacit)
  1. When a person hired as a tester starts writing requirements he will not be in the role of tester anymore.
    He will write them from the position of product owner or client or on their behalf.
    He will most probably cover just part of the explicit requirements.

  2. He writes the stuff on behalf of someone.
    He also writes them for someone else.
    A few arguments from here:
    Is his task ending after the first version of the requirements, or is he the owner of the requirements until implementation and in the maintenance phases of the products?
    Is he responsible for the explanation, clarification, understanding of the requirements and product to the client or is the client relationship and responsibility passed over?
    Is he responsible for the implementation of the product based on the requirements written by him? Or is that being transferred to someone else?
    Are the implicit and tacit requirements also a responsibility of the temporary product owner(tester)?

The responsibility can be given to a tester(who’s going to be in another temporary role) to write requirements by his manager. And he could accept it.
But, the whole story doesn’t start with the writing and doesn’t stop at the end of the writing.


I would say testers should be the ones who talk to the business and frame the requirements. They can put across their questions on requirements from various angles in order to make sure that the requirements are complete.

To give you an example, there was an ops. meeting in which I was representing the test. The Distinguished Engineer was presenting on behalf of the ‘industry standard’ a.k.a customer. It so happened that some of the specifications on what the product would do did not even occur while they wrote the specifications. When I pointed that out, they agreed that it was never discussed, and promised to add them to the specs.

So, testers can do a fabulous job of validating as well as be part of writing the requirements and specifications.


I think product should be responsible for writing the requirements but validating and questioning them should be a whole team effort. While my team is not directly responsible for writing requirements, we are part of the requirement writing process. We sit down with product once the equivalent of a rough draft of the requirements are written and discuss how that would impact other parts of the product, questions we have about experiences or areas that may have been overlooked (we have the highest product knowledge on our team), as well as how we would test those requirements. If the testing would require additional work (e.g adding some data to test in production), we want to know that ahead of time.


In my opinion:

  • Product Owner (or Technical Author/Business Analyst, if you have one) writes the Requirements, with User Stories and Acceptance Criteria
  • Developers write the Functional Requirements, based on the Requirements
  • Testers validate the Requirements and Functional Requirements against each other, and then ensure other information is added or clarified (see my mention of N.E.E.B.S further down)
  • One person from each department then signs the page off

When I review the spec (although I am currently retrospectively writing the spec for my company’s existing product) I always consider the below (N.E.E.B.S) and if I can’t see it in the spec, I request it. If anyone baulks, I tell them those are the things I test for and would rather know what to expect than incorrectly open a ticket.

  • Negative - What happens when nothing is added or present
  • Expected - What happens when the expected is done
  • Error - What causes an error (and how does it present)
  • Boundary - Character limits, file-size limits, etc.
  • Special - Unexpected, or alternative things such as videos in an image field, etc.

I want that on a Tshirt now


Totally agree with the original poster, writing the requirements and testing seems like a conflict of interests (also developing and testing hehehe).
And, also, that both developers and tester should check the requirements and give feedback because of what you said: testability, scope, also sometimes where you´re testing you get to know the product very well and you can provide a lot of feedback.

Basically, the V-model. The V-model is a winner for me.


I would agree with @spridgey on this.
Product Owners or BA’s are usually those closest to the business/end customers, and unless you are in an organisation where you can be a tester and BA combined, a tester role is pretty full on as it is, without trying to add the business requirements gathering into the mix.
The way we look at it is that the PO’s tell us what is needed, and as engineers (dev and test), we review the stories, ask questions and decide on how best to implement the solution.
Its a good separation.

1 Like

It’s not my original idea… I think I originally found it in this article. I altered it slightly to add something extra for me to remember to do, but also N.E.E.B.S is a YouTube channel I enjoy a lot on youtube!

For me, there has recently been lack of resource from the business so we end up writing up the requirements. This problem has only increased since we’ve gone covid. This is obviously wrong so we can only do our best to think of a solution that best match the perspective of the business. If it’s wrong then we fix it post release. I do still believe that most of it should fall with the BAs or product owners as people have already mentioned here.

Now I have a question myself which may be slightly off topic. What do you think about writing certain requirements for more technical stuff? For example ‘upgrading PHP version X’ or ‘upgrading to database version X’. For these things, there is no formal process but we just write up a simple ticket for devs and testers to work together. That means doing regression testing after the infrastructure has been upgraded and fixing any resulting bugs. The business obviously does not care at all but we still need to go ahead with this as the IT team. When this happens, we have to tell the business that we have to get this out the way before we can accept more work.