What is Entry and Exit Criteria in Software Testing Life Cycle?
Testing is an essential element of the increasingly competitive technology industry. It is an integral part of any Software Development Life Cycle or SDLC and can impact the result of all aspects of the project, such as time, cost, and quality.
STLC, or Software Testing Life Cycle, is a series of operations carried out by the testing team to ensure the quality of the software or product, and it solely addresses the testing phases. Knowing the entry and exit criteria for STLC is essential. This defines testing areas and the activities performed by testers, allowing an accurate estimation of the time required for testing every site.
Additionally, the entry and exit criteria of STLC help identify all the critical defects that need immediate attention in a software project.
This article provides a detailed explanation of the entry and exit criteria in STLC.
Table Of Contents
- 1 Software Testing Life Cycle (STLC)
- 2 Entry Criteria in STLC
- 3 Exit Criteria in STLC
- 4 Phases of the Software Testing Life Cycle(STLC)
- 5 Requirement Analysis
- 6 2. Test Planning
- 7 3. Test Case Development
- 8 4. Test Environment Setup
- 9 5. Test Execution
- 10 6. Test Cycle Closure
- 11 Conclusion
Software Testing Life Cycle (STLC)
The STLC is a holistic process that includes software testing, verification, and validation and has six stages:
- Requirement analysis.
- Test planning.
- Test case design and development.
- Test environment setup.
- Test execution.
- Test cycle closure.
Besides these predetermined STLC metrics, other components for the cycle completion requirements, such as test strategy, test execution, test coverage, test cases, and test case report, are also included in the cycle.
Entry Criteria in STLC
Entry criteria are conditions that must be met for a task to be performed; if any of these factors are missing, the job cannot be completed.
Determining the time window in which the entry criterion item will be ready to begin the procedure is crucial. For example, the following prerequisites must be satisfied to start the test case development phase:
- You should have access to the required document.
- It is necessary to have a thorough understanding of the application flow.
- The test plan document must be completed.
Exit Criteria in STLC
Exit criteria for STLC phases are actions or tasks that must be finished before the current phase is over and the next one begins. Hence, exit criteria requirements must be fulfilled to end the STLC phase.
For example, the following requirements must be fulfilled for the test cases development phase to be completed:
- Test cases must be written and examined.
- Test data needs to be prepared and recognized.
- If necessary, a test automation script must be ready.
Phases of the Software Testing Life Cycle(STLC)
Every STLC Model has the following six key phases:
The first stage of the cycle is requirement analysis. The testers determine all the elements to be tested at this juncture. To thoroughly comprehend all criteria, the quality assurance specialists will communicate with all stakeholders, including system architects, end users, and business analysts.
After the requirements have been determined and described, they should be divided into functional and non-functional testing. Priorities for testing ought to be established.
The QA team engages in three main tasks during this phase. The following is a description of the events.
1. Setting the Scope
The QA team examines the requirements and the specifics of the environment where testing is to take place. The QA team categorizes the testing scope into distinct functional components. The team also determines the testing kinds that must be carried out, such as smoke, sanity, practicality, and regression. The group gathers information regarding the testing priorities and concentrates on the order of modules that need to be validated. If modules conflict and functionality is not transferred over with other modules, it also reveals the requirement faults.
2. Analyzing automation
The QA team evaluates the level of automation needed for regression testing during the requirement phase. If automation is added to the scope, the team selects which tool to utilize, which functionalities will be covered as automation, the timeline, and the resource commitment required for automation development. After this evaluation, the QA team distributes the Automation Feasibility Report to various stakeholders for approval.
3. Develop RTM
Documenting the connections between the requirements and the work items created to implement and validate those requirements is the process of requirements tracing. All requirements from the requirement analysis are documented in the RTM, along with their traceability. At the end of the life cycle, everything is published.
- Availability of the requirements document (both functional and non-functional)
- Acceptance criteria defined.
- Availability of the application architecture document.
- Signed off RTM
- Test automation feasibility report released by the client.
- Automation feasibility report (if applicable).
2. Test Planning
A test plan specifies the technique to test an application, the resources to be employed, the testing environment, the testing parameters, and the timing of the testing operations. Writing a test plan will typically fall under the purview of the quality assurance team lead.
The following things are included in a test plan:
- The paper containing the test plan is introduced.
- Hypotheses are made during the testing of the application.
- A list of test cases is utilized to evaluate the application.
- A list of the features that need testing is created.
- The software testing strategy is devised.
- A list of products that require testing is curated.
- The equipment for application testing is set aside.
- Any dangers present while conducting the exam are described and discussed.
- Requirements documents
- Requirement traceability matrix
- Test automation feasibility document
- Approved test plan/strategy document
- Effort estimation document signed off
- Test plan/strategy document
- Effort estimation document
3. Test Case Development
Preparing test cases for a particular unit is the primary goal of this phase. The QA Team creates test cases as soon as the test plan is complete. These structural and functional test cases cover the functionality, points of verification, and validation indicated in the test plan. The QA team writes the test case using a step-by-step process during this stage. A business analyst reviews the test case and, if necessary, revises it before signing it off. The QA team prepares the Test Data based on preconditions after the test cases are available.
The three tasks performed in the Test Case Development phase are as follows:
1. Identifying Test Scenarios
A complex system may be tested and evaluated more easily with scenarios. The techniques listed below facilitate the development of solid procedures:
- Determine potential users, their goals, and the actions they might take.
- List possible instances of system misuse while evaluating users using a hacker’s perspective.
- Give a rundown of the system’s activities and how it responds to requests like these.
- Create end-to-end tasks to verify the benefits you listed.
- Check out articles about similar systems’ behavior.
- Examining criticisms of the items’ pro competitors.
2. Writing Test Cases
A test case is a document created for a specific test scenario to verify compliance against a particular requirement. It contains test data, preconditions, expected results, and post-conditions.
Test execution begins with the Test Case. The application has a clear consequence and exits the system at some end point after applying input values, sometimes referred to as the execution post-condition.
3. Test Data Preparation
Tests on test software are run using test data. The test data must be exact and comprehensive to find the flaws.
It is then followed by a step-by-step strategy, described below, to achieve these three goals.
- Specify the resources or requirements for tests.
- List the parameters or functionality that will be tested.
- Establish priority test parameters.
- Choose the test conditions.
- Calculate the predicted outcome of processing test cases.
- Construct test cases
- Record the test circumstances.
- Take a test
- Verify and amend test cases in response to revisions.
- Requirements Documents
- RTM and test plan
- Automation analysis report
- Reviewed and signed test Cases/scripts
- Reviewed and signed test data
- Test cases/scripts
- A baseline is created.
- Test cases/script data.
4. Test Environment Setup
The environment is set up after test cases are developed and designed. The hardware and software are chosen to test the application or product. The creation of the test environment and test issues can happen simultaneously. Alternatively, the client-side can create this ecosystem by supplying the necessary hardware and software.
The test environment contains components that support test execution with software, hardware, and networks configured. The configuration must closely resemble the production environment to locate any configuration-related problems.
Actions Taken to Setup the Test Environment
In this phase, the following tasks are completed.
- Design Test Environment
For the design of a test environment, the following criteria are crucial.
- To take backups, ascertain whether the test environment has to be archived.
- Ensure the network settings are correct.
- Identify the databases, server operating system, and other necessary components.
- Determine the number of licenses needed by the test team.
2. The Environment’s Setup
Prepare a list of the software and hardware needs for the setup after analyzing the environment requirements. Get the go-ahead from the appropriate authorities to build up the test ecosystem and establish access to it.
3. Smoke testing
A brief round of smoke testing should be carried out after the environment is set up and the QA team has access to it to validate the stability of the test environment build. The QA team can proceed to the next stage if the results match expectations; otherwise, they can point out any discrepancies and wait for deployment after corrections.
- Availability of system design and architecture documents
- Availability of the environment setup plan
- Working on the environment setup as desired
- Completion of the test data setup
- Successful smoke test
- A ready environment with test data setup
- Results of the smoke test.
5. Test Execution
The test execution phase involves testing every error, problem, and defect by the test plans. Use is made of the test cases and scripts. Flaws are mapped to test claims (RTM) in the requirements traceability matrix. Any discrepancies are reported to the developers for correction, and retesting is conducted post that. Updates are made to the requirement traceability matrix. The QA team performs AUT validation based on written test cases, comparing the results step-by-step to what was estimated.
For a test execution procedure, the following elements must be taken into account:
- Select a portion of the test suite to be run for this cycle based on risk.
- Give testers responsibility for executing each test suite’s test cases.
- Run tests, file problems, reports, and record test status continually.
- As they appear, fix blocking problems.
- Revisions of daily status updates, assignment changes, and goals and priorities.
- Analyze the results and progress of the test cycle.
The following are the crucial tasks for this phase:
1.System Integration Testing
The actual product or AUT validation begins here. System Integration Testing (SIT) is a black box testing method that assesses the system’s conformance with created test cases and specifies requirements.
To assure quality, the QA team looks for as many flaws as possible during SIT. The primary goal here is to find as many bugs as possible.
2. Defect Reporting
The QA team discovers various problems while conducting SIT, and they must be notified to the relevant team members. Reporting also makes it simpler to follow the status of faults. The group continues to work on the flaws.
3. Defect Mapping
Analyzing the errors in the product and creating an accurate defect report are both aided by it. Once a problem has been discovered and recorded, it needs to be linked to the relevant failed or blocked test cases and the accompanying requirements in the requirement traceability matrix. The defect reporter is responsible for this Mapping. Once the test cases and conditions have been aligned with the issue, stakeholders can review the information. Depending on its priority and severity, they can then decide whether to correct or postpone the defect.
Retesting involves running a failed test against the AUT to see if the issue has been fixed. After a repaired flaw, retesting is done to check the scenario under the same environmental settings.
5. Regression Testing
System integration testing can depend entirely on test cases and requirements after all defects are in closed, delayed, or rejected status. None of the test cases are in progress, failed, or not-running class. A single round of rapid testing is necessary to ensure functionality is not compromised due to coding modifications or defect corrections.
Rerunning tests that have been affected by code changes is the black box testing technique known as regression testing. These tests should be run as frequently throughout the software development life cycle.
- Baselined RTM, Test Plan, and Test case/scripts are available
- The test environment is ready
- Test data setup is done
- Unit/Integration test report is available
- All tests planned are executed
- Defects logged and tracked to closure
- Completed RTM with execution status
- Test cases updated with results
- Defect reports
6. Test Cycle Closure
The test closure phase is the concluding phase of the STLC. All of the functional and non-functional tests have been finished and closed at this point. The testing team will review the activities carried out in each phase at this last stage. The lessons discovered during each step will be recorded in other testing operations on comparable apps.
The following are used to close the testing cycle:
1.Test completion reports
Test completion reporting presents the test metrics to the stakeholders in a summary format. They can make an educated judgment as a result of this.
A good test completion report describes the software’s level, assesses any unresolved risks, and denotes its quality.
2. Test Completion Matrix
After testing, several matrices are gathered to create the test rereports.
3. Test Results
Test results should be saved and produced along with the test cycle closure documents to assist in the completion of test execution while executing a test case, retesting faults, and completing regression test cases.
Examples of articulates are screenshots, database query results, recordings, and log files.
- Testing has been completed
- Test results are available
- Defect logs are available
- Test closure report attested by the client
- Test closure report
- Test metrics
This article makes the importance of having valid entry and exit criteria for a test process prominent. These criteria ensure that sufficient tests are executed during all testing phases to meet the Quality Program requirements.
Entry and exit criteria are meaningful principles for the software testing life cycle. These entry and exit criteria can undoubtedly prove helpful for any effective functioning of the software testing system. It is necessary to define its benefits and disadvantages before using it. There are many exit criteria available in STLC, but not all the criteria are reasonable to operate simultaneously. It is a good practice to choose one criterion at a time that is suitable for your project and testing environment.
Want to know more about end to end testing and enhance the experience using AI? Check out Testsigma and its services, your all from one source.