The Software Development Life Cycle for QA Engineers

"User can log in" is not a testable acceptance criterion. "User with valid credentials is redirected to /dashboard within 3 seconds; user with invalid credentials sees 'Invalid email or password'" is. Catching that gap at the requirements phase costs a conversation; catching it after development costs a sprint. This article covers what QA engineers actually do at each of the seven SDLC phases, where the highest-leverage moments are, and how the role differs between Waterfall, Agile, and DevOps models.

The phases

1. Planning

The project is being scoped. Requirements are being written. Budgets and timelines are being set.

What QA does here: Mostly not much, in most teams. This is a problem. The best QA contribution in planning is identifying testability requirements early: does the feature need logging? Test environment access? The ability to reset state? Raising these in planning costs hours. Raising them in development costs days. What QA should do: Attend planning meetings. Ask "how will we know this works?" for each proposed feature. Flag requirements that are unclear or untestable.

2. Requirements analysis

Requirements are being refined and made specific. User stories are written. Acceptance criteria are defined.

What QA does here: Review acceptance criteria for completeness. "User can log in" is not testable. "User with valid credentials is redirected to /dashboard within 3 seconds, user with invalid credentials sees 'Invalid email or password' error" is testable. What QA should do: Write test cases while requirements are being finalized — not after. Raise missing edge cases. Push back on vague language. This is where the most valuable QA work happens.

3. Design

The technical architecture is being designed. Database schema. API contracts. Component structure. Deployment topology.

What QA does here: Review design for testability. Can the system be tested in isolation? Are there testable APIs or does everything go through the UI? Are there logging and observability hooks? Is there a way to inject test data? What QA should do: Raise testability concerns during design review. "This feature has no API — it can only be tested through the UI, which means every test will be slow and brittle. Can we add an API endpoint or at least a way to seed test state?"

4. Implementation (development)

Developers are writing code. Features are being built.

What QA does here: Write test cases in parallel. Set up test environments. Write automated tests for features as they become ready. Flag bugs as they're found. What QA should do: Test features incrementally — not all at once at the end. Work with developers to define what "ready for QA" means. Consider pair testing for complex features.

5. Testing

Features are complete and ready for systematic verification.

What QA does here: Execute test cases, run automation, do exploratory testing, verify bug fixes, do regression testing on unchanged areas. What QA should do: Maintain a clear defect record. Communicate risk clearly ("5 high-severity bugs open, we recommend not releasing until at least 3 are fixed"). Don't just find bugs — help prioritize and communicate their impact.

6. Deployment

The product ships to users.

What QA does here: Smoke testing in production or staging after deploy. Monitoring for production errors. Quick validation of the critical path. What QA should do: Have a deployment validation checklist. Know which 5–10 tests run immediately after every deploy to confirm the system is healthy. Monitor error tracking tools in the hours after release.

7. Maintenance

The product is live and being maintained. Bug fixes, small improvements, performance work.

What QA does here: Regression testing for every change, however small. Maintaining the test suite as the product evolves. What QA should do: Update tests when features change. Retire tests for removed features. Don't let the test suite become a museum of features nobody uses anymore.

SDLC models

Waterfall

All phases run sequentially. Requirements are locked before design starts. Design is locked before development starts. Testing happens only after development is complete.

QA in waterfall: QA is a phase at the end. This produces the most expensive defects — bugs found late are expensive to fix. Almost no modern software teams use pure waterfall.

Agile (Scrum, Kanban)

Work is done in short iterations (sprints). Each sprint includes planning, development, and testing. Features ship incrementally.

QA in Agile: Testing happens within the sprint, not after it. QA engineers are part of the cross-functional team. This is the dominant model in 2026 for product teams.

DevOps/Continuous Delivery

Continuous integration and continuous deployment. Code changes trigger automated tests and can ship to production multiple times per day.

QA in DevOps: Automation is essential — you can't manually verify every deployment. QA engineers build and maintain the automation pipeline. Focus shifts from manual test execution to test strategy and automation quality.

Why QA engineers should know this

Knowing where you are in the SDLC tells you what kind of QA work is most valuable right now.

In planning: requirements review. In development: early test case writing. Post-deployment: smoke testing. A QA engineer who only knows how to execute test cases in the testing phase is only useful in one phase of seven. A QA engineer who understands the full SDLC can add value at every stage.

This is also why "shift-left" has become the dominant QA philosophy — moving testing earlier in the SDLC, where it's cheaper and more impactful.