The software development lifecycle (SDLC) describes the stages software typically goes through: planning, design, development, testing, deployment, and maintenance. Testing itself has multiple levels — unit testing checks individual components in isolation, integration testing checks how components work together, and system testing checks the complete application — catching problems earlier in this sequence is generally far cheaper to fix than catching them after release.
Example
A bug in a single function might be caught immediately through unit testing during development, costing minutes to fix — but if that same bug slips through to a live app used by thousands of people, fixing it becomes far more costly and disruptive, involving emergency patches and damaged user trust.
Key terms
SDLC:
Software Development Lifecycle — the stages software typically goes through from planning to maintenance.
Unit testing:
Testing individual components of software in isolation.
Integration testing:
Testing how different components work together.
Questions
1. SDLC stands for:
Software Development Lifecycle
System Design and Launch Cycle
A term unrelated to software
Single Development Launch Code
2. Unit testing checks:
Individual components in isolation
The entire finished application only
Nothing related to code quality
Only the user interface, with no code testing
3. Integration testing checks:
How components work together
A single component in complete isolation
Nothing related to how components interact
Only the visual design of an app
4. System testing checks:
The complete application
Only a single, isolated function
Nothing related to the application as a whole
Only the database, with no other components
5. The SDLC includes stages such as:
Planning, development and testing
Only a single, undivided stage
Stages unrelated to building software
Only marketing, with no development involved
6. Catching a bug earlier in development is generally:
Cheaper to fix than catching it after release
Always more expensive than fixing it after release
Exactly as costly regardless of when it's caught
Irrelevant to the cost of fixing a bug
7. Maintenance is a stage that occurs:
After deployment, to keep software working over time
Only before any code has been written
A stage that never actually exists in the SDLC
Only during the very first day of a project
8. Why might unit testing be considered the first line of defence against bugs, compared to system testing?
It catches problems in individual components early, before they can combine with other code and become harder to trace
Unit testing always happens after system testing in every development process
Unit testing has no ability to catch any bugs before the complete application is tested
System testing always catches every bug more effectively than unit testing could
9. Why might a bug that passes unit testing still be caught during integration testing?
A component might function correctly on its own but behave unexpectedly when interacting with other components
Integration testing never catches any bugs that unit testing has already missed
Components always behave identically whether tested alone or combined with others
Bugs caught during integration testing are always identical to those caught during unit testing
10. Why is the planning stage considered important before development begins, rather than diving straight into coding?
Clear planning helps define requirements and reduce costly changes or misunderstandings later in the process
Planning has no effect on how smoothly the later stages of development proceed
Skipping planning and diving straight into coding is always the most efficient approach
Requirements and misunderstandings are never actually clarified during a planning stage
11. Why might maintenance be considered an ongoing stage rather than a one-time final step in the SDLC?
Software often needs updates, bug fixes and improvements throughout its entire lifespan after release
Maintenance always ends the moment software is first deployed, with no further work needed
Software never requires any updates or fixes once it has been released
The SDLC ends completely and permanently as soon as deployment occurs
12. Why might the SDLC be described as a cycle rather than a strictly linear, one-directional process?
Findings from testing or maintenance often loop back to inform further design or development changes
The SDLC always proceeds through each stage exactly once, with absolutely no possibility of returning to an earlier stage
Testing and maintenance never provide any information relevant to earlier stages of development
A linear, one-directional process always perfectly describes how real software development occurs
13. Why might automated testing (rather than only manual testing) be increasingly used in modern software development?
Automated tests can be run quickly and repeatedly, catching regressions efficiently as code changes over time
Automated testing is always significantly less reliable than manual testing in every situation
Manual testing is always faster and more thorough than any automated approach
Automated tests provide no advantage over manual testing for any kind of software project
14. Why might IBM's finding that bugs cost 6x to 100x more to fix after deployment (compared to during development) support investing heavily in early-stage testing?
The dramatic cost increase illustrates the financial value of catching and fixing issues as early in the SDLC as possible
This cost difference suggests there is no real benefit to catching bugs earlier in the process
Fixing bugs always costs an identical amount regardless of which stage they are caught in
Investing in early-stage testing has no meaningful connection to overall project cost
15. Why might large, complex software projects benefit particularly strongly from a structured SDLC, compared to a small personal project?
Coordinating many people, components and requirements benefits from clear stages, documentation and testing practices
Structured processes only ever benefit small, simple projects, never large and complex ones
Large software projects never actually require any particular structure or process
The complexity or size of a project has no bearing on how useful a structured development process is
16. Why might skipping system testing before deployment be particularly risky, even if unit and integration tests have all passed?
System testing verifies the complete, real-world behaviour of the application, which passing smaller-scale tests doesn't fully guarantee
Passing unit and integration tests always guarantees the complete system will also work correctly
System testing provides no additional useful information beyond what unit and integration testing already reveal
Skipping any level of testing never introduces any additional risk to a software release
17. The deployment stage of the SDLC involves:
Releasing the software for actual use
Only the very first planning discussions
Deleting the software entirely
A stage that occurs before any code has been written
18. A test that checks whether a login form correctly rejects an invalid password is an example of:
A type of software testing
A stage of planning, not testing
Something unrelated to the SDLC
A maintenance-only activity with no connection to testing
19. Why might agile development approaches (with frequent short cycles of planning, development and testing) be popular for projects with changing requirements?
Shorter cycles allow the team to adapt more quickly to new information or changing needs than a single long, rigid process
Agile approaches always take significantly longer than a single long, rigid development process
Frequent cycles of planning and testing provide no benefit when requirements are likely to change
Changing requirements have no bearing on which development approach might be most suitable
20. Why might a company invest in a dedicated quality assurance (QA) team, separate from the developers who wrote the code, to conduct testing?
An independent perspective can catch issues or assumptions the original developers might overlook
A separate QA team provides no additional benefit over developers testing their own code exclusively
Developers always catch every possible issue in their own code without needing independent testing
Quality assurance has no meaningful role to play in the software development process
21. Why might requirements gathered during the planning stage sometimes need revisiting once development or testing reveals new information?
Building or testing software can surface practical constraints or gaps that weren't apparent during initial planning
Requirements identified during planning are always perfectly complete and never need any revision
Development and testing never reveal any new information relevant to a project's original requirements
Revisiting requirements partway through a project is never a genuinely useful or necessary practice
Answer key (parent copy)
1. Software Development Lifecycle
2. Individual components in isolation
3. How components work together
4. The complete application
5. Planning, development and testing
6. Cheaper to fix than catching it after release
7. After deployment, to keep software working over time
8. It catches problems in individual components early, before they can combine with other code and become harder to trace
9. A component might function correctly on its own but behave unexpectedly when interacting with other components
10. Clear planning helps define requirements and reduce costly changes or misunderstandings later in the process
11. Software often needs updates, bug fixes and improvements throughout its entire lifespan after release
12. Findings from testing or maintenance often loop back to inform further design or development changes
13. Automated tests can be run quickly and repeatedly, catching regressions efficiently as code changes over time
14. The dramatic cost increase illustrates the financial value of catching and fixing issues as early in the SDLC as possible
15. Coordinating many people, components and requirements benefits from clear stages, documentation and testing practices
16. System testing verifies the complete, real-world behaviour of the application, which passing smaller-scale tests doesn't fully guarantee
17. Releasing the software for actual use
18. A type of software testing
19. Shorter cycles allow the team to adapt more quickly to new information or changing needs than a single long, rigid process
20. An independent perspective can catch issues or assumptions the original developers might overlook
21. Building or testing software can surface practical constraints or gaps that weren't apparent during initial planning