Software Testing Lifecycle

Software Testing Lifecycle:

• STLC is a structured sequence of phases specifically designed for managing and
organizing software testing activities, ensuring that every aspect of the software is
checked against its requirements and quality standards.
• It provides a framework for systematically validating, verifying, and documenting
the quality of software through defined steps such as requirement analysis, test
planning, test design, test environment setup, test execution, and test closure
Phases of Software Testing Lifecycle:
• Requirement Analysis: Understand what needs to be tested.
• Test Planning: Define strategy, objectives, resources, and schedule.
• Test Design: Create test cases, test data, and set up the environment.
• Test Environment Setup: Prepare hardware and software for testing.
• Test Execution: Carry out tests as per the plan, log results and defects.
• Test Cycle Closure: Analyze results, report, and learn for the future.

Example: Suppose a team is testing an e-commerce site. The team begins by studying requirement
specifications (login functionality, payment options), then devises a plan, designs tests (positive and
negative login scenarios), sets up the test environment, executes the tests, and finally, documents the
results and closes the cycle.
Test Planning:
In this phase, the test manager or lead creates a comprehensive document known as the test
plan, outlining the strategy, scope, approach, resources, and timetable for the testing process.
The test plan also anticipates possible risks, ways to minimize those risks, and sets clear
criteria for when testing should start and end.

Key activities:
• Define what features and functions will be included/excluded from testing.
• Identify testing objectives (e.g., verify all login scenarios)
• Estimate required resources (staff, tools, hardware) and assign roles.
• Determine schedule, test deliverables, and reporting procedures.
• Assess risks and mitigation strategies.

Example:
A test plan for an online shopping app specifies testing payment gateways, excludes third-
party social media logins, requires three testers (one focused on automation), sets a two-
week schedule, and uses Selenium and JIRA for test automation and defect tracking
Test Design:
• Test design is the bridge between test planning and execution. During this phase, QA
teams translate test requirements and objectives into detailed, actionable test cases. Test
data, test scripts (for automation), and a requirements traceability matrix are prepared.
Each test case describes steps to validate a feature, expected results, and the test data
required.

Key activities:
• Analyze requirements to design exhaustive test scenarios.
• Write step-by-step test cases covering positive, negative, and edge cases.
• Create or identify the test data needed for execution.
• Review test cases for completeness and accuracy.

Example:
• For a login system, test cases might include entering valid credentials (should log in),
leaving the password blank (should show an error), using a special character in the
username, etc.
Test Execution:
Test execution is where planned test cases are actually run in the designated test
environment. Testers compare the actual results with expected ones and document any
differences as defects or bugs. All results are tracked, with successful tests marked as
“Passed” and those with discrepancies as “Failed”.
Key activities:
• Execute manual and automated tests as per the schedule.
• Document and report results for each test case.
• Identify, log, and track bugs or defects in a designated tool.
• Retest after development fixes; perform regression testing to ensure old features remain
unaffected.
Example:
Upon executing a payment test case, the tester notes that the total price is calculated
incorrectly after adding a discount code, logs the defect, and retests after the developer's fix.
Test Cycle Clouser:
• Test Cycle Closure is the final and crucial phase in the Software Testing Life Cycle (STLC). This
stage occurs after test execution is completed—when all planned test cases have been run, major
defects have been addressed, and test objectives have been evaluated.

What Happens During Test Cycle Closure?

Evaluating Test Completion:
Assess whether all testing objectives were met and all test deliverables are complete. Ensure all
planned test cases have been executed, and unresolved defects are documented and communicated.
Defect Analysis and Documentation:
Review and analyze bugs found during testing. Prepare a final list or report of open and closed
defects, their severity, and business impact.
Reporting:
Prepare and share detailed test summary reports. This report includes testing scope, coverage, defect
distribution, test execution statistics, lessons learned, and improvement recommendations.
Knowledge Transfer & Archiving:
Store all test artifacts (test cases, data, logs, reports) for future reference. Conduct sessions with the
team to share insights and best practices that can improve future projects.
Formal Sign-off and Closure:
Obtain formal approval or sign-off from stakeholders to close the testing phase, indicating that the
product is ready for release or next steps.
Why is Test Cycle Closure Important?
• Ensures accountability and transparency regarding the test work completed.
• Provides a foundation for continuous improvement by learning from issues, delays, or missed
defects.
• Serves as an official record that testing has concluded and the software product is ready for delivery
or deployment.
What Is a Test Plan Walkthrough?
A Test Plan Walkthrough is a formal or informal meeting where the testing team,
developers, business analysts, and stakeholders review the test plan for a project.
It happens before execution of actual testing.
The main goals are to:
• Ensure test coverage for all requirements.
• Clarify responsibilities, timelines, and processes.
• Identify any gaps, ambiguities, or risks early.
• Collect suggestions for improvement.
This collaborative review helps align the team and secures agreement on the testing
approach before execution begins.
Practical Tips for Identifying Core Items in a Test Plan:
1. Scope of Testing:

Defines what features, modules, or functionalities will (and won’t) be tested.

How to Identify:
Review the software requirements/specifications.
Discuss with business analysts and developers.
Include both functional (login, payment) and non-functional (performance, security)
features.

Example:
If testing an e-commerce site, the scope includes registration, product search, shopping cart,
and payment. Exclusions might be third-party integrations not yet delivered.
2. Objectives of Testing:
Description:
States the goals of testing—what you want to achieve.

How to Identify:
Refer to project goals and quality expectations.
Think about what defines “success” (e.g., user must be able to checkout seamlessly).

Example:
“To confirm all payment gateways process transactions correctly and securely.”
3. Resources and Roles:
Description:
Lists the team members, their responsibilities, and necessary tools or environments.

How to Identify:
Map tasks to individuals based on expertise.
Account for external stakeholders (e.g., business owner for UAT).
Specify test tools or automation resources.

Example:
Alice: Manual functional testing
Bob: Automation scripting with Selenium
DevOps: Test environment setup
4. Test Schedule:
Description:
Timeline for each test activity: planning, design, execution, defect retest, reporting.

How to Identify:
Align with the project development timeline.
Consider dependencies (e.g., waiting for code freeze).
Include buffer times for retesting and reporting.

Example:
Test Case Design: July 1–5
Test Execution: July 6–12
Defect Retesting: July 13–14
5. Test Data:
Description:
Information required to execute tests: sample user accounts, product SKUs, input values.

How to Identify:
Review requirements for necessary input values.
Involve developers to generate or anonymize realistic data.
List positive, negative, and boundary test values.

Example:
Testing login:
Valid: jane@[Link] / correct password
Invalid: blank username, wrong password, SQL injection string
6. Entry and Exit Criteria:
Description:
Conditions to start or stop testing activities.

How to Identify:
Entry: What must be ready (code freeze, test environment up)?
Exit: What defines test completion (all critical defects closed)?

Example:
Entry: User registration build is complete, test data is ready.
Exit: All blockers resolved, all test cases executed, major bugs fixed.
7. Risks and Mitigation Plans:
Description:
Identify factors that may impact testing and strategies to handle them.

How to Identify:
Brainstorm with team about past issues (e.g., late requirements, environment
instability).
Gather input from stakeholders on business-critical areas.

Example:
Risk: Third-party payment API might go live late.
Mitigation: Use a mock API for most cases, delay payment testing until API is stable.
How a Walkthrough Is Conducted (Example):
Preparation:
The QA lead creates a test plan document and shares it with the team ahead of the meeting.

Review Meeting:
During the walkthrough, the plan is projected or shared. Each key section (scope, objectives,
schedule, data) is discussed.

Feedback and Clarification:

Stakeholders ask questions—e.g., a product owner notices the checkout promo codes aren’t in scope;
the team agrees to add them.

Action Items:
The QA updates the test plan document to reflect changes after the meeting.

Sign-off:
Once all concerns are addressed, stakeholders approve the plan, and testing execution proceeds.