New answers tagged pm-software
-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 ...
1
You need to define further what you mean by, "...is not being tested properly". Was the testing not proper because the tester improperly performed the test or was it improper because the test was inadequate? Without an answer to the root cause, you have no possible action. So to answer your question, your best approach is to uncover the root cause. ...
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, ...
3
For me, it wouldn't make any difference if you did all the testing, B did all the testing or if you shared the effort. Nor does it make a (big) difference if what you notice in production is a new problem, an incomplete fix or a regression.
In all cases, you should follow the procedure for reporting and assessing a problem found in the production environment....
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 ...
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 ...
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 ...
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.
Top 50 recent answers are included