Skip to content

Loading interactive demos…

RESUME
← All QA Handbook guidesPlaywright & technical demos ↗

STLC — A QA Engineer's Perspective

Explore how software testing is planned, designed, prepared, executed and completed — with practical examples, test artifacts and the QA Engineer's responsibilities at every stage.

Software Testing Life Cycle (STLC) organizes testing work so a team can prevent defects, evaluate behavior and communicate quality risks using evidence. Activities can overlap and repeat during iterative development; the six phases below are a learning model, not mandatory handoffs.

Phase 1 / 6

Requirement Analysis

Process Overview

Purpose

Understand the required behavior, discover gaps and quality risks, and identify what can be tested before those gaps become implementation defects.

Responsible People

QA Engineer, Product Owner, Business Analyst, developers and relevant business or security stakeholders.

Inputs

Business requirements, user stories, acceptance criteria, functional and non-functional requirements, product documentation and existing system behavior.

Activities
  • Review requirements and acceptance criteria for clarity, consistency and testability.
  • Identify positive, negative and edge-case test conditions; discuss integrations and dependencies.
  • Record preliminary quality risks and clarification questions; agree expected behavior with the people who own the requirement.
QA Engineer’s Role
  • During backlog refinement, ask how each behavior can be observed and verified. Trace initial test conditions to the test basis.
  • Shift-left testing brings reviews and test thinking earlier to prevent defects. Dynamic testing still continues during development and beyond.
Output / Deliverables

Requirement review notes, answered clarification questions, initial test conditions, risk observations and the foundation for requirement-to-test traceability.

Entry Criteria

Example: a draft story, relevant product context and access to people who can clarify behavior are available.

Exit Criteria

Example: high-impact ambiguities have agreed answers, key risks are recorded and initial test conditions can inform planning. Revisit analysis when requirements change.

Key takeaway, common mistake & related ISTQB concepts
Key Takeaway
A testable requirement names an observable result under defined conditions.
Common Mistake
Accepting “logout must be secure” without defining session invalidation, browser history, multiple tabs and failure behavior.
Related ISTQB Concepts
Test Analysis identifies what to test; requirement reviews are static testing. See CTFL §§1.4.1, 3 and 4.5.2.

Read the CTFL v4.0.1 syllabus ↗

Practical Example

REQ-AUTH-001 — Secure User Logout & Session InvalidationSTORY-AUTH-001 · Educational example · fictional builds, records and outcomes; no live CI execution

User story · STORY-AUTH-001

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

Reviewed acceptance criteria

  • AC-AUTH-001 — After successful logout, the UI clears authenticated state and redirects to the sign-in page.
  • AC-AUTH-002 — After successful logout, the previous session is invalid: protected APIs return 401 without protected data; direct protected-page requests require sign-in.
  • AC-AUTH-003 — Browser Back after successful logout does not expose sensitive account content; refreshing or requesting protected content requires sign-in.
  • AC-AUTH-004 — Tabs sharing the same session cannot fetch protected content after that session is logged out; the next protected request requires sign-in.
  • AC-AUTH-005 — If the logout API fails, show “Logout could not be confirmed. Retry.” Do not show success or claim that the session was invalidated. A successful retry ends the session.

These example criteria are verifiable because they identify a trigger, a defined condition and an observable result: for example, a successful logout followed by an old-session API request must return 401 without private data. “Secure” alone is not an observable result.

QA review notes, questions and initial test conditions
Requirement review · agreed decisions for this example
Question / riskAgreed decision / initial test condition
Does hiding the UI invalidate the server session?No. Check both server rejection of the previous session and the UI redirect (AC-AUTH-001 / 002).
Could browser history expose account data?Sensitive history content must not be visible; test Back and refresh (AC-AUTH-003).
Does logout include every device?Only the current session, including tabs sharing it. Other device sessions are excluded (AC-AUTH-004).
What happens if the logout request fails?Do not claim success; offer retry. Session status may be uncertain after a network failure (AC-AUTH-005).
Which security risks are highest?Session replay / unauthorized data access is critical. Cached private content and misleading failure feedback also need coverage.
Phase 2 / 6

Test Planning

Process Overview

Purpose

Agree testing objectives, scope, approach, resources and risk controls so the team can use its time and evidence effectively.

Responsible People

QA Engineer, test lead or test manager where present, Product Owner, developers and DevOps / platform representatives.

Inputs

Reviewed requirements and acceptance criteria, feature scope, project and product risks, available environments, team capacity and delivery schedule.

Activities
  • Define objectives, scope and exclusions; select test levels, test types and a balance of manual and automated testing.
  • Identify people, environments, tools and data needs. Estimate effort and plan around dependencies.
  • Prioritize by risk; agree context-specific entry and exit criteria, reporting and communication arrangements.
QA Engineer’s Role
  • Turn the security risk into prioritized coverage and make assumptions, constraints and tradeoffs visible.
  • Keep planning proportional: an Agile team can use a story checklist and sprint notes; a regulated or complex project may require a formal reviewed plan. Separate documents are not mandatory.
Output / Deliverables

Test Plan or equivalent planning artifact, scope definition, risk assessment, test approach, resource / environment requirements and entry / exit criteria.

Entry Criteria

Example: enough requirement and risk information exists to estimate a first scope; capacity and delivery constraints are known.

Exit Criteria

Example: the team understands the approach, owners, resource needs and completion criteria. Assumptions and unresolved dependencies have owners.

Key takeaway, common mistake & related ISTQB concepts
Key Takeaway
A useful plan helps the team decide what to test first and what evidence it needs.
Common Mistake
Treating a template as a fixed contract or measuring progress only by the number of tests written.
Related ISTQB Concepts
Test Planning, risk-based testing, estimation and prioritization. See CTFL §§5.1–5.2.

Read the CTFL v4.0.1 syllabus ↗

Practical Example

REQ-AUTH-001 — Secure User Logout & Session InvalidationSTORY-AUTH-001 · Educational example · fictional builds, records and outcomes; no live CI execution

Test Plan · PLAN-LOGOUT-001 · Reviewed example

Feature / objective
Secure User Logout & Session Invalidation · verify REQ-AUTH-001 and AC-AUTH-001–005.
Scope
Current-session logout, protected API / direct page access, Back navigation, shared-session tabs and API failure / retry.
Exclusions
Other device sessions, SSO provider logout, full penetration testing, load testing and browsers beyond Chromium. These require separate coverage before a broader release claim.
Test levels
Developer component tests; integration tests for auth middleware / session store; QA system tests with UI and API checks; PO reviews acceptance evidence.
Test types / approach
Functional and focused security / usability checks; automate repeatable UI and API checks, supplement with exploratory investigation.
Environment / data
QA / Staging demo application, Chromium, Playwright + TypeScript, Authentication API and isolated test database. Synthetic active / invalid sessions; no production data.
Risks / priority
Critical: session replay. High: cached data, shared-tab access and misleading error feedback. Run TC-LOGOUT-002 early.
People / effort / schedule
QA owns system evidence; developer owns fixes / component checks; platform owner supports deployment. Illustrative estimate: 1 QA day for design / setup, 1 for execution / reporting, with fix time reviewed in sprint planning.
Entry criteria
Reviewed ACs, ready build / environment, accounts, test cases and fault-injection controls available.
Exit criteria
All five cases executed and passed on the candidate build; no open critical / high defects in scope; all five ACs have linked evidence. Reassess or escalate any unmet criterion.
Reporting / deliverables
Share progress and blockers in the daily team update; triage critical failures immediately. Deliver cases, traceability, sanitized evidence, defect reports and a completion summary.
Test Strategy, Test Plan and Test Approach
Test Strategy
High-level direction for test levels and testing within those levels, often shared across an organization or program: for example, combine component, integration and system checks for authentication risks.
Test Plan
The project / feature planning artifact that brings together objectives, scope, resources, timing and criteria. Here, PLAN-LOGOUT-001 can live in the story or team wiki.
Test Approach
The contextual choices that implement the direction: here, API session replay, selected browser checks and exploratory investigation, prioritized by risk. It can be recorded inside the plan.
Phase 3 / 6

Test Case Development

Process Overview

Purpose

Turn test conditions into reviewed test cases, data and executable coverage that can reveal meaningful failures.

Responsible People

QA Engineers, automation engineers, developers and Product Owner / Business Analyst for expected behavior review.

Inputs

Reviewed story and acceptance criteria, prioritized test conditions, test plan, interface contracts and test data / environment constraints.

Activities
  • Refine test conditions, apply suitable test design techniques and design positive, negative and edge-case tests.
  • Prepare test data, trace cases to acceptance criteria and review coverage with peers.
  • Prioritize and organize tests; prepare manual procedures and suitable automated scripts, including setup and cleanup.
QA Engineer’s Role
  • Convert each acceptance criterion into observable expected results. Include preconditions and repeatable steps.
  • Choose stable, repeatable, high-value automation candidates. Retain exploratory and usability testing; automation complements human investigation.
Output / Deliverables

Reviewed test cases, test data, coverage matrix, requirement traceability, executable manual procedures and automated scripts where appropriate.

Entry Criteria

Example: acceptance criteria are testable, high-risk conditions are known and the initial approach is agreed.

Exit Criteria

Example: prioritized cases have reviewed expected results, mapped acceptance criteria and prepared data; remaining coverage gaps are recorded.

Key takeaway, common mistake & related ISTQB concepts
Key Takeaway
Coverage is the connection between a requirement, a meaningful test and its expected result.
Common Mistake
Writing click-by-click scripts without an oracle, or forcing boundary values onto behavior that has no ordered boundary.
Related ISTQB Concepts
This teaching phase spans Test Analysis (conditions), Test Design (cases / data needs) and Test Implementation (scripts / suites / data). See CTFL §§1.4.1 and 4.2.

Read the CTFL v4.0.1 syllabus ↗

Practical Example

REQ-AUTH-001 — Secure User Logout & Session InvalidationSTORY-AUTH-001 · Educational example · fictional builds, records and outcomes; no live CI execution

Five reviewed cases turn the Phase 1 conditions into repeatable checks. Every case traces to REQ-AUTH-001 and STORY-AUTH-001.

TC-LOGOUT-001 — Successful logout

Priority
High
Preconditions
An active session exists; the account page is open; logout service is healthy.
Test Steps
  1. Select Log out.
  2. Observe the response, route and authenticated navigation.
Expected Result
A successful response clears authenticated UI state; sign-in page is shown and private navigation is removed.
Associated Acceptance Criteria
AC-AUTH-001
Automation Candidate
Yes — UI flow with deterministic session setup.

TC-LOGOUT-002 — Access protected page after logout

Priority
Critical
Preconditions
An active session exists. An authorized QA harness retains its session token in memory for the replay check; never publish it.
Test Steps
  1. Log out successfully.
  2. Replay the previous session against GET /api/profile.
  3. Navigate directly to /account.
Expected Result
GET /api/profile returns 401 and no protected data. Direct /account navigation requires sign-in.
Associated Acceptance Criteria
AC-AUTH-002
Automation Candidate
Yes — API assertion plus direct UI navigation.

TC-LOGOUT-003 — Browser Back navigation after logout

Priority
High
Preconditions
An authenticated user has visited /account with sensitive demo content.
Test Steps
  1. Log out successfully.
  2. Use Browser Back.
  3. Refresh and request /api/account.
Expected Result
Sensitive account content is not displayed from history. Refresh requires sign-in; GET /api/account returns 401.
Associated Acceptance Criteria
AC-AUTH-003
Automation Candidate
Yes — browser test; supplement with exploratory history / cache checks.

TC-LOGOUT-004 — Logout from multiple tabs

Priority
High
Preconditions
Tabs A and B share one authenticated session; both show /account. Independent sessions on other devices are outside this scope.
Test Steps
  1. Log out in tab A.
  2. In tab B, trigger a protected GET /api/account request.
Expected Result
Tab B cannot fetch protected data; the request returns 401 and the UI requires sign-in. Immediate cross-tab visual synchronization is not required by this criterion.
Associated Acceptance Criteria
AC-AUTH-004
Automation Candidate
Yes — two pages in one browser context, sharing a session.

TC-LOGOUT-005 — Logout API failure

Priority
High
Preconditions
An active session exists; a scoped test-only fault injector can return 500 before logout processing.
Test Steps
  1. Enable the one-request failure and select Log out.
  2. Observe failure feedback and authenticated state.
  3. Remove the fault and retry logout.
Expected Result
The UI says “Logout could not be confirmed. Retry.” and never claims success on failure. A successful retry redirects to sign-in and invalidates the session.
Associated Acceptance Criteria
AC-AUTH-005
Automation Candidate
Yes — controlled fault injection; rerun success path against the real test API.
Requirement → Acceptance Criterion → Test Case
Coverage matrix · designed coverage
Requirement / storyAcceptance criterionTest case
REQ-AUTH-001 / STORY-AUTH-001AC-AUTH-001TC-LOGOUT-001
REQ-AUTH-001 / STORY-AUTH-001AC-AUTH-002TC-LOGOUT-002
REQ-AUTH-001 / STORY-AUTH-001AC-AUTH-003TC-LOGOUT-003
REQ-AUTH-001 / STORY-AUTH-001AC-AUTH-004TC-LOGOUT-004
REQ-AUTH-001 / STORY-AUTH-001AC-AUTH-005TC-LOGOUT-005

Designed coverage is 5 / 5 acceptance criteria. Execution evidence is added in Phase 5; a mapped test alone does not show that a requirement passed.

Choose suitable test design techniques
Equivalence Partitioning
Group inputs or states expected to behave alike. Active sessions may access protected data; invalidated / absent sessions must be denied. Cover each relevant partition; add tests if the scope grows.
Boundary Value Analysis
Exercise values at and around ordered boundaries. This story defines no timeout or numeric range, so no boundary example is forced here. If session expiry becomes scope, clarify its threshold and test just before, at and after it.
Decision Table Testing
Combine conditions and actions. For this feature, compare a successful logout response (clear UI / sign-in) with a failed response (warning / retry); do not report success for the failure rule.
State Transition Testing
Model authenticated → logged out after success; further protected requests are rejected. A failed logout must not be presented as a confirmed transition. TC-LOGOUT-001, 002 and 005 exercise these paths.
Prepared test data
  • DATA-LOGOUT-001: synthetic active account with demo profile data, recreated per case.
  • DATA-LOGOUT-002: previous-session token captured in memory by an authorized test harness; never stored in published evidence.
  • DATA-LOGOUT-003: two tabs in one browser context; an isolated one-request 500 fault for TC-LOGOUT-005. Reset the injector and session after each test.
Phase 4 / 6

Test Environment Setup

Process Overview

Purpose

Prepare a reliable, appropriately representative environment so test results can be trusted and reproduced.

Responsible People

QA Engineers, developers, DevOps / platform engineers and database or service owners where needed.

Inputs

Environment requirements, deployment / build information, test cases, data needs, API contracts and service dependency details.

Activities
  • Verify the deployed build and configuration; confirm accounts, seed data and relevant database prerequisites.
  • Validate API availability and dependencies; check browser and test runner configuration.
  • Run readiness / smoke checks, record limitations and identify who will resolve blockers.
QA Engineer’s Role
  • Provisioning can belong to developers, DevOps or platform teams. QA verifies readiness for the intended tests and captures configuration evidence.
  • Separate an unavailable environment from a product failure. Confirm reproducibility and reset data between tests.
Output / Deliverables

Environment details, readiness checklist, prepared accounts / data, dependency status and a readiness report with limitations.

Entry Criteria

Example: a candidate build, approved test access, dependency information and data requirements are available.

Exit Criteria

Example: agreed smoke checks pass, required services and data are ready, and limitations are understood before execution.

Key takeaway, common mistake & related ISTQB concepts
Key Takeaway
A green smoke check establishes readiness for deeper testing; it does not establish release readiness.
Common Mistake
Testing the wrong build or assuming a stubbed dependency proves the real integration works.
Related ISTQB Concepts
Environment requirements are considered during Test Design; building and verifying the environment is part of Test Implementation. See CTFL §1.4.1.

Read the CTFL v4.0.1 syllabus ↗

Practical Example

REQ-AUTH-001 — Secure User Logout & Session InvalidationSTORY-AUTH-001 · Educational example · fictional builds, records and outcomes; no live CI execution

Environment manifest · ENV-LOGOUT-001

Environment
QA / Staging · isolated educational example
Application / feature
Demo application · Secure User Logout & Session Invalidation
Builds
logout-demo.1 for initial execution → logout-demo.2 after the fix; repeat readiness checks after deployment.
Browser / automation
Chromium · Playwright + TypeScript; record exact pinned versions in a real run manifest.
Backend / database
Authentication API · isolated test database with synthetic accounts; no production credentials.
Readiness checklist · illustrative statuses, not live checks
CheckSample statusReadiness evidence
Build / configurationReadyManifest identifies logout-demo.1 and the QA endpoint.
Accounts / databaseReadySynthetic account seeded; reset routine verified.
API / dependenciesReadyLogin, logout and protected services reachable; session store connected.
Browser / runnerReadyPinned runtime and Chromium installed; isolated browser context configured.
Fault injectionReadyOne-request 500 can be enabled and reset in QA only.
Smoke checksPassLogin and authenticated /account navigation work.
External SSOOut of scopeNo SSO integration is claimed in this example.

Readiness outcome: suitable for the five planned tests, with recorded scope limits. A reachable endpoint can still have a security defect; the smoke check does not prove session invalidation.

Phase 5 / 6

Test Execution

Process Overview

Purpose

Run tests, compare actual and expected results, investigate discrepancies and provide actionable evidence about quality.

Responsible People

QA Engineers, automation engineers, developers for diagnosis / fixes and Product Owner or test lead for triage.

Inputs

Testable build, ready environment, prioritized test procedures, prepared data, expected results and a defect reporting workflow.

Activities
  • Run manual and automated tests; record Pass, Fail, Blocked or Not Run with the build and relevant evidence.
  • Investigate discrepancies, report reproducible defects and link results to acceptance criteria.
  • Confirm fixes, run regression tests based on change impact and update coverage / risks. Monitor progress and adjust testing when necessary.
QA Engineer’s Role
  • Distinguish product failures, test defects and environment problems before making a claim. Describe observed behavior without overstating a suspected cause.
  • Communicate impact and uncertainty, preserve sanitized evidence and collaborate on triage. A passing automated test alone cannot guarantee product quality.
Output / Deliverables

Execution results, test evidence, defect reports, updated coverage status, confirmation testing records and regression results.

Entry Criteria

Example: test cases, data and environment are ready, the build is identified and any limitations are accepted by the team.

Exit Criteria

Example: planned coverage is evaluated, results and defects are recorded, and unresolved blockers / risks are escalated against the agreed criteria.

Key takeaway, common mistake & related ISTQB concepts
Key Takeaway
A failure becomes useful when someone can reproduce it and understand its impact.
Common Mistake
Calling a rerun of one failed test “full regression,” or reporting a UI redirect as proof of server-side session invalidation.
Related ISTQB Concepts
Test Execution, confirmation testing, regression testing and defect management. See CTFL §§1.4.1, 2.2.3 and 5.5.

Read the CTFL v4.0.1 syllabus ↗

Practical Example

REQ-AUTH-001 — Secure User Logout & Session InvalidationSTORY-AUTH-001 · Educational example · fictional builds, records and outcomes; no live CI execution

Initial execution · RUN-LOGOUT-001 · logout-demo.1

Initial results · five unique test cases
Test caseStatusEvidence / observation
TC-LOGOUT-001PassEV-LOGOUT-001: expected behavior observed for this case.
TC-LOGOUT-002FailEV-LOGOUT-002: old session accepted by /api/profile; BUG-LOGOUT-001.
TC-LOGOUT-003PassEV-LOGOUT-003: expected behavior observed for this case.
TC-LOGOUT-004PassEV-LOGOUT-004: expected behavior observed for this case.
TC-LOGOUT-005PassEV-LOGOUT-005: expected behavior observed for this case.

4 Pass + 1 Fail + 0 Blocked + 0 Not Run = 5 planned cases. Blocked means execution could not proceed due to a prerequisite; Not Run means it has not yet been attempted. Neither is a pass.

Defect report · BUG-LOGOUT-001

Title
Protected profile API accepts the previous session token after successful logout
Severity / priority
Critical impact: unauthorized profile access · P1: fix before release (example team scale). Severity describes impact; priority describes urgency.
Environment
ENV-LOGOUT-001 · QA / Staging · logout-demo.1 · Chromium / Authentication API
Preconditions
Synthetic authenticated account; valid previous-session token retained only in the authorized QA harness.
Steps to Reproduce
1. Log in. 2. Log out successfully. 3. Send GET /api/profile using the previous session token.
Expected Result
401 Unauthorized without protected data; the ended session must not access protected resources (AC-AUTH-002).
Actual Result
200 OK with synthetic profile data, even though the UI shows sign-in. TC-LOGOUT-002 = FAIL.
Evidence
EV-LOGOUT-002: illustrative sanitized request / response record below. No real token, account or CI run is included.
Status
Open → Triaged → In Progress → Ready for confirmation → Closed after QA confirmation on logout-demo.2. This workflow is illustrative.
Inspect evidence and the developer fix
EV-LOGOUT-002 · educational evidence, not a live request
Build: logout-demo.1
POST /api/logout  → 204 No Content
GET /api/profile  → 200 OK + synthetic profile data
Session token: [REDACTED]
Expected: 401 Unauthorized, no protected data

Developer diagnosis in this fictional project: /api/profile did not apply the shared session-revocation check, while /api/account did. The developer applies the shared check and adds a component / integration regression check, then provides logout-demo.2. QA repeats environment readiness checks before confirmation.

Confirmation and regression · RUN-LOGOUT-002 · logout-demo.2

QA reruns TC-LOGOUT-002: GET /api/profile now returns 401 without data, and direct /account navigation requires sign-in. EV-LOGOUT-002-R2 records the confirmation; BUG-LOGOUT-001 is closed.

Final snapshot · latest outcome per case, not total executions
Test caseFinal statusEvidence
TC-LOGOUT-001PassEV-LOGOUT-001-R2
TC-LOGOUT-002PassEV-LOGOUT-002-R2
TC-LOGOUT-003PassEV-LOGOUT-003-R2
TC-LOGOUT-004PassEV-LOGOUT-004-R2
TC-LOGOUT-005PassEV-LOGOUT-005-R2

Change-impact review selects TC-LOGOUT-001, 003, 004 and 005 for regression; all four pass on the fixed build. The latest snapshot is 5 / 5 passed. The two full runs contain 10 case executions in total; closure counts five unique planned cases.

Testing, execution, confirmation, regression and reporting
Testing
The wider work of evaluating quality, including reviews, analysis, design, preparation and execution.
Test Execution
Running tests and recording actual results against the expected results.
Retesting / Confirmation Testing
Checking that the reported defect has been fixed: here, TC-LOGOUT-002 on logout-demo.2.
Regression Testing
Checking for adverse effects of the change in affected or related behavior: here, the other four cases selected by impact analysis.
Defect Reporting
Recording a discrepancy with context, impact, reproduction steps and evidence so the team can investigate and prioritize it.

For the technical browser automation walkthrough, see the Test Automation Demo ↗. Its simulation is separate from these illustrative STLC records.

Phase 6 / 6

Test Cycle Closure

Process Overview

Purpose

Evaluate completion, summarize outcomes and remaining risks, and preserve useful test assets and lessons for the next cycle.

Responsible People

QA Engineer / test lead, Product Owner, developers and relevant release, business or operational stakeholders.

Inputs

Agreed completion criteria, execution / coverage records, defect status, confirmation and regression results, and risk observations.

Activities
  • Compare outcomes with completion criteria; review coverage, unresolved defects and residual risks.
  • Communicate a summary and QA recommendation with limitations to stakeholders.
  • Archive or hand over testware, restore the environment to an agreed state and capture lessons / follow-up improvements.
QA Engineer’s Role
  • Explain what was tested, what was learned and what remains uncertain. Make a release-readiness recommendation with evidence.
  • Test completion closes a defined activity or milestone. Release approval belongs to the people designated by team governance; production deployment is a separate operational action. QA does not necessarily own either.
Output / Deliverables

Test Summary / Test Completion Report as appropriate, open-defect summary, residual risk assessment, lessons learned and archived test assets.

Entry Criteria

Example: a sprint / release milestone is reached and results, defects and criteria are available for evaluation, even if some criteria were not met.

Exit Criteria

Example: stakeholders receive the report, risks / unfinished work have owners and useful assets are archived. Completion does not mean testing permanently ends.

Key takeaway, common mistake & related ISTQB concepts
Key Takeaway
The team needs an evidence-based recommendation with explicit limits, not a promise of zero defects.
Common Mistake
Equating “all planned tests passed” with “no remaining risk,” or confusing QA advice with a deployment authorization.
Related ISTQB Concepts
Test Completion occurs at milestones, including iteration or test-level completion. See CTFL §§1.4.1 and 5.3.

Read the CTFL v4.0.1 syllabus ↗

Practical Example

REQ-AUTH-001 — Secure User Logout & Session InvalidationSTORY-AUTH-001 · Educational example · fictional builds, records and outcomes; no live CI execution

Test Summary · SUMMARY-LOGOUT-001 · latest build logout-demo.2

Example dataset · five unique planned cases; latest results from RUN-LOGOUT-002 after confirmation of BUG-LOGOUT-001.

Planned / executed / not run
5 planned · 5 executed · 0 Not Run
Passed / failed / blocked
5 Pass · 0 Fail · 0 Blocked
Open defects
0 in scope. BUG-LOGOUT-001 was confirmed fixed and closed; its history and initial failure remain archived.
Critical risks
0 known unresolved critical risks within the tested scope. This is not proof that no vulnerabilities exist.
Acceptance criteria coverage
5 / 5 ACs designed, executed and passed: AC-AUTH-001–005, each linked to TC-LOGOUT-001–005 and EV-LOGOUT-001-R2–005-R2 respectively.
Exit criteria evaluation
All five planned cases passed, no open critical / high defects and evidence linked for all five ACs. The example plan’s exit criteria are met.
Residual risks / limits
Chromium and current-session flows only. Other browsers, SSO, other device sessions, load and comprehensive security assessment remain outside this cycle; owners must plan coverage before broader claims.
QA recommendation
Ready for Release for the agreed demo scope. The designated release owner still reviews risks and gives release approval; deployment is a separate action.
Archived assets
Reviewed story / ACs, PLAN-LOGOUT-001, five test cases / data recipes, coverage matrix, ENV-LOGOUT-001, both run records, sanitized evidence and BUG-LOGOUT-001.
Lessons / follow-up
Developer: enforce shared authorization checks on every protected route. QA: retain old-session API replay coverage and extend endpoint / browser coverage in the next cycle. Platform owner: reset the environment to its agreed baseline.
How the recommendation could change
Ready for Release
The agreed criteria are met and the evidence supports the intended scope, as in the final demo snapshot.
Ready with Known Risks
Some limits or defects remain and are explicitly assessed for acceptance by the designated risk / release owners. QA records the tradeoff and who owns it.
Not Ready / Blocked
A material criterion or prerequisite is unmet. The initial logout-demo.1 result warrants Not Ready because the previous session can still expose profile data.

These are example team recommendations, not universal ISTQB statuses. Completing the report, making a QA recommendation, granting release approval and deploying to production are distinct events.

STLC within SDLC, Agile & ISTQB

Testing activities are embedded in the broader SDLC. In a sprint, QA may review the next story while executing tests on the current one. Automation preparation can begin during design or development; defect management spans the cycle. Closure marks a milestone and feeds later testing.

The classifications differ. This guide uses the common six-phase STLC structure described by Applause for navigation. ISTQB does not prescribe these exact six phases.

How the six teaching phases align with ISTQB test activities
Educational alignment · not a one-to-one official phase model
Guide phaseRelated ISTQB activity
Requirement AnalysisTest Analysis; static testing of the test basis.
Test PlanningTest Planning.
Test Case DevelopmentTest Analysis, Test Design and Test Implementation.
Test Environment SetupTest Design for requirements; Test Implementation for setup and verification.
Test ExecutionTest Execution, including confirmation / regression work.
Test Cycle ClosureTest Completion.
Across all six phasesTest Monitoring and Control: compare progress / risks with the plan and take corrective action.

For example, a delayed environment leads QA to report the blocker (monitoring), then the team changes priorities or provisions an alternative (control). These activities run throughout testing, not as a seventh sequential gate.

Related resources: SDLC guide · Test Automation Demo · Agile & Scrum notes. Explore the Agile & Scrum guide for a two-week Sprint simulation. The Test Plan outline is still in preparation.

References