when do u know that testing is over?

When the functionality is done , we can say almost 90% of the testing is done

hi, thanx for ur reply but i'm still not satisfied with the answer...can someone ellaborate the answer more professionally please?!!

when the actual requirements are met and system function properly with no bugs then we stop testing

to obe honest the answer to this question is varied depending upon which stage of testing you are within. Ultimately Testing is a subset of QA - and the QA standards will state what criteria satisfy a testing stage to be deemed to be completed. These standards could be known as 'exit criteria' and when these criteria are met then the test cycle can be deemed to be complete. (Test strategies / plans and specs will ellaborate these areas)

This kind of question is used as a trick question. The person asking may be looking for "Testing is never done".

Usually the QA team is squeezed for time so you are forced to do the best given the time you have. So while you "finish" testing because the due date was reached, the best answer is to say that "Testing is never done".

My 2 cents....

When cost of the budget and regression testing is over then we say that test is completed.

Are we DONE is a decision, not a predetermined event !!

We can consider it as "OVER" based on the following conditions :

Level of Confidence > Customers Confidence

(or)

Known Bad:Tests Failed + Unknown:Tests not run

< Known Good:Tests passed

The easiest way to decide when to stop testing is to create a Defect Metrics. Its a graph which is plotted on x - y axis....x being Build Nos. and y being No. of defects found.You plot the no. of defects found in each build in this graph and seeing the trend u can evalute when the plot comes down n becomes a stagnent one...

1.In real testing never ends because no software can be error free. But so as to get satisfaction to testers we can say that when all the test cases written by testers completes and all of them get fixed and retested we can say testing is over.

2.When release date of software comes then managers forced testers to complete testing that time it forcefully completes.

 Testing is endless. We cannot test till all the defects r  removed.

common factors in deciding:

1.Deadlines(release, test deadlines)

2test budget depleted

3.bug rate falls below a certain level

4.coverage of functionality reaches a certain level

If the bug rate comes down and there were no critical and major defects

when expected result = actual result

Developer will complete the project and it will be sent to tester for testing defects-tester open the project and validates wheather it is as per the client requirement- if pass (delivered to client).- if failed (sent to developer and he'll fix)- again tester will test . cycle continues till expected result =actual result(this confirmation will be given be tester)

Rgds

Kanchana

First of all it should know that TESTING is a endless process. It have to stop at that when  We cannot test it at 100% but we try to do it at maximum level.

there are some common factors where testing have to stop:

(I).Deadlines(release, test deadlines)

(II)test budget depleted

(III).bug rate falls below a certain level

(IV).coverage of functionality reaches a certain level

 

Whn the exit creteria is met thn testing can b said to b over

When the bug rate decresres if we have completed tested the major functionality of  a Product we stop Testing

When u r out of budzet............Out of time..............have executed all testcases...........when u r finding no new bug afterall..........u may decide that testing is over.

Testing is over , when all the testcases you have checked was correct, and working succesfully, and when the project ends with out errors.

Hi,

100% testing is not possible. But there are some constraints to know when to stop testing.

• Deadlines (release deadlines, testing deadlines, etc.)
• Test cases completed with certain percentage passed
• Test budget depleted
• Coverage of code/functionality/requirements reaches a specified point
• Bug rate falls below a certain level
• Beta or alpha testing period ends

Regards

Prasad

At the time of creation of Test Plan itself we are going to define the exit criteria. If the test results meets the exit criteria, we can say that the testing is over.

For example, let us say the the exit criteria is 1 bug per 100 function points. Our project is of 1000 Function points. So the allowed limit is 10 bugs. When we are satisfied with the testing done, without the knowledge of the tester we can introduce 10 bugs and give it to testing. If the tester is able to find out all the 10 bugs, we can say the testing done was at the aceptable limit. If the testing team is able to identify less than 10, it shows that some more testing is to be done.

Normally there is a exit criteria defined in the Test Plan. When the system meets all the exit criteria then we can say tyesting is done. But sometimes it happens that we are not able to meet the all the exit criteria but due to time constraints we need to release the product then we can say that testing is done but with a remark that still the particular specification is not met.

In Test Plan, Exit Criteria specified when to stop testing considering exit criteria is based on
1) between the build release If Bug ratio comes down and there were No critical and medium bugs
2) 100 % coverage is over as per the Test case document or Traceability Matrix
3) As per the Release Date mention in the agreement with client
4) Out of budget
5) When managers says stop testing
6) Alpha or beta testing is over

1) When the bug flow rate is minimum or zero.
2) When all the features / functionalities are covered
3) Dead line is near / release date is getting closer --> Stopping the testing
4) Budget over flow --> stopping the testing.

This can be difficult to determine.Many modern software applications are so complex and run in such an interdependent environment that complete testing can be never done.Common factors in decidingwhen to stop testing are:
Deadlines eg: release deadlines ,Testing deadlines;
Test budget has been depleted;
Test cases completed within certain percentage passed;
Coverage of code ,functionality,or requirements reaches a certain point;
Bug rate falls below a certain level or;
Beta or Alpha testing period ends.

Testing is endless process, still testing is over on the basis of below criteria:

1. All the test cases are executed at-least once.
2. Complete coverage of all the scenarios.
3. End of project timeline.
4. No more budget for the project.
5. Defect or open items are on degree of acceptable and confirmed by business.

Regards,
Pankaj B

when the predefined criteria 'cut-off' is achieved, for example the coverage achieved the required % or the number of open bugs is up to the defined level

Basically It depends on your project's exit criteria, when you meet the exit criteria then you can stop testing.

1, When high priority bugs are fixed
2, the testing budget is exhausted
3, the project duration is completed
4, deadlines
5, maximum number of bugs successfully executed
6, after alpha or beta testing

Each company/client will have their own quality gates for software applications. The exit criteria that was mentioned in previous posts is primarily based on this 'quality gates.' We have different types of bugs - performance, functional, UI, database, integration etc. Some may be critical some may be minor enough to be pushed into production site. Based on the severity and business priority, each company will set their own quality gates. Again the business priority depends on the audience and goal of the application under development. Let's say you are testing a casual browsing site - say MSN (sorry if you dislike it!) - wherein the look and feel (UI) and performance are of prime importance. Since its only a casual browsing site, security ranks fourth or 5th, but still we need to make sure no one is hacking into the server and messing it up. Priority stems from business point and severity stems from technical viewpoint.

So generally I would say testing is complete when:

- showstopper (bugs like - application is crashing each time I click on so and so link/icon; or unable to login to email account etc.), major, medium bugs are closed, and only minor UI bugs like spellings, etc are left, you can stop testing. If you go back to my casual browsing site example, websites display ads to get money. Some are displayed on the home page while others are on the interior pages. So business might mention in quality gates document that all home page ads must work (because it brings in more money). During testing you found that an ad banner on home page isn't navigating to its site or navigates to a wrong site becomes a high priority bug but has low severity. Since it was mentioned in quality gates doc, testing is incomplete since you need to re-test the bug before you sign off on testing.

- all requirements have been tested

if there is neither quality gates doc nor an exit criteria in test plan, you can stop testing when all the features have been tested, and when critical, major, medium bugs have been fixed.

If this were an interview, you could summarize what I just wrote : it depends on the exit criteria set in the test plan or some companies have a quality gates doc in place that details the exit criteria. If neither exist, I would stop testing when all the features have been tested, and when critical, major, medium bugs have been fixed. Simple!

When the functionality of the application is working properly and the user requirements are fully satisfied.

When the bug rate falls bellow certain level
When are reaching to dead lines.

When the budget is depleted.

When the Beta and Alpha testing period ends

We can arrive at the decision of Testing is over based on the following criteria:

* Level of Confidence on the functioning is greater than the Customers Confidence.

* Known Bad (i.e.Tests Failed) + Unknown (i.e.Tests not run) is less than Known Good (i.e.Tests Passed)

Teating prosses depends on software company but still has a guideline. When produce meets with it requirement, exit
criteria, also sometime over budget, time is over but test is not finish.