The Levels Of Test Execution

Test execution is nothing but executing the selected number of test cases. We can execute them either manually or using automation tools . We have different levels in this execution.The Application under test undergoes different levels of test cases and then gets released.We are going to discuss about these test execution levels now. The levels of Test execution are 

• Smoke Testing
• Confirmation Testing
• Re-Testing
• Regression Testing
• Final Regression Testing
• Sanity Testing

Smoke testing:

Practically the test execution process I sstarting with smoke testing to estimate the stability of that build. In this smoke testing, testers concentrate on particular factors for the coverage of basic functionality in that build. Smoke testing checks whether the build is understandable, operatable, observable, controllable , consistent in working, simplicity is available or not, whether the build is mainatainable and it is automatize or not. The above like smoke testing is also known as testability testing or build acceptance testing or verification testing or tester acceptance testing or octangle testing. The smoke testing is called octangle testing because it checks mainly 8 attributes of the build.

Comprehensive Testing:

It is also known as detail testing. After completion of smoke testing , Testers conduct detailed testing to detect defects in the application.When a test fails and we determine that the cause of the failure is a software defect , the defect is reported, and we can expect a new version of the software that has had been defect fixed. In this case we need to execute the test again to confirm that the defect has indeed been fixed or not. This is known as confirmation testing.In this level, testers are executing all the test cases either in manual or in automation as test batches or test suites. Every test batch consists of a set of dependent test cases. In this Test execution has batches on the build, the testers prepare test log document with three types of entries

• Pass (The expected values matches the actual values)
• Fail (The expected values doesn’t match the actual values)
• Blocked (postponed due to the lack of time).

Re-Testing:

During comprehensive testing the testers are reporting the mismatches in between our build actual output values and expected output values as default reports. After receiving defect reports from testers the developers are conducting a review meeting to fix defects. If our defect is accepted by the developers then they perform changes in coding and then they will release modified build with release note. The release note of a modified build describes the changes in that modified build to resolve reported defects. This is called retesting.

Regression Testing:

Testers are going to plan regression testing to be conducted on a modified build with respect to the release note. The main reason or approach for this regression testing is, when testers receive modified build along with the release not from the developers. They apply sanity testing on that modified build. They ruin that select test case on modified build to ensure the correctness of modification without having side effects in that row.Regression testing are executed when ever the software changes, either as a result of fixes or new or changed functionality.It is also good idea to execute them when some aspect of the environment changes .

Final Regression Testing:

After completion of entire testing process the testing team concentrates on final regression testing. This level of testing is also known as Postmortem testing or Pre- acceptance testing. During this final regression testing if testers find any defect. That defect is called as Golden defect of Lucky defect. After resolving all the Golden Defects, The testers will concentrate on User Acceptance test along with developers.

Sanity Testing:

After receiving a software build, with minor changes in code, or functionality, Sanity testing is performed to ascertain that the bugs have been fixed and no further issues are introduced due to these changes.The goal is to determine that the proposed functionality works roughly as expected. If sanity test fails, the build is rejected to save the time and costs involved in a more rigorous testing.The objective of sanity testing is "not" to verify thoroughly the new functionality, but to determine that the developer has applied some rationality (sanity) while producing the software. For instance, if your scientific calculator gives the result of 2 + 2 =5! Then, there is no point testing the advanced functionalities like sin 30 + cos 50.