PM decided that all risks are evaluated and no more testing required.
You confirmed all requirements are met.
All acceptance criteria are met.
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.
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.
I think the topic should be How to complete testing for a release. We have a standard test plan that includes fixed bug regression, integration tests, regression tests, smoke tests before testing starts. Other than these, upgrade testing and performance testing are crucial for any testing and included in many test plans.
We need to continue testing as per the test plan created. After executing the entire test plan, documentation is the next part. Documents typically mean build installation instructions, release notes and everything mentioned in them should be up to date according to the builds. Thus with testing, we should consider documentation creation and review is also the part of testing.
Although testing is completed what about the time to achieve the release date. For this, we have various testing or development methodologies, Agile being latest in which a sprint timeline of 2-3 weeks is pre-defined and everything related to testing should be finished within this period only. If the software testing services providers are adhered to these methodology strictly, then everything that is pass will be consider for final release. In case anything left is, consider as left and will be pull out from current release. Such cases will be included in next version releases.
Now, the PM or Scrum master will decide if all the specifications are met or not and the build is good to go for production deployment.
So, this is the approach we follow to say that the testing is complete for a release.
What’s your way of communicating testing is completed?
Face to face conversation.I communicate what I’ve tested so far, after I managed to find answers to my main identified risks investigations. The product manager can stop the testing at any time. I can stop testing as well if I believe the risks for other problems are low; Or the problems that I would find would cost more money to dig into than the benefit of knowing them(some of those would never be fixed).
What if, it’s all wrong to claim testing is completed or done?
Testing should have a mission when you start it. You split your missions in sessions. You stop at some point…Testing is done or completed, according to some mission that you had when you started it, which came to an end.
Testing can be interrupted as well and one or more missions you have in progress might not be completed/done.
If you have no mission it can be endless.
Third, how can you measure testing is actually completed?
You don’t measure, you assess: the learning you’ve had, the risks, problems you’ve found, factors around the product, stakeholders, time, budget. The assessment can be done with others as well. Depending on your expertise you might not be confident in your own assessment.
Testing is complete when all items are verified working as designed.
Once it’s in production, the system is monitored.
In the project I’m in, emails will be sent out automatically to certain people to investigate issues. Also, the customer will complain if they think the premium is wrong or at least seems wrong. Last but not least, the audit department will raise a concern if any are found.
Testing can never be completed, but STOPPED 
Comments 