The QA Role at Every SDLC Stage

If there is one myth you should demolish before your first day on the job, it's this one: "QA tests the finished product."

Yes, QA tests finished features. But a QA engineer who only does that is leaving the majority of their impact on the table. This lesson shows you the full scope of what quality looks like across the entire SDLC.

Learning Objectives

By the end of this lesson you will be able to:

• Describe QA's specific contribution at each SDLC phase
• Explain the "Shift Left Testing" principle
• Articulate why QA involvement in requirements analysis is worth more than any amount of regression testing

Phase by Phase: What QA Actually Does

Phase 1 — Requirements Analysis: Be the Devil's Advocate

When the BA, PO, and stakeholders are in the room writing requirements, QA should be in that room asking uncomfortable questions.

QA's contribution:

• "This requirement says 'the user can upload a file.' What file types? What's the maximum size? What happens if the upload fails?"
• "This AC says 'the form validates the email.' Does it validate at blur, on submit, or both? What does the error message say?"
• Identifying missing requirements: "We have a requirement for the happy path. Where's the requirement for the error state?"

The payoff: Every ambiguity resolved here is a bug that was never written into the code.

Phase 2 — Design: Test the Blueprint

When architects and developers are drawing API diagrams and UI wireframes, QA reviews them for:

• Missing error states — "Your API spec defines HTTP 200 (success) and HTTP 500 (server error). What happens on HTTP 400 (bad request)? What does the Frontend do with that?"
• Edge cases in UX flow — "Your wireframe shows the checkout flow for a logged-in user. What does a guest user see? What if their session expires mid-checkout?"
• Testability gaps — "This design doesn't include any logging for failed payments. How will we diagnose issues in production?"

The payoff: Design-phase defects are fixed with an edit to a document or diagram. No code is rewritten.

Phase 3 — Development: Prepare and Pair

While developers are writing code, QA is:

• Writing test cases from the finalised requirements — so testing can start immediately when development finishes
• Refining Acceptance Criteria — as developers build, they sometimes discover that ACs were too vague. QA clarifies.
• Setting up test data — preparing the realistic data sets needed to exercise edge cases
• Pairing with developers on complex features — "What happens if I pass a null value here? What does the API return?"

The payoff: When development finishes, QA can start testing immediately instead of spending the first day figuring out what to test.

Phase 4 — Testing: The Core (But Not the Only) Act

This is the phase everyone knows. QA's activities:

• Functional testing — every Acceptance Criterion, verified
• Regression testing — did this change break anything that worked before?
• Exploratory testing — going beyond the spec to find what the spec missed
• Non-functional testing — performance under load, security, accessibility

The payoff: Bugs are caught before users see them. This is expensive relative to requirements review, but it's still vastly cheaper than production fixes.

Phase 5 — Deployment: The Go/No-Go Call

QA participates in the go/no-go decision before each release:

• Open bug severity review — are any open bugs P1 or P2? If so, the release is blocked.
• Post-deployment smoke test — verify that the feature works in production (configuration differences between staging and production can introduce new failures)
• Deployment checklist — database migrations applied? Feature flags configured? Rollback plan ready?

The payoff: Deploying a release you've signed off on is a professional moment. Deploying one you had reservations about and not raising them is a risk you own.

Phase 6 — Maintenance: The Feedback Loop

After release, QA monitors:

• Support ticket patterns — three reports of the same issue in a week is a bug that needs a test case
• Production error logs — error rates that spike after a deployment are a regression signal
• Hotfix verification — every hotfix deployed to production goes through the same testing gate as a regular release (just faster)
• Retrospective contributions — "We had 4 production bugs this sprint that our test suite should have caught. Here's why they slipped through, and here's the coverage I'm adding."

The payoff: Each production incident improves your test coverage. The team gets smarter with every release.

Shift Left Testing

"Shift Left" is the principle of moving testing activities earlier in the development lifecycle — to the left on the timeline.

Old model:  Requirements → Design → Development → [TESTING] → Deployment
Shift Left: [QA] → [QA] → [QA] → [TESTING] → [QA]

The earlier a defect is found, the cheaper it is to fix. Every QA activity in Phase 1 and Phase 2 is an investment that pays dividends in Phase 4 and Phase 6.

The practical version of Shift Left: Ask to be added to the BA's requirements review sessions. Ask to be in design reviews. Ask to see wireframes before they're approved. This is not overstepping — it's doing your job to its full potential.

Summary

This is what quality engineering looks like across the full lifecycle. You're not a gatekeeper at the end — you're a quality advocate at every step.

Congratulations on completing the final lesson of this course. You're ready for the Teamplayer badge.