Suspension Criteria Vs Resumption Requirements

Sl.No	Suspension Criteria	Resumption Requirements
1	For a given input, if the parallel program gives output that is not identical to the output of the sequential program testing will be suspended. If any of the functionalities described in the SRS do not work, testing will be suspended.	Testing will be resumed if the parallel program outputs identical files as the sequential program and has the functionalities described in the SRS.
2	From the point 1 it’s clear that the expected result is not equal to the actual result so which is tracked as issue/ bug/ defect and report to the development team	On receive of an issue / bug / defect from the testing teaming the development team as to fix the same and release to the testing team.
3	The Quality document used by the testing team to release is “Test Release”	The Quality document used by the development team to release is “ Development Release”.
4	This is also known as “Test stop Criteria”	Resumption criteria / requirements are restart criteria for the testing activity.

0 members like this

Comment

You need to be a member of Quality Testing to add comments!

Join Quality Testing

Comment by Don Mills on May 23, 2010 at 1:37am: "“Suspension and Resumption” are about the risk that situations may arise during test execution, that threaten to make continuing with testing a WOMBAT (Waste Of Money, Brains, And Time), until things are sorted out. (It would usually be pre-supposed that entry criteria had been met, including some sort of smoke test so that the test team at least knew that the software was executable and responsive before systematic test execution begins.)

As an example of a widely quoted suspension criterion, consider a situation in which testers doing System Testing are spending 25% or more of test execution time writing up incident reports. This is an indication that the delivered software wasn’t “test-ready”. System Testing should be suspended, and the software returned to the developers for continued work.

Another example is when test execution is halfway or more through its scheduled duration, and the rate of reporting incidents and the rate of confirming fixes are still diverging. This is a sign that the developers are being overwhelmed by the volume of incident reports. Continuing to overwhelm them can only make things worse.

One more example is when platform instabilities are resulting in frequent failed executions that are not because of the quality of the software under test.

Resumption criteria resemble entry criteria, but are likely to be more focussed on proof that the specific cause of suspension has been resolved.

Suspension criteria constitute a form of project risk management for the test project. In IEEE 829 Test Plans, other risks to the test project, that are not direct risks to continued test execution (such as the risk of late delivery into testing) are dealt with under Clause 16, Risks and Contingencies.

Comment by Hitesh Shah on May 21, 2010 at 5:12pm: Hi ,
very nice and helpful , How we describe Suspension Criteria & Resumption Requirements in Test plan ?
it is same to Exit & Entry criteria ?
Give the practical example of S.No. 1 (in table)
Thanks