What is QA miss of defects and how to avoid it

Profile picture for user devraj
Submitted by devraj on

There were situations when QA did not find the defects and when the client was doing UAT, he found the bug, and somebody shouted! How can QA miss that? In an Agile environment where quality is the responsibility of all, why doesn't somebody ask the Developer of the feature or the lead developer who did the code review?

Everybody should understand in the organization that QA is not Scapegoats for all defects. Defects Miss are never intentional but accidental.

We are not here to blame others but to work as a team, QA is not the only person, but the fact is QA is the person who is dedicated to this job. Everybody expects that QA will find all the defects, but this is not practically possible.

Reason for QA Miss

  1. Lack of Time: Short sprint cycle. Not enough time for QA to test all scenarios. Also, the Developer has less time to develop; there is the possibility that more bugs can be introduced. 
  2. Test Case Review: Test cases are not well written and not reviewed by Sr. QA or other stakeholders.
  3. Lack of skill set: When the Developer and QA are not enough trained or lack knowledge of the application.
  4. Complexity of Application: When the application under development is complex, more rigorous testing is needed, and chances of failure increase.
  5. No involvement in meetings: QA is not involved in sprint meetings.
  6. Lack of documentation: QA Notes by Developer not added by Developer or AC not correctly.
  7. We all are human: QA is also a human being. They can not be 100% correct.
  8. Perfect software is a myth: There is always a bug in the software.
  9. Change in QA Resource: Frequent change in QA resource, experienced QA or QA with good application knowledge decides to leave. New QA can take time to understand the application. The company hires fresher and less experienced QA to save budged another reason.

How to avoid QA Miss

  1. Enough Workload: Add enough stories to sprint, do not overload sprint so that developers get enough time to develop and QA gets enough time for testing.
  2. Meetings involvement: Involve QA in sprint meetings so that they can understand business logic and concepts.
  3. QA in the SDLC: Involve QA from the beginning of the project and ask them to review everything required starting from the requirement, design, etc.
  4. Document in one place: Everybody can refer when needed.
  5. Avoid blame games: Do root cause analysis rather than spending more time blaming others. By blaming others, you will not win clients' hearts or deliver better software.
  6. Test Case Management: Use a better tool to manage and review test cases.
  7. Team of skilled and experienced people: The team should be a combination of experienced people. From 0 to N years, make a team of people with different experiences and skillsets. Provide training to staff at regular intervals.