Chris Rickard

These other answers are so horrendously AI generated. Here’s some real talk. Test result discrepancies mean one of 3 things… 1. The acceptance criteria was correct, the developer understood it, but implemented it incorrectly (bugs) 2. The acceptance criteria was correct, but the developer misunderstood it, and therefore implemented it wrong (miscommunication / misunderstanding) 3. The acceptance criteria was wrong (incomplete / incorrect) This is really a software requirements definition problem - not a “test case discrepancy” problem. You might notice it at the END of the project, but the problem arose at the START of the project. People don’t spend enough time up front on high quality requirements. Fix that, fix the symptom.

If the high-ranking exec has a voice on the project.. then acknowledge the request and show you understand why they want the change, but emphasise the impact on the current scope, timeline, or budget. For example, if a C-level asks to add a new feature, you could say, “Happy to include this, but it might push our launch date back by 2 weeks. Is that okay?” If they do NOT have a voice on the project.. then you need to ensure that the decision-makers OK it. It’s all about aligning their expectations with reality!

Continuous loops are key.| Continuous refinement, continuous learning, and continuous user and stakeholder feedback. Each iteration should reduce the ambiguity and (hopefully!) bring you closer to clarity.

SME's need to be in the room, that's no question. But it's also common that you don't know who those experts are, UNTIL you start untangling the requirements. The rule of thumb: if the people in the room don't have an answer or clear understanding of the requirement, stop, find out who would, and bring them into the conversation. Many people gloss over this step and it's a leading cause of "misaligned requirements"

Requirements engineering is 100 %an art. And clear, complete, and aligned requirements should always be the goal for any project. I recommend writing user stories and non-functional requirements first with all the relevant stakeholders present. Then flesh out acceptance criteria, as getting to that level of detail cuts down on misinterpretation and scope changes.

Rapid prototyping gives stakeholders something tangible to validate early. MANY people are visual thinkers - so easier to iron out ambiguity when people can see it.