5

As a software tester/QA, how to handle when stakeholders (e.g Project Manager and Developer) have different understanding of project requirements? I understand that this communication breakdown affects the release and QA timeline for the project.

Can anyone suggest what would be the tester/QA's next move here?

Appreciate your kind suggestion. Thanks!

1
  • What project management methodology are you using? A Waterfall methodology like Prince2 or PMBoK? An Agile methodology like Scrum or DSDM?
    – nick012000
    Sep 8 at 6:23
7

This is a great question. Several years back I analysed the bugs reported in a team and found that over half of them came about as a result of misunderstanding of requirements.

Some things that can help to reduce this problem include:

  • Have the team (QA, devs, PM, etc.) jointly add details to a requirement, so that they share a common understanding
  • Using an approach such as Behaviour Driven Development (BDD)
  • Early and frequent demonstrations of new functionality - even demonstrating features while they are still under development
1
  • Whether the Project Manager is considered a member of the project team varies depending on what methodology you're using.
    – nick012000
    Sep 8 at 6:23
5

If there are two stakeholders who have different understandings of the requirement, then there may be more. What about how you interpret the requirement, from the perspective of a tester? Or how about the customer? Or even the end-users of the product? If the requirement is ambiguous to the point where two people who (in theory, anyway) are working closely together to deliver the product have different interpretations, I'd consider it likely that there are other interpretations out there.

I'd expect that the QA team is watching out for this by being involved in every step of the process. Looking at quality assurance as post-development testing is insufficient to deliver a quality product. Looking at the requirements as another pair of eyes to find ambiguity or asking questions about how to go about testing the requirement early in the development process is important for setting the team up for long-term success.

If you're already to the point where the work is ready for integration and testing, yet there are disagreements about the requirement, the first step would be to figure out what the requirement truly is. Someone has to make the final decision. One option would be for someone to contact the customer or an end-user and get clarification as to what the need actually is. In some cases, the project manager or product owner may be empowered to make the decision and provide the voice of the customer, in which case their word is the true requirement. Once you have the true requirement, the tests are built to exercise the system within the bounds of the requirement and demonstrate that it fulfills the need.

Depending on what the true requirement is and how far the design and implementation is from that requirement will determine the following steps.

2

Welcome to PMSE!

It's very normal for people to have different understandings of a requirement but what is interesting is that you haven't mentioned the person whose opinion matters most of all: the customer. The way to deal with your situation is to collaborate closely and frequently with your customer (sponsor / product owner / end-users), deliver results regularly and often, seek the customer's feedback and act on it.

QA should always run from the beginning of a piece of work to its end. It is counter-productive trying to box QA into a limited timeframe. What matters is how quickly the team as a whole (analysis, development, QA and customer) can deliver each increment of the product.

5
  • "The way to deal with your situation is to collaborate closely and frequently with your customer" This is true for Agile approaches, but may not be true for Waterfall approaches.
    – nick012000
    Sep 8 at 6:25
  • @nick012000 I'd suggest that close cooperation with the customer is key to the success of any piece of work, regardless of what kind of label you put on your approach.
    – nvogel
    Sep 11 at 8:36
  • In Waterfall, all the planning is done up front. Collaboration with the customer during development is to avoided to prevent costly changes to specifications.
    – nick012000
    Sep 11 at 11:17
  • Hi @nick012000 Perhaps you are not being serious here, but projects that are specified up-front usually have a change-control process and since there is no such thing as an infallible, perfect specification there is always room for discussion, clarification and user feedback. Avoiding customer collaboration is not something I would ever recommend as a strategy for success! but YMMV!
    – nvogel
    Sep 11 at 12:01
  • The fact that "change management" exists is evidence for what I'm saying.
    – nick012000
    Sep 11 at 12:34
1

I am going to answer this question more generically because deconflicting stakeholder issues should not require different methods based on who the stakeholders are or what the tasks are. Different opinions, interpretations, and perceptions are a given on any complex project so the team should have a process by which these issues are escalated, examined, analyzed, and upon which the team agrees on a solution. If two or more stakeholders cannot resolve an issue at a lower, more informal level, then one or more stakeholders would formally escalate it through this process allowing the broader team to handle it accordingly.

This process should allow both opposing stakeholders to voice their point of view, arguing the merits, and providing their solution. The escalation team would listen to both arguments and then choose a solution using the predetermined method, whether it is an individual with the proper authority, majority vote, or another form of consensus.

0

In terms of QA, when a requirement is frozen, prepare your test cases and present them to the team. Everybody will see what they will build and/or receive and come up with questions & change requests before you start testing.

-2

Everyone with an apparently different understanding of project requirements needs to be reminded both of the original, specific wording and of the usual interpretation in industry-standard custom and practice.

If there are people who can't or won't accept that, either they need to attend some kind of group-think seminar to get their minds right, or they're correct and the project brief needs to be re-written.

4
  • Hi Robbie - I'd say your answer could benefit from a rewriting more focused on what OP could do (and as a bonus, how could he do it) from a QA standpoint.
    – Tiago Cardoso
    Sep 10 at 21:43
  • @TiagoCardoso Thanks and don't you think that would be going too far towards doing it for him? Sep 10 at 21:46
  • The answer should ideally help OP (and others) solving the problem. You need to add as many details as possible to reach to this goal.
    – Tiago Cardoso
    Sep 13 at 11:29
  • @Tiago Thanks and if I haven't already provided enough information to help the OP (and others) solve the problem, why are they being paid for any job where this kind of thing might matter? I don't believe the Exchange is here to provide detailed scripts; merely to suggest outlines. How does that fall short of your expectations? Sep 13 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.