3.1. Phases of STLC

1. Requirement Analysis

Objective: Understand what needs to be tested and identify testable requirements.

Activities:

• Review Business Requirement Documents (BRD), Functional Specs, User Stories
• Identify gaps, inconsistencies, or ambiguities
• Determine testable and non-testable requirements
• Involve BA/Product Owner for clarification

Deliverables:

• Requirements Traceability Matrix (RTM)
• Requirements Review Report

Entry Criteria:

• BRD/FRD/User Stories are available
• QA team is identified

Exit Criteria:

• Requirement understanding is signed off
• RTM is initiated

In the Requirement Analysis phase, the primary goal is to thoroughly understand the specifications of the software that needs testing. This involves reviewing documents like Business Requirement Documents (BRD) and Functional Specifications. The QA team looks for any gaps or inconsistencies in the requirements and determines which aspects can be tested. Collaborating with the Business Analyst (BA) or Product Owner is crucial for clarifying any unclear or ambiguous points in the requirements.

The key outputs of this phase include the Requirements Traceability Matrix (RTM) and a Requirements Review Report, which help ensure that all requirements are covered in testing. To start this phase, certain conditions (entry criteria) must be met, such as having the necessary documentation available and a QA team in place. The phase concludes when the understanding of requirements is signed off and the RTM is initiated.

Think of Requirement Analysis like preparing to build a house. Before any construction can begin, the architect needs a clear blueprint and understanding of what the homeowner wants. Any gaps in the plan, like missing rooms or unclear measurements, can lead to problems later. Similarly, in software testing, identifying testable requirements upfront helps avoid issues during the actual testing phase.

2. Test Planning

Objective: Define the strategy, scope, objectives, and logistics of the testing process.

Activities:

• Identify test objectives and types (functional, regression, smoke)
• Estimate effort and resources
• Decide tools, roles, responsibilities
• Define Entry and Exit Criteria for each test phase

Deliverables:

• Test Plan Document
• Risk Management Plan
• Effort Estimation Sheet

Entry Criteria:

• Requirements baseline is completed
• Test strategy template is available

Exit Criteria:

• Test plan is reviewed and approved
• Team and environment are ready

During the Test Planning phase, the focus shifts to strategizing how testing will be conducted. This involves determining the overall goals of testing, identifying what types of tests will be performed (e.g., functional or regression testing), and estimating the resources and efforts required. Critical decisions are made about which tools will be used and assigning roles and responsibilities to team members. Additionally, entry and exit criteria for testing phases are defined to ensure a structured approach.

The deliverables for this phase include the Test Plan Document, which outlines the entire testing approach, and a Risk Management Plan that identifies potential obstacles. The phase starts once the requirement baseline is established and ends when the plan has been reviewed and approved, and the team is prepared to begin testing.

Imagine planning a big event, like a wedding. Before the day arrives, you need to make a detailed plan: choosing the venue, determining your budget, and organizing tasks. Each member of the planning team takes on a specific role, and you set clear timelines for when each aspect must be done. This structured planning is essential to ensuring that the event runs smoothly, just as Test Planning does for testing a software product.

3. Test Case Development

Objective: Design detailed test cases based on requirements and prepare test data.

Activities:

• Write manual test cases or automated scripts
• Identify and create test data (dummy inputs)
• Review test cases for completeness and coverage

Deliverables:

• Test Cases & Test Scripts
• Test Data
• Review Comments/Sign-off

Entry Criteria:

• Test plan is approved
• RTM is finalized

Exit Criteria:

• All test cases are reviewed and approved
• Test data is prepared

In the Test Case Development phase, the QA team creates specific tests that will verify if the software meets its requirements. This includes writing manual test cases or developing automated testing scripts. The team also creates test data—dummy inputs that will be used during testing to simulate real-world scenarios. After crafting the test cases, they are subjected to a review process for completeness and coverage to ensure all aspects are tested.

Successful completion of this phase results in approved Test Cases & Test Scripts, alongside prepared Test Data. This phase starts once the Test Plan has been approved, and it concludes with all test cases being reviewed, approved, and test data being ready for execution.

Think about baking a cake. You wouldn't just throw ingredients together randomly; you need a recipe (test cases) that outlines each step (activities) and specifies what you'll need (test data). Before you start baking, you check that you have everything and understand the process—it’s the same meticulous preparation that ensures a successful testing process.

4. Test Environment Setup (Parallel Phase)

Objective: Prepare the hardware/software setup required for testing.

Activities:

• Configure test servers, databases, staging environments
• Install required tools (e.g., Selenium, JIRA, TestRail)
• Validate environment readiness (smoke test)

Deliverables:

• Environment Validation Report
• Access credentials and URLs

Entry Criteria:

• Environment requirements are known
• Hardware/software is available

Exit Criteria:

• Test environment is stable and accessible

The Test Environment Setup phase involves preparing all the necessary hardware and software needed for testing. This includes configuring test servers, databases, and staging environments where the software will be tested. Key tools required for testing, such as Selenium for automated testing, are also installed during this phase. Finally, a 'smoke test'—a preliminary check to ensure the environment is ready for detailed testing—is conducted.

Deliverables from this phase include the Environment Validation Report and access credentials. It starts only when environment requirements are clear and available resources are in place, and ends when the environment is tested for stability and accessibility.

Consider setting up a new classroom for students. You need to arrange the desks, install technology like projectors, and ensure everything is functioning before the students arrive. A 'dry run' might be similar to a smoke test where you check that all equipment works. Only when everything is set up and functioning well can the teaching (or in this case, testing) begin.

5. Test Execution

Objective: Execute test cases and report any defects found.

Activities:

• Execute manual/automated tests
• Record actual results and compare with expected outcomes
• Log defects in tools like JIRA
• Retest after defect fixes

Deliverables:

• Test Execution Report
• Defect Report & Bug Tracker Updates
• Updated RTM

Entry Criteria:

• Test cases and test data are ready
• Test environment is up and running

Exit Criteria:

• All test cases executed
• All critical bugs are fixed or deferred with approval

In the Test Execution phase, the actual testing of the software takes place. The previously developed test cases are executed, whether manually or via automated systems. As tests are executed, the results are recorded, and any defects or bugs found are logged in tracking tools like JIRA. After fixes are made for any defects, those tests are run again (retesting) to ensure that the issues have been resolved.

The deliverables from this phase consist of the Test Execution Report, Defect Report, and updates to the Requirements Traceability Matrix (RTM). This phase begins when all test cases and corresponding test data are ready and the test environment is operational, concluding once all tests are executed and critical bugs are addressed.

Picture a team conducting a performance review. Each person has a checklist of criteria to evaluate their colleague (like executing test cases). They make notes about observations and areas needing improvement (logging defects). After feedback is provided, they might need to check if the areas needing improvement have been adequately addressed in follow-up meetings (retesting our solutions). This process ensures that everything important is scrutinized and corrected.

6. Test Cycle Closure

Objective: Formally close testing activities, assess metrics, and document learnings.

Activities:

• Ensure all test cases are executed and defects addressed
• Evaluate test coverage and quality metrics
• Conduct retrospective or post-mortem analysis
• Archive testware for reuse

Deliverables:

• Test Summary Report
• Lessons Learned Document
• Final RTM

Entry Criteria:

• Test execution is complete
• Defect status is resolved or accepted

Exit Criteria:

• All deliverables are submitted
• QA sign-off is obtained

The Test Cycle Closure phase marks the conclusion of the testing process. It involves confirming that all test cases have been executed and any defects have been addressed satisfactorily. Metrics related to test coverage and overall quality are assessed to judge the testing efforts. A retrospective or post-mortem analysis is conducted to assess what worked well and what could be improved. Finally, all testing artifacts are archived for future use.

Deliverables from this phase include a Test Summary Report, a Lessons Learned Document, and a finalized Requirements Traceability Matrix (RTM). The phase begins after the test execution is complete and defects are settled and ends when all necessary documentation is submitted and the quality assurance team has provided their sign-off.

Imagine finishing a big project, like organizing a community festival. Once the event is over, you gather the team to evaluate everything that went well and what could be improved (post-mortem analysis). You tally the attendance and satisfaction levels and create a report to capture your findings for future events (Test Summary Report and Lessons Learned Document). Just as in project management, closure in testing ensures that the effort is formally wrapped up and insights are captured for improvement.

Importance of Entry & Exit Criteria

Entry Criteria: Set of conditions that must be met before a test phase can begin.

• ✅ Helps avoid incomplete or rushed testing.

Exit Criteria: Conditions that must be fulfilled before moving to the next phase or ending testing.

• ✅ Ensures quality control and formal handoff.

Example: You shouldn't begin test execution unless all test cases are reviewed and test data is available.

Entry and exit criteria are critical components of the STLC that help maintain quality and structure throughout the testing process. Entry criteria specify the conditions that must be met to start a new testing phase, helping to prevent incompleteness or rushing into testing without proper preparation. Exit criteria define what has to be accomplished before concluding a phase or moving on to the next, ensuring that all necessary steps have been completed and that quality is maintained.

Think of entry and exit criteria like the rules of a game. Before you can start playing (entry criteria), you must have all your players in place and understand the rules. Once the game is done, you have to ensure everyone understands the outcome before calling it quits (exit criteria). This helps everyone operate smoothly and ensures that no step is overlooked.

--