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!
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:
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.
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.
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.
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.
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.
