How do you know when to stop testing?

Acceptance Criteria - All projects has some acceptance criteria to satisfy its applications.

Cost - Project cost also should be a consideration.

Time - We want to complete the testing within the priscribed time limit, else it leads to increase in cost.

We need to complete the execution of all the test cases. We need to combine these tree factors to reduce stop the testing. We can't stop if the project exceeds the cose that allocated or time that given if we are still finding Major defects in this.

In this factors mistakes are from testers itself. We may know that applications performance while starting the testing it self. At that time itself we need to reject the Application for redevelopment.

We can stop testing when all the Standard of testing are aquired and there is no deviation. Also if any specific requirement of  client is there and if that also matches to the maximum say 90-95%, if not 100%, than we can stop testing.

We can stop testing when below things are fulfilled:-

1) When our Software/Product meets customer requirements with least bug open.

2) when we feel that s/w is bug free ( not 100% except some known issue and hidden bugs)

3) When dead line pre-ponds.

4) Ideally one week before dead line......in order to reduce last moment confusion.

5) If some open bugs that need to be resolved in this label but needs more budget to resolve , then they should be kept as known issue and should be resolved in nxt label and testing should be stopped if point 1 and 2 are fulfilled.

Depending upon project deadline means in what time period a specific project is going to complete ,than testing will be performed whether the project has achieved  its defined standards or not ,proper feedback is provided than only we can stop testing.

When the defect rate fall below certain specified level in respect to the project than we stop testing.

Its some Sort Of Impossible To Answere Bcz No One Can assure you about S/W performance in certain condition.

but we can stop testing at time of deployment or implemtnting. it also realted with cost n complexity of s/w.

if the process is too long and complex it need more n more testing after each module.

Its some what impossible to answere this qstn bcz no one can assure us abt the working of S/W in certatin condition.

but we can stop testing of s/w at time of deploying or impelmenting.

and also its realted with cost  and compllexity of project. if the process is to long n complex it need more n more testing after each module.

Today as project are being more and more complex, we can't wait for proper time to come for beginning the testing process. I feel testing should be started from very basic stage with proper checklist of Client's requirement. More client interaction always been a trump card for justifying testing process.

Keeping the constrain of time, cost, scope in mind its all about what is the best quality we can achieve. or if the expectation on quality is rock solid then how far we can tolerate on other factors i.e time and cost to decide on when to stop testing.

QA manager should define Test Exit criteria with the consent of all the stakeholders of the project in the Test Plan and get it approved.
Test Exit Criteria:
e.g.
All the planned deliveries are ready
x % of the test cases should be passed
Bug rate falls below certain level or
100% or x% Sev 1 bug should be closed
100% or x% Sev 1 bug should be closed
85% or x% Sev 1 bug should be closed
75% or x% Sev 1 bug should be closed
Open bugs should be documented as the known issues in the documentation

Finally its all about optimization of the factors time, cost, scope and quality and decide on when to stop testing.