ISTQB CTFL Testing in the SDLC: Lifecycle Models, TDD/ATDD/BDD, DevOps, Shift Left and Retrospectives
Testing in the context of a software development lifecycle (SDLC) means fitting test activities to the way software is built: the chosen lifecycle decides when testing happens, how much is documented and automated, and what testers do. This CTFL lesson covers how sequential, iterative and Agile models change testing, the good practices that apply to every lifecycle, the test-first approaches TDD, ATDD and BDD, how DevOps affects testing, what shift left means and costs, and how retrospectives drive process improvement.
On this page8 sections
- How does the chosen SDLC affect testing?
- How is testing done in sequential, iterative and Agile models?
- What good testing practices apply to every SDLC?
- What are the test-first approaches: TDD, ATDD and BDD?
- How does DevOps affect testing?
- What is shift left?
- What does shift left cost, and what does it need?
- How do retrospectives improve the testing process?
- Explain how the chosen SDLC affects the scope and timing of testing, documentation detail, techniques, automation and the tester's role
- Describe how testing fits sequential, iterative and incremental, and Agile models
- Recall the good testing practices that apply to every SDLC
- Recall and distinguish the test-first approaches TDD, ATDD and BDD
- Summarise the benefits and the risks of DevOps for testing
- Explain shift left, the practices that achieve it and its cost trade-off
- Explain how retrospectives are run, recorded and used to improve testing
How does the chosen SDLC affect testing?
The software development lifecycle (SDLC) a team follows changes how testing is done, not what testing is. An SDLC model is an abstract, high-level picture of the development process, and testing has to fit into it. The syllabus names the aspects of testing that the chosen SDLC influences:
- the scope and timing of test activities, such as test levels and test types
- the level of detail of test documentation
- the choice of test techniques and test approach
- the extent of test automation
- the role and responsibilities of a tester
The SDLC changes how testing is organised, not its principles or terminology.
Common SDLC models fall into families: sequential (waterfall, V-model), iterative (spiral, prototyping), incremental (Unified Process). Within these, teams often follow more detailed software development methods and Agile practices, such as Scrum, Kanban, Lean IT, Extreme Programming, ATDD, BDD, domain-driven design, feature-driven development and TDD.
How is testing done in sequential, iterative and Agile models?
Each family of models puts testing in a different place, because each produces executable code at a different time.
| Model family | What it assumes | How testing fits |
|---|---|---|
| Sequential (waterfall, V-model) | Phases follow one another; executable code is created in later phases. | In the initial phases testers take part in requirement reviews, test analysis and test design. Dynamic testing cannot start early because there is no code to execute yet. |
| Iterative and incremental | Each iteration delivers a working prototype or product increment. | Static and dynamic testing may be performed at all test levels in every iteration. Frequent delivery needs fast feedback and extensive regression testing. |
| Agile | Change may occur throughout the project. | Lightweight work product documentation and extensive test automation (to make regression testing easier). Manual testing mostly uses experience-based test techniques that need little prior test analysis and design. |
Two points are easy to get wrong. First, a sequential model does not postpone all testing: static testing and test design start immediately; only dynamic testing waits for code. Second, in an iterative model every increment changes software that already worked, so regression testing of earlier features belongs in every iteration.
What good testing practices apply to every SDLC?
Whatever the lifecycle, the syllabus lists four good testing practices:
- For every software development activity there is a corresponding test activity, so that all development activities are subject to quality control.
- Different test levels have specific and different test objectives, which allows testing to be appropriately comprehensive while avoiding redundancy.
- Test analysis and design for a given test level begin during the corresponding development phase of the SDLC, so testing follows the principle of early testing. In a V-model, for example, system test analysis and design start while the system requirements are being written, not when the integrated system is ready.
- Testers review work products as soon as drafts are available, so earlier testing and defect detection support a shift-left strategy.
The point of distinct objectives per level is coverage without duplication.
What are the test-first approaches: TDD, ATDD and BDD?
TDD, ATDD and BDD are test-first approaches: in all three, tests are defined before the code they check is written. That makes them an implementation of early testing and of shift left, and they support iterative development. In all three the tests may persist as automated tests that protect code quality during later changes and refactoring.
| Approach | Where the tests come from | Typical form |
|---|---|---|
| Test-driven development (TDD) | Coding is directed by test cases instead of extensive software design. | Write a test, write just enough code to pass it, then refactor the tests and the code. |
| Acceptance test-driven development (ATDD) | Tests are derived from acceptance criteria as part of the system design process. | Acceptance tests written before the part of the application that must satisfy them is developed. |
| Behavior-driven development (BDD) | The desired behaviour of the application, described so stakeholders can understand it. | Test cases in simple natural language, usually Given/When/Then, which are then translated into executable tests. |
In short: TDD is anchored in a test-code-refactor cycle, ATDD in acceptance criteria, and BDD in behaviour written in natural language that stakeholders can read.
How does DevOps affect testing?
DevOps is an organisational approach that brings development (including testing) and operations together to work towards common goals. It needs a cultural shift that values operations as much as development, and it promotes team autonomy, fast feedback, integrated toolchains and technical practices such as continuous integration (CI) and continuous delivery (CD). Together these let teams build, test and release high-quality code faster through a DevOps delivery pipeline.
| Benefits for testing | Risks and challenges for testing |
|---|---|
|
|
DevOps comes with a high level of automated testing, but manual testing, especially from the user's perspective, is still needed. A large regression suite reduces repetitive manual checking; it does not replace a human judging whether the product works well for its users.
What is shift left?
Shift left is the principle of early testing applied as an approach: testing is performed earlier in the SDLC, for example without waiting for code to be implemented or for components to be integrated. It does not mean that testing later in the SDLC should be neglected.
Good practices that achieve shift left:
- Reviewing the specification from the perspective of testing; these reviews often find potential defects such as ambiguities, incompleteness and inconsistencies
- Writing test cases before the code is written and having the code run in a test harness during implementation
- Using CI, and ideally CD, because it comes with fast feedback and automated component tests accompanying the source code when it is submitted
- Completing static analysis of source code before dynamic testing, or as part of an automated process
- Performing non-functional testing starting at the component test level, where possible, rather than waiting for system testing
A useful test: every shift-left practice moves a test activity before the work it would otherwise follow. CI's contribution is that each code submission arrives with its own automated component tests and static analysis.
What does shift left cost, and what does it need?
Shift left may result in extra training, effort and/or costs earlier in the process, but it is expected to save effort and/or costs later. It is an investment, not a free saving.
Because the cost comes first and the saving later, stakeholders must be convinced of the concept and buy into it. Shift left adds early testing without neglecting the testing that comes later.
How do retrospectives improve the testing process?
A retrospective is a meeting in which the team reflects on how it worked and agrees improvements; it is a key mechanism for continuous process improvement. Retrospectives are also known as post-project meetings or project retrospectives. Retrospectives are often held at the end of a project or an iteration, at a release milestone, or whenever needed; their timing and organisation depend on the SDLC model being followed.
Who takes part: not only testers, but also developers, architects, the product owner and business analysts, the people who did the work together.
What they discuss:
- What was successful and should be retained?
- What was not successful and could be improved?
- How can the improvements be incorporated and the successes retained in the future?
Recording and follow-up: the results should be recorded and are normally part of the test completion report. Any recommended improvements must be followed up, otherwise the retrospective changes nothing.
Typical benefits for testing:
| Benefit | What it looks like |
|---|---|
| Increased test effectiveness and efficiency | Implementing suggestions for process improvement |
| Increased quality of testware | Jointly reviewing the test processes, for example agreeing to refresh stale test data |
| Team bonding and learning | The chance to raise issues and propose improvement points |
| Improved quality of the test basis | Deficiencies in the extent and quality of the requirements can be addressed and solved, for example adding missing non-functional requirements |
| Better cooperation between development and testing | Collaboration is reviewed and optimised regularly |
The testware/test basis pair is the near-twin to keep apart: problems in the tests (scripts, data, expected results) are testware; problems in what the tests are derived from (requirements, user stories, acceptance criteria) are the test basis.
Tip. Questions on this topic are short recall and understanding items, usually with an uppercase qualifier such as BEST, CORRECT or FIRST. Expect to identify which aspects of testing a lifecycle change affects, how testers work early in a sequential model versus in every iteration of an iterative or Agile model, and which of four good testing practices applies to any SDLC. Test-first items ask you to recognise TDD, ATDD or BDD from a description or a Given/When/Then example, or to order the TDD steps. DevOps items separate its benefits for testing from its risks and challenges, and ask whether manual testing is still needed. Shift-left items ask which activities count as shift left, what CI contributes, the early-cost/later-saving trade-off and the need for stakeholder buy-in; one may combine several statements in a roman-numeral item. Retrospective items cover what is discussed, who takes part, where results are recorded and which benefit (testware versus test basis) an outcome shows. Test levels, test types and maintenance testing are tested in their own topics.
- The SDLC shapes the scope and timing of testing, documentation detail, techniques and approach, the extent of automation and the tester's role; it changes how testing is organised, not its principles.
- Sequential models: early static testing and test design, but dynamic testing waits for code. Iterative models: static and dynamic testing at all levels in every iteration, with fast feedback and extensive regression testing.
- Agile favours lightweight documentation, extensive automation for regression, and experience-based manual testing.
- Every SDLC: a test activity for each development activity, distinct objectives per test level, test analysis and design during the corresponding development phase, and reviews of drafts as soon as they exist.
- TDD (test, code, refactor), ATDD (tests from acceptance criteria before development) and BDD (Given/When/Then, then automated) all define tests before the code.
- DevOps brings fast feedback, CI with component tests and static analysis, stable environments, more non-functional focus and lower regression risk, but the pipeline, tools and automation must be built and maintained.
- Manual testing from the user's perspective is still needed in DevOps.
- Shift left tests earlier without neglecting later testing; it may cost more early, is expected to save later, and needs stakeholder buy-in.
- Retrospectives involve the whole team, ask what to keep, what to improve and how, are recorded normally in the test completion report, and must be followed up.
Frequently asked questions
How does the software development lifecycle affect testing in ISTQB CTFL?
In ISTQB CTFL, the chosen software development lifecycle affects the scope and timing of test activities, the level of detail of test documentation, the choice of test techniques and test approach, the extent of test automation, and the role and responsibilities of the tester. It changes how testing is organised, not its principles or terminology.
Can dynamic testing start early in a sequential model such as waterfall or the V-model?
No. In a sequential model executable code is created in later phases, so dynamic testing cannot usually start early. Testers still contribute from the start by taking part in requirement reviews and by doing test analysis and test design.
What is the difference between TDD, ATDD and BDD?
All three are test-first approaches that define tests before the code. TDD has developers write a test, write code to pass it, then refactor the tests and code. ATDD derives tests from acceptance criteria during system design, before the feature is developed. BDD describes desired behaviour in simple natural language, usually Given/When/Then, which is then translated into executable tests.
Does DevOps remove the need for manual testing?
No. DevOps relies on a high level of automated testing in the delivery pipeline, which reduces repetitive manual testing and regression risk, but manual testing, especially from the user's perspective, is still needed.
What is shift left in software testing?
Shift left is the principle of early testing: testing is performed earlier in the software development lifecycle, for example through test-oriented specification reviews, test cases written before code, CI with automated component tests, static analysis before dynamic testing and non-functional testing from the component level. It does not mean that later testing is neglected.
Does shift left reduce testing costs?
Shift left may add training, effort or cost early in the process, but it is expected to save effort and cost later. Because the investment comes first, stakeholders need to be convinced of the approach and buy into it.
Where are the results of a retrospective recorded?
The results of a retrospective should be recorded and are normally part of the test completion report. Any recommended improvements should then be followed up so that the retrospective actually leads to continuous improvement.
Who takes part in a retrospective?
A retrospective involves not only testers but also developers, architects, the product owner and business analysts. Together they discuss what was successful and should be retained, what could be improved, and how to make those changes in future.
Source
This lesson covers the "Testing Throughout the Software Development Lifecycle" domain of the official CTFL exam guide. Vendors revise their guides — check the source for the current version.
Sign up free to mark lessons complete, bookmark topics and track your exam readiness.