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 ...
The benefits of reviews for requirements, designs, and code
assumptions are reduced
code can be easier to change
more time to write better tests
requirements are better understood
common design mistakes can be avoided
software that meets more requirements correctly
delivery pace can be maintained and not slow down
The biggest single advantage - ...
It is easier to fix issues if they are found earlier in the development process and reviews may draw out these issues
Reviews could potentially reduce the need for re-work, which is a form of waste
By finding issues earlier in the process you can help to de-risk the later stages of the work
Reviews are a form of knowledge sharing
I think it is a very fair question for the PM to ask. Evaluating the proposed effort against its benefits, costs, and risks is proper leadership and management. If you have a proposal for testing, you ought to be able to articulate value. If you cannot, then do you truly understand the work?
Testing is risk mitigation, and PMs own the responsibility to ...
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, ...
Modern testing is all about how you assist to "Accelerate the Achievement of Shippable Quality".
Do your reviews help with accelerating? What metrics do you use to create proof of that? Testing helps with reducing risks, but at what cost? What is the return on investment.
Overall I think the project managers question seems a very valid one. Wonder ...
I'm not sure that there is a good answer to the manager's question. In some contexts, having formal gate reviews may be beneficial. However, reviews tend to be after-the-fact inspections, which aren't the best way to build quality into a product.
I'd recommend rethinking what you mean by "review". For example, the Three Amigos can help you during ...
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 ...
What do you mean by "reviews" in this context? Many development teams do peer-reviews of code and analysis because they find that reviews improve productivity and quality. Many teams also make end-user reviews part of their Definition of Done for work. This is something the whole team should have an opinion on, not something you need to discuss ...
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 ...
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 ...
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.