New answers tagged

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


0

The benefits of reviews for requirements, designs, and code less bugs 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 - ...


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


0

Possible arguments: 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


6

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


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, ...


8

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


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


3

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


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

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


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