Skip to content

Loading interactive demos…

RESUME

SDLC — A QA Engineer’s Perspective

Explore how software moves from requirements to production, what each team does, and how QA Engineers contribute throughout the entire lifecycle.

Software Development Life Cycle (SDLC) is the overall process of developing, delivering and maintaining software. These six phases are conceptual: Agile teams often repeat activities and work in parallel. Quality Assurance (QA) contributes throughout; quality is a shared team responsibility.

Phase 1 / 6

Requirement Gathering & Analysis

Process Overview

Purpose

Understand customer needs and agree what the software must do.

Responsible People

Client, stakeholders, Product Owner (PO), Business Analyst (BA), Project Manager (PM) and relevant team members.

Input

Business idea, customer requests and stakeholder expectations.

Activities
  • Discuss the business need introduced by the client or stakeholder; collect functional requirements (what the software does) and non-functional requirements (how well it must work).
  • Clarify business objectives and scope; assess feasibility, risks, dependencies and constraints.
  • Record requirements in suitable artifacts: a Software Requirements Specification (SRS), user stories or a backlog. An SRS is one option, not a mandatory document.
QA Engineer’s Role
  • Review clarity and testability; identify ambiguous or missing behavior and ask clarification questions.
  • Consider functional and non-functional risks; contribute to acceptance criteria and early test analysis.
Output / Deliverables

Reviewed requirements, specifications or user stories, clarification notes and acceptance criteria inform design and delivery planning.

Practical Example

REQ-AUTH-001 — Secure User LogoutIllustrative project · fictional builds and outcomes

What happens in this phase?

A Product Owner receives a request for secure logout. The team refines REQ-AUTH-001 before deciding how to build it.

Responsible team
  • The PO explains the business need; the BA records a user story and measurable acceptance criteria with developers and QA.
QA Engineer’s Role
  • Ask what happens to the server session, other tabs, browser Back and failed logout requests.
  • Clarify that backend access must stop in every tab; immediate tab UI synchronization needs a separate scope decision. Review security risks and testability.

Business requirement

Authenticated users must be able to log out securely, and their authenticated session must be invalidated.

User story & acceptance criteria

“As an authenticated user, I want to log out securely so that my account cannot be accessed after my session ends.”

  • AC-01Logout redirects the user to the login page.
  • AC-02Protected routes require authentication after logout.
  • AC-03The server-side authenticated session is invalidated.
  • AC-04A terminated session cannot be reused.
Result / Deliverable

Reviewed User Story and Acceptance Criteria, with clarification notes on history, tabs and failure handling. These become input to the logout design.

Phase 2 / 6

System & Software Design

Process Overview

Purpose

Decide how the software should behave and how its components will be structured.

Responsible People

User Interface / User Experience (UI/UX) designers, software architects, developers, PO, BA and relevant stakeholders.

Input

Requirements, acceptance criteria and business constraints.

Activities
  • Design user journeys, interfaces, architecture and frontend / backend interactions.
  • Consider data flow, Application Programming Interface (API) contracts and database structure.
  • Review wireframes, prototypes and technical specifications with stakeholders. A Software Design Specification (SDS) is one possible artifact; teams may document designs differently.
QA Engineer’s Role
  • Review relevant designs for quality and testability; raise questions early.
  • Identify edge cases, negative scenarios, failure handling and usability concerns; begin test scenarios.
Output / Deliverables

Reviewed or approved designs, prototypes, architecture documentation and test scenario ideas guide implementation.

Practical Example

REQ-AUTH-001 — Secure User LogoutIllustrative project · fictional builds and outcomes

What happens in this phase?

The team turns the reviewed story into a logout design covering both the interface and the authenticated session.

Responsible team
  • Designers specify an accessible Log out control and the login-page destination. Developers define the logout operation, session invalidation and protected-route checks.
  • For this illustration, the server holds a revocable session. After successful logout, the client clears authentication state and redirects. A failed operation shows a retryable error without claiming revocation succeeded.
QA Engineer’s Role
  • Review keyboard access, error announcements, cached pages, repeated logout and other tabs.
  • Check that the design can demonstrate AC-01…04: a visible redirect, protected-route rejection and server-side denial of the old session.

Reviewed interaction

  1. User activates Log out.
  2. The backend invalidates the authenticated session.
  3. The client clears authentication state and opens the login page.
  4. Protected routes and requests reject the terminated session.

Other applications may use different token or identity-provider designs; this is the agreed architecture for this example.

Result / Deliverable

Reviewed Logout Design: interaction, service behavior, route protection and error handling are ready for implementation and test preparation.

Phase 3 / 6

Development & Implementation

Process Overview

Purpose

Turn requirements and designs into working software.

Responsible People

Frontend, backend and full-stack developers, technical leads and supporting engineering teams.

Input

Requirements, designs, technical specifications and acceptance criteria.

Activities
  • Implement functionality across frontend and backend components; review code and run unit tests that check small parts of the code.
  • Use Continuous Integration (CI) to integrate changes, run automated checks and prepare testable builds; investigate failures with the team.
  • Common environments include Development (DEV) for integration, QA / Test for verification, Staging for release validation and Production for live users. Teams may combine these or use temporary environments.
QA Engineer’s Role
  • Collaborate with developers and clarify expected behavior; prepare test cases, test data and environment needs.
  • Prepare suitable automation scenarios and begin testing as soon as testable functionality is available.
Output / Deliverables

Working builds, implemented functionality and testing-ready changes provide input for further verification and feedback.

Practical Example

REQ-AUTH-001 — Secure User LogoutIllustrative project · fictional builds and outcomes

What happens in this phase?

Developers implement the agreed design and deliver candidate build v1.0.1 to the QA / Test environment.

Responsible team
  • Frontend developers wire the logout action, state cleanup, redirect and protected-route behavior. Backend developers implement session invalidation and protected-resource checks.
  • Developers add unit and integration tests, review code and use CI to build and check changes before delivery to the test environment.
QA Engineer’s Role
  • Prepare synthetic accounts and active / expired sessions; confirm the test build, environment and agreed behavior.
  • Prepare TC-LOGOUT-001…005 for logout, protected URLs, other tabs, error handling and browser Back. Select stable checks for automation and review setup / cleanup with developers.

Test preparation handoff

Trace: REQ-AUTH-001 → AC-01…04 → TC-LOGOUT-001…005.

One criterion may need several cases, and one case may cover several criteria. The test environment uses disposable accounts and repeatable data; no customer credentials are used.

Result / Deliverable

Testable Logout Feature: a candidate build, implementation notes, prepared cases and data. QA can now compare actual behavior with the agreed outcomes.

Phase 4 / 6

Testing & Quality Assurance

Process Overview

Purpose

Evaluate whether the software meets requirements and make quality risks visible.

Responsible People

Quality Assurance (QA) Engineers, Software Development Engineers in Test (SDETs), developers and relevant specialist testers.

Input

Testable build, requirements, designs, test cases, test data and suitable test environments.

Activities
  • The Software Testing Life Cycle (STLC) includes requirement analysis, test planning, case design, environment preparation, execution and test cycle closure. These activities overlap other SDLC phases.
  • Run manual, automated and exploratory checks; compare expected and actual results and document outcomes.
  • Report defects, retest fixes and perform regression testing; review coverage and outstanding risks.
  • Functional testing checks what the software does; non-functional testing evaluates qualities such as performance, accessibility or security. Depending on scope, tests cover UI, API and database layers.
  • CI runs selected checks and retains logs, reports and failure evidence. Review these alongside manual findings; close the test cycle with coverage, outcomes and residual risks.
QA Engineer’s Role
  • Plan coverage, priorities, data and execution with the team; execute appropriate checks.
  • Investigate failures, evaluate results and risks, and report evidence and coverage gaps to stakeholders.
Output / Deliverables

Test results, defect reports, evidence, coverage information and quality assessments support decisions. Passing tests cannot guarantee defect-free software.

Practical Example

REQ-AUTH-001 — Secure User LogoutIllustrative project · fictional builds and outcomes

What happens in this phase?

QA executes the prepared cases on v1.0.1. The fictional results reveal that the protected account page remains accessible after logout.

Responsible team
  • QA records expected versus actual results and reports BUG-LOGOUT-001. Developers reproduce the issue, find missing server revocation and correct session invalidation and route checks in candidate v1.0.2.
QA Engineer’s Role
  • Reproduce: sign in → log out → revisit /account → request protected data with the same pre-logout session. Attach the build, browser, steps and evidence.
  • Retest the original failure on v1.0.2, then check login, Back, other tabs, expiry and logout errors for regression. Review manual / exploratory findings alongside CI feedback.

Illustrative execution · v1.0.1

Test / coverageExpectedActual · example
TC-LOGOUT-001 · AC-01 / 03 / 04Login page; old session denied.Redirect works; old session still retrieves data. Fail.
TC-LOGOUT-002 · AC-02Direct /account access requires login.Account content remains accessible. Fail.
TC-LOGOUT-003 · AC-02 / 04Other tabs cannot fetch protected data.Tab B still retrieves account data. Fail.
TC-LOGOUT-004 · error handlingLogout failure shows a retryable error.Error announced without false success. Pass.
TC-LOGOUT-005 · AC-02Back reveals no sensitive account content.Cached account content is visible. Fail.

BUG-LOGOUT-001 → fix → verification

Protected account page remains accessible after logout. Severity: Critical because protected data is exposed. Priority: P1 in this fictional release.

Illustrative retest: v1.0.2 requires login, rejects the same old session with 401 Unauthorized, and passes the targeted history, tab and error-path checks. QA verifies the fix and records regression evidence; a defect is created only when a finding warrants investigation.

Where Playwright and CI help

Playwright can repeat the logout, redirect and protected-page checks using stable role / label locators and meaningful assertions. CI can run smoke checks on relevant changes, broader regression on candidates, and retain logs, screenshots, traces and reports for investigation.

UI automation alone does not prove backend session revocation. A separate service-level check must attempt to reuse the same pre-logout session. The existing examples below require a configured QA app and disposable test accounts.

Browser E2E (end-to-end) example

// Illustrative QA app contract, not the separate SauceDemo example.
// baseURL and isolated test-account credentials come from QA configuration.
import { test, expect, type Page } from '@playwright/test';

class AccountPage {
  constructor(private readonly page: Page) {}
  async logout() {
    await this.page.getByRole('button', { name: 'Log out', exact: true }).click();
  }
}

test('TC-LOGOUT-002: protected page requires login after logout', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Username', { exact: true }).fill(process.env.QA_TEST_USER!);
  await page.getByLabel('Password', { exact: true }).fill(process.env.QA_TEST_PASSWORD!);
  await page.getByRole('button', { name: 'Sign in', exact: true }).click();
  await expect(page).toHaveURL(/\/account$/);
  await expect(page.getByRole('heading', { name: 'Your account', exact: true })).toBeVisible();

  await new AccountPage(page).logout();
  await expect(page).toHaveURL(/\/login$/);
  await expect(page.getByRole('button', { name: 'Sign in', exact: true })).toBeVisible();

  await page.goto('/account');
  await expect(page).toHaveURL(/\/login$/);
  await expect(page.getByRole('heading', { name: 'Your account', exact: true })).toHaveCount(0);
});

Separate service-level session replay check

// Separate service-level check for the agreed opaque-session contract.
// Test fixture supplies an isolated account and cleans up its sessions.
import { test, expect } from '@playwright/test';

test('TC-LOGOUT-001: old session cannot access protected data', async ({ request }) => {
  const login = await request.post('/api/auth/login', { data: {
    username: process.env.QA_TEST_USER,
    password: process.env.QA_TEST_PASSWORD,
  } });
  expect(login.status()).toBe(200);
  const { token } = await login.json();
  const headers = { Authorization: `Bearer ${token}` };
  try {
    const logout = await request.post('/api/auth/logout', { headers });
    expect(logout.status()).toBe(204);
    const replay = await request.get('/api/account', { headers });
    expect(replay.status()).toBe(401); // the SAME pre-logout token
  } finally {
    await request.post('/api/auth/logout', { headers });
  }
});

Jenkins evidence configuration · illustrative fragment

// Playwright configuration: HTML + JUnit reporters;
// trace: retain-on-failure; screenshot: only-on-failure
// Jenkins agent: Node, locked dependencies and matching browsers installed
// Test step: npx playwright test
post {
  always {
    junit 'test-results/junit.xml'
    archiveArtifacts artifacts: 'playwright-report/**,test-results/**'
  }
}

The configured reporter path must match Jenkins. Preserve evidence on failure and investigate the assertion, application behavior and environment before classifying the result.

Explore the separate Playwright / Page Object demo ↗ · Open the existing CI Pipeline Lab ↗

Result / Deliverable

Test Results, Defect Verification and Test Evidence: expected / actual records, verified BUG-LOGOUT-001, updated coverage and reviewed CI feedback support the release assessment.

Phase 5 / 6

Release & Deployment

Process Overview

Purpose

Make validated software available to its intended users through the agreed release process.

Responsible People

Development, Development and Operations (DevOps) / Release Engineering, QA, Product / Business stakeholders and other relevant teams.

Input

Release candidate, test results, defect status, known risks and deployment plan.

Activities
  • Review the release candidate, coverage, results, open defects and risks; complete relevant acceptance activities and prepare a deployment plan.
  • Staging / Pre-production supports production-like release validation and may support User Acceptance Testing (UAT), where business users assess whether needs are met.
  • Deploy to Production, the live environment used by customers; validate deployment and monitor initial release health. Continuous Delivery (CD) keeps validated changes ready to release; deployment and final approval follow the organization’s responsibilities.
QA Engineer’s Role
  • Review coverage and results, identify remaining defects and risks, communicate quality status and support release decisions.
  • Perform applicable smoke checks (quick checks of critical journeys) and verify critical functionality after deployment when appropriate.
Output / Deliverables

Released software, deployment verification results and release status. Final deployment approval follows organizational responsibilities; QA supplies evidence and readiness feedback.

Practical Example

REQ-AUTH-001 — Secure User LogoutIllustrative project · fictional builds and outcomes

What happens in this phase?

Candidate v1.0.2 enters release review after the logout defect is verified and agreed regression checks pass in this illustration.

Responsible team
  • Product, development and release / operations owners review the candidate, known defects, residual risks and deployment plan. The responsible team authorizes and deploys it.
  • Staging validation and business acceptance happen where applicable; initial monitoring follows production deployment.
QA Engineer’s Role
  • Review AC-01…04 coverage, results and BUG-LOGOUT-001 verification. Communicate gaps and the scope limits of the evidence.
  • Recommend readiness based on risk. After deployment, perform permitted smoke checks of login, logout and protected routes with approved test accounts.

Illustrative release assessment

Recommendation: proceed through the agreed approval process after reviewing the candidate evidence; the authentication defect must be verified before release.

Residual scope: immediate visual synchronization of all tabs and logout on every device are not claimed. Backend denial of the terminated session is required. Passing checks do not guarantee defect-free software.

Deployment validation: record the deployed version, smoke outcomes and any discrepancies. Report a failed check to the release owner for mitigation or rollback assessment.

Result / Deliverable

Release Assessment and Deployment Validation: a documented QA recommendation, accepted limitations, deployment verification and release status from the responsible team.

Phase 6 / 6

Maintenance & Continuous Improvement

Process Overview

Purpose

Maintain quality after release and use feedback to improve the product.

Responsible People

Development, Operations, Support, QA, Product teams and relevant stakeholders.

Input

Production feedback, incidents, monitoring information, reported defects and new requirements.

Activities
  • Monitor application behavior, investigate production issues and fix confirmed defects.
  • Deliver urgent hotfixes when impact warrants them; other fixes can follow the planned release process. Improve existing functionality.
  • Review new feature requests and plan subsequent releases.
QA Engineer’s Role
  • Help reproduce production issues, verify fixes and perform targeted regression testing.
  • Update relevant automated tests, identify recurring risks and support improvements in future iterations.
Output / Deliverables

Validated fixes, updated versions, improved regression coverage and new requirements. New requirements may begin another SDLC iteration.

Practical Example

REQ-AUTH-001 — Secure User LogoutIllustrative project · fictional builds and outcomes

What happens in this phase?

After release, suppose a user reports that browser Back intermittently displays cached account details after logout in one browser version.

Responsible team
  • Support gathers the steps and environment; the technical team investigates the cache behavior and exposure.
  • Developers implement a fix where needed. The incident owner assesses urgency: an urgent hotfix or a planned release depends on impact, rather than every defect automatically requiring a hotfix.
QA Engineer’s Role
  • Reproduce the timing, browser and session conditions; distinguish cached UI exposure from fresh access to protected data.
  • Verify the fix, repeat targeted regression and add TC-LOGOUT-006 for the missed browser-cache condition. Update relevant automated coverage and share the lesson with the team.

Feedback into the next iteration

REQ-AUTH-001 remains linked to the incident and its regression tests. A new request, such as logging out from all devices, returns to requirement analysis with its own scope and acceptance criteria.

Result / Deliverable

Verified Fix and Updated Test Coverage: retest evidence, a validated release, expanded browser-cache regression and new requirements for a future iteration.

The lifecycle continues after release. User feedback, defects and new requirements feed future iterations; QA helps turn those lessons into better coverage and quality decisions.