Testing Throughout the SDLC Interview Questions for ISTQB

In sequential models like waterfall and the V-model, testers join early for reviews and planning, but dynamic testing happens later once code exists. In iterative and incremental models such as Scrum, every iteration delivers a working increment, so static and dynamic testing happen at all levels in each iteration, regression testing is critical and automation is usually needed. The model affects scope, timing, documentation, techniques and automation.

Shift-left means performing testing earlier in the SDLC. Practices include reviewing specifications from a tester's perspective, writing test cases before code, using CI/CD for fast feedback, running static analysis before dynamic testing and starting non-functional testing at component level. It costs extra effort early, but saves much more later, because a defect found in requirements is far cheaper to fix than one found in production.

A retrospective is held at the end of an iteration, release or project to discuss what went well, what did not and how to improve. For testing, the benefits include more effective and efficient testing, better testware, team bonding, better quality of the test basis and stronger cooperation between developers and testers. Results should be recorded and the improvement actions tracked so that they are actually carried out.

Component testing checks individual units in isolation. Component integration testing checks interfaces and interactions between components. System testing checks overall behaviour, both functional and non-functional. System integration testing checks interfaces with other systems and external services. Acceptance testing focuses on validation and readiness for deployment. Each level has its own objectives, test basis, test objects, typical defects and responsibilities.

User acceptance testing is done by intended users. Operational acceptance testing is done by operations staff and covers backup, restore, installation and disaster recovery. Contractual and regulatory acceptance testing checks contract criteria or legal rules. Alpha testing is done by potential users at the developer's site, and beta testing by users at their own locations. Acceptance testing mainly builds confidence and validates fitness, not defect finding.

Confirmation testing checks that an original defect has been fixed, by re-running the failed tests or new tests that cover the change. Regression testing checks that a change, including a fix, has not caused adverse effects elsewhere, in the same component, connected components or the environment. Regression suites grow and run often, so they are strong candidates for automation, typically inside a CI pipeline.

This is system integration testing, because it tests the interface between our system and an external system, the credit bureau API. If it checked the interface between two internal modules of our own application, it would be component integration testing. In exam questions, keywords such as 'external system', 'third-party service' or 'other systems' point to system integration testing.

This is user acceptance testing, because intended users validate that the system meets their needs in a realistic environment before deployment. If it were a commercial product released to external customers at their own sites for feedback, it would be beta testing. If potential users tested it at the developer's site, it would be alpha testing. Look for who tests and where.

Model answer: I enjoy finding how things break and thinking from the user's side. During my degree I tested our team project and found issues others missed, which built my interest. I studied the ISTQB Foundation syllabus to learn standard terms and techniques. I want to grow from manual testing into automation and domain expertise, and testing lets me understand the whole product and the full SDLC.

CTFL v4.0 lists these: for every software development activity there is a corresponding test activity; each test level has its own specific objectives; test analysis and design for a level begin during the corresponding development phase; and testers are involved in reviewing work products as soon as drafts are available. Together these practices support early testing and quality control in waterfall, V-model and Agile projects alike.

All three are test-first approaches. In TDD, developers write a failing unit test, write code to pass it, then refactor. In ATDD, acceptance tests are derived from acceptance criteria with the team and business before development starts. In BDD, desired behaviour is written as Given/When/Then scenarios in natural language that stakeholders understand and that can be turned into executable tests. All three support shift-left.

DevOps joins development and operations through a CI/CD pipeline. Benefits for testing: fast feedback on code quality, shift-left through automated component tests and static analysis on every commit, stable environments through automation, more visibility of non-functional qualities and less repetitive manual work. Risks: the pipeline must be defined and maintained, CI/CD tools must be set up, and automation needs extra resources. Manual testing from the user's perspective is still needed.

Functional testing checks what the system should do, covering completeness, correctness and appropriateness. Non-functional testing checks how well it behaves, using ISO/IEC 25010 characteristics such as performance efficiency, usability, security, reliability, compatibility, maintainability and portability. Black-box testing is specification-based, and white-box testing is structure-based. Any test type can be applied at any test level, with a different focus at each.

Component integration testing focuses on interfaces between components of the same system and is usually done by developers or testers who know the architecture, often with stubs and drivers. System integration testing focuses on interfaces with other systems and external services, such as payment gateways or government APIs, and needs production-like environments. Incremental integration, top-down or bottom-up, is preferred over big-bang because it localises defects.

I would join backlog refinement to review stories and acceptance criteria, help estimate test effort in sprint planning, write acceptance tests early, pair with developers on automation, test each story as soon as it is ready, keep regression running in the CI pipeline, run exploratory sessions on new features and share testing feedback in the retrospective. Testing runs continuously rather than at the end of the sprint.

I would do a quick impact analysis to see what the change touches, run confirmation tests for the defect, then a risk-based regression subset covering the changed module, its integrations and critical business flows like login and payment. I would use the automated smoke suite in the pipeline, record what was not covered, and plan fuller regression in the next regular release.

Situation: stories reached me only in the last two days of each sprint. Task: stop testing from being a bottleneck. Action: I proposed writing acceptance criteria and test cases during refinement, asked developers to merge smaller stories earlier, and automated API checks in the CI pipeline. Result: within three sprints, carried-over stories fell from five to one, and the team added early testing to its definition of done.

Situation: our releases had many defects traced to unclear requirements. Task: reduce them without slowing delivery. Action: I showed data that about 40 percent of defects started in requirements, piloted requirement reviews and three-amigos sessions in one team, and tracked the results. Result: requirement-related defects dropped by roughly half over two releases, and other teams adopted the practice.

Maintenance testing covers changes to a system already in production. Triggers are modifications such as enhancements, corrective fixes or hotfixes; upgrades or migrations of the operational environment, including data migration; and retirement of an application, which may need archiving and restore tests. Scope depends on the risk of the change, the size of the existing system and the size of the change, with impact analysis guiding regression selection.

Non-functional tests are often left to the end, but late discovery of performance or security problems can threaten the whole project. v4.0 recommends starting early, even at component level, for example measuring response time of a key service. Some tests need special environments such as a usability lab. Many non-functional tests reuse functional tests but measure a different quality, like checking login speed under 500 concurrent users.

This is maintenance testing triggered by migration. I would check data completeness with record counts and checksums, data accuracy through sampling and reconciliation reports, transformation rules, performance on the new platform and rollback procedures. Operational acceptance testing covers backup, restore and failover. Regression testing of key functions on migrated data is needed, and retiring the old system may need archiving tests.

I would push component tests and static analysis into the pipeline on every commit, build a test pyramid with many unit tests, fewer API tests and few UI tests, provision environments through infrastructure as code and add production monitoring. Testers shift from long test phases to continuous risk analysis, exploratory testing and quality coaching. I would plan training and track metrics like lead time and escaped defects.

Identify changed items from commits and change requests; use traceability to find affected requirements, components and interfaces; check dependency maps and defect history; rank the affected areas by risk; select automated regression for broad coverage plus targeted manual tests for high-risk flows; and document what is excluded and why. Impact analysis can also help decide whether a risky change should be made at all.