Is it a testers responsibility to gather requirements from the client & create a scope document?

Question

I am working on project as manual tester with 2 years of experience. In my company there is 1 BA, 1 project manager and 2 marketing guys. However nobody wants to gather requirements from the client; they are asking me to do so and create a scope document.

I do not have any experience doing this. I asked my BA and PM to do so; they said "this is your job, not ours". Is this correct?

I want to know who is typically the correct person/position to do the requirement gathering from clients and convert them into a scope document.

Also, if any team member asks any question to the BA/PM/the person who gathered the requirements, should the person asked resolve these queries or reply "talk to client directly"? When a team member asks the question to a client which he has already cleared to the person who gathered the requirement, the client gets frustrated. What should a person do in this case?

Answer 1

Right, you've got a couple of problems.

The first challenge that I see is that no one considers it their role to talk to the client and understand the requirement. This is typically the role of the Product Owner (or PO), which you don't have.

It's the PO's role to engage with stakeholders and ensure that what you're working on is always the most valuable piece of work. If your team doesn't have anyone fulfilling this role then how does the entire team have confidence that their efforts are not going to be wasted?

Assuming for a minute that your company isn't about to hire new people or retask existing ones then you've got a gap. It's not unbridgeable...

As a QA you actually have quite a good position here. It's your job to ensure that whatever is built not only works, but that it's fit for purpose and meets your clients' requirements. If the requirements are unclear then that's going to be very hard for you!

Creating huge upfront requirement documents is often a wasted effort, there's no way that you're going to be able to cover every scenario and even if you can it's highly likely that the client will make a mistake or change their mind once they see it. The key is to demonstrate the work in progress as much as possible and collaborate as you go.

The ad-hoc communication with the client isn't a bad thing, in fact it's a very good thing! However it sounds like it's a little unstructured. I would suggest a couple of things:

• Demoing your work to the client every couple of weeks (I'm deliberately avoiding the word sprint here as it doesn't sound like you're a particularly agile time). This will give the client the chance to give feedback and you a chance to ask any question
• Encourage EVERYONE to talk to the client, I'm not talking formal emails - I'm talking about building a relationship and chatting.
• To avoid asking the same things over and over again make sure queries are circulated internally first and the questions/answers logged are added to the documentation (or just a question log).

See this as an opportunity to improve your team and client collaboration, don't see it as a "your job" or "my job" thing.

Answer 2

Generally, there are four criteria for resource allocation:

1. Possession of the proper knowledge, skills, and ability to do the work
2. Available time to do the work
3. No conflict of interest between the various roles one could assume and
4. Assigned by the person in charge

It appears you failed only one criterion.

If the person in charge wishes to assume the risk of having someone do work they do not know how to do, then that's on him/her. They have the ultimate accountability for a successful delivery. Let him or her know you have no idea what you're doing but are willing to learn, raise the risk of less than stellar performance, and then get to work and learn a new skill set.

Answer 3

Is this correct?

That depends entirely on the situation. Is it correct in all situations? No. Is it correct in yours? Maybe.

There is some overlap between Business Analyst (BA) and a Quality Assurance personnel (QA). I was once on a team where one person was officially a BA and unofficially a QA; it worked well enough.

Whether or not it makes sense in your situation depends on a few factors. Importantly, what does your hierarchy look like?

Is the PM/BA your direct superior? If so, David Espina's Answer of raising risks to them then accepting their decision is a solid approach.

Do you share a direct superior? If so, you should consider going to this superior and asking for clarification of roles. Right now, each of you is thinking that it is the others' responsibility to gather requirements. This disagreement is causing confusion, and thus needs to be cleared up.

Also if any team member asks [...] the client gets frustrated.

This seems like a separate question to me (in fact, I'm not sure how 'the BA/PM won't gather requirements' fits with 'what to do when the BA/PM asks me to gather requirements after already having gathered them him/herself'...), but I'll answer it here anyway.

First thing you need to find out is why this is happening. Why does the BA/PM want you to go to the client directly - again? Does s/he not actually get that requirement before, just something that's similar? Did s/he forget? Is s/he just lazy? Does s/he believe QAs need more direct involvement with the client? Was s/he instructed by a superior to operate this way? Did the client request this?

You need to find out the why before you can decide what is the right approach.

Answer 4

the scope of work during an employment is very much a prerogative of the company and superior, and the title really doesn't mean much as different company may use different titles to refer to the same role, not to mention for small and/or agile team whereby each task member is covering many different scope of works.

for me, i think no, it is not a junior QA responsibility to elicit requirement. it should be the BA, and for PM to firm up the scope with stakeholders. Getting the requirement and analysing it require very distinct good skills. Like what David Espina mentioned, they are taking the risk.

Furthermore, there is already a lot of things on the QA plate.