How to complete testing

How-to complete testing:

  1. Complete all test cases that had been written.
  2. Signed off from testing.
  3. Test exit report produced.
  4. The team can not find any more bugs.
  5. Managers decided no more testing is required.
  6. PM decided that all risks are evaluated and no more testing required.
  7. You confirmed all requirements are met.
  8. All acceptance criteria are met.
  9. Deployed to production.

What’s your way of communicating testing is completed?

What if, it’s all wrong to claim testing is completed or done?

First, what does that even mean “testing is completed or done”? Try to describe the benefits by “completing your testing” in plain English.

Second, why should anyone care about if testing is completed or not?

Third, how can you measure testing is actually completed?

Last but not least, think about why are we testing? What is the purpose of testing? Testing should never be anyone’s goal or aim to complete or done. It is only one way of evaluating and learning about the #risks and #quality of the product at a point of time.

Focus on asessing risks (social and technological) & quality of the product. STOP further testing if business is satisfied and accepts risks of releasing to production.

:sparkles: Testing can never be completed, but STOPPED :sparkles:

:point_down: Comments :point_down:

1 Like
  1. I don’t think you will ever get to a point where “The team can not find any more bugs.”!
    In the years I have been testing, testing has, at a basic level, been defined as completed when:
    A. You time has run out (e.g., hard deadline for production, you must move on to the next iteration of the project).
    B. All blocker and critical defects have been fixed. All major defects are either fixed or have a work around that the business has agreed is “good enough for now”. All other bugs that have not been fixed have been prioritized for a future release/sprint (I have worked on both Waterfall and Agile projects).
    C. User Acceptance Testing has been completed (if this applies) and the business has signed off, agreeing that the software code is acceptable to be moved to production.
    D. Depending on the environment you are working in (i.e., private industry vs. government vs. other), the Project Manager and other stakeholders have also signed off agreeing that the code is ready to be moved to production.

I don’t think I’ve ever seen a software delivery that didn’t have known bugs go into production, but there has always been agreement that the existing bugs were acceptable. The hope is, that as a QA team, we have found all of the critical/major defects, and no new defects have been introduced in last minute code fixes that may have only had a quick once over by QA.

1 Like