SDLC, STLC and Agile

Process questions come up in almost every testing interview: "explain the STLC", "compare waterfall and Agile", "what do you do in each Scrum event?". Interviewers ask them to check that you know where testing fits in a project and what a tester does at each point, beyond running test cases. This article explains the life cycles, then the Scrum events, then the sprint problems interviewers like to ask about.

SDLC and STLC

The software development life cycle (SDLC) covers building a product from start to finish: requirements, design, coding, testing, release and maintenance. The software testing life cycle (STLC) is the set of testing activities inside it. Interviewers usually expect six phases, each with an output:

1. Requirement analysis: study what must be tested and raise questions. Output: testable requirements, often with a requirement traceability matrix (RTM), a table that links each requirement to its tests.
2. Test planning: scope, approach, effort, schedule and risks. Output: the test plan (the document that describes what will be tested and how; see test planning).
3. Test case design: write cases and prepare data. Output: reviewed test cases.
4. Environment set-up: prepare the environment and confirm it with a smoke test.
5. Test execution: run tests, log defects, retest fixes. Output: results and defect reports.
6. Test closure: check the exit criteria (the conditions that say testing can stop) and write the summary report.

The ISTQB syllabus describes a similar test process with different names: planning, monitoring and control, analysis, design, implementation, execution and completion. In Agile teams all of this happens inside each sprint, in small slices.

Waterfall, the V-model and Agile

Waterfall runs the phases one after another, with testing near the end. Mistakes in requirements are found late, when they cost the most to fix. It suits small projects with fixed requirements.

The V-model is also sequential, but it pairs each development phase with a test level. Testers design each level's tests while the matching phase happens, so problems in documents are found early, even though test execution still comes late.

Agile delivers working software in short iterations (small cycles of a few weeks). Requirements can change between iterations, testing happens in every one, and testers work with developers and the product owner from the start. Automation and continuous integration (merging code changes often, with a server that builds the software and runs the tests after each change) give fast feedback.

Scrum and the tester

Scrum is the most common Agile framework. The 2020 Scrum Guide names three accountabilities: the Product Owner (PO), who orders the product backlog; the Scrum Master; and the Developers, meaning everyone who builds the product, testers included. A sprint is a short, fixed period in which the team builds a small, finished part of the product. It lasts one month or less; two weeks is common. The product backlog is the ordered to-do list of everything the product still needs, and each item on it is usually a user story (a short description of a feature).

In sprint planning, make sure testing and automation tasks are in the plan and each story is testable. In the Daily Scrum, which is time-boxed to 15 minutes, share test progress, blockers and what you need. The Scrum Guide does not require the three classic questions. In the sprint review (a meeting where the team shows finished work to the people who care about the product), help show finished work and note feedback. In the retrospective, raise what slowed testing, such as late builds or flaky tests (tests that sometimes pass and sometimes fail with no code change; see flaky tests).

Backlog refinement is an ongoing activity, not a formal event, and it is where testers add the most: questioning stories, helping write acceptance criteria and spotting data or environment needs early.

Story points, acceptance criteria and done

Story points are a common team practice that the Scrum Guide does not mention. They estimate a story's size compared with other stories, combining effort, complexity and uncertainty, and testing effort is part of them. Acceptance criteria are the conditions one story must meet. The product owner owns them, and they are best written with developers and testers before coding starts, often in Given/When/Then form (Given a situation, When the user does something, Then this result is expected). The definition of done is the team's shared quality bar for every story, such as "code reviewed, tests passing, criteria met". It works like exit criteria (the conditions that say work can stop); the definition of ready works like entry criteria (the conditions that must be true before work starts).

How to answer in an interview

Describe your real process with specifics: sprint length, team size, how stories reach you and what you do in each event. For "a story reaches testing on the last day of the sprint", say that you tell the team and product owner at once, test the riskiest parts first, do not call it done if it is not, let the product owner choose to carry it over or split it, and raise the pattern in the retrospective.

Common mistakes

• Saying the Daily Scrum lasts 30 minutes, or that it must use three questions.
• Treating story points as hours.
• Mixing up acceptance criteria (one story) and the definition of done (every story).
• Saying testers join only after coding.

Recap

The STLC is the testing part of the SDLC. The V-model pairs each phase with a test level. In Scrum, testers are Developers and add value in every event, most of all in refinement.