I think this question is as a result of not following two of the most important testing principle:
- Early testing
Early testing states that testing activity should begin as early as possible. This helps in reducing the cost involved in fixing the defects. The earlier the issue found lesser is the cost. Here the cost is calculated by the paid working hours needed to be spent on debugging, identifying, fixing and then retesting the defect.
**Example:**If the issue is found after a full system is built then it takes more time to debug, fix, rebuild and test. If it is found in unit test level then you can fix and retest right away.
So when is the earliest to start testing?
The earliest to test is from the requirement analysis phase. If an experience QA is added into requirement gathering then missed requirements can be easily found out.
For example :
Imagine a requirement gathering section for a social media website is going on and the client tells that user should be able to upload photo and able to delete.
Marketing team rights this down and sends to PO
Product owner writes this down as the user is able to upload a photo and able to delete it
In development user story it is translated as user is able to upload one photo and delete it
And during testing, QA team questions that why shouldn't the user be able to upload multiple photos> And client confirms this and informs that release cannot be done unless this feature is available.
If QA was involved in requirement gathering and had asked clarity on this requirement then this release delay won't have happened
- Absence of errors fallacy
This is the same situation as above where the requirement was translated to user stories without details and the implementation lacked the basic requirement. So now the product doesn't meet the requirement and any other quality attribute is of no use
How this could have been prevented
This could have been prevented if QA would have been more vocal and questioned the design at least in the design phase.
So action points for your team:
- Add QA to requirement gathering
- Have more user-story refinement sessions and be vocal in such sessions
- Don't hesitate to go back to the client if the requirement is not clear, keep the feature in product backlog till clarity is obtained
- Ask more question and involve Product owner and developer for things QA feels like a bug in design. Make all decisions a team decision rather than an individual's