Testing Throughout the SDLC practice questions

Document the ambiguity in the defect tracking tool and wait for the developer to fix it.

Why it fails: Defect tracking tools are intended for bugs discovered during the execution of the software, not for requirement clarifications. Using a bug tracker for planning ambiguities creates unnecessary administrative overhead and fails to utilize the collaborative communication channels essential for Agile teams to resolve issues efficiently and quickly.

Wait until the unit testing phase to verify how the code interprets the ambiguous requirement.

Why it fails: Waiting for unit testing is a reactive approach that contradicts the shift-left testing principle. Discovering an ambiguity during coding leads to rework, increased costs, and project delays. Addressing requirements early ensures that developers build the right functionality the first time, preventing wasted effort during the software development process.

Proceed with writing test cases based on the tester's own assumption of the requirement.

Why it fails: Making assumptions about requirements is a high-risk activity that often leads to invalid test cases and incorrect product behavior. Testing based on incorrect assumptions results in a mismatch between the delivered product and business needs, ultimately leading to higher maintenance costs and poor customer satisfaction scores upon release.

Testing only occurs after the development phase is finished.

Why it fails: Modern SDLC models, especially Agile and DevOps, emphasize shifting left, meaning testing starts during requirements analysis and design. Waiting until the end of development is a characteristic of traditional models that are prone to high rework costs and delayed detection of fundamental design flaws.

Testing is an independent phase that is separate from development.

Why it fails: Testing is not an isolated phase; it is an integral activity that occurs concurrently with development. In cross-functional teams, testers, developers, and business stakeholders collaborate throughout the lifecycle to ensure quality is built into the product rather than just inspected at the very end.

Testing activities are identical regardless of the SDLC model used.

Why it fails: While the fundamental principles remain constant, the execution of testing activities varies significantly between SDLC models. For example, Agile requires continuous integration and automated testing, while a V-model approach relies on formal, sequential test phases tied to specific documentation milestones like design specifications.

Immediately request a code change to the authentication module.

Why it fails: Requesting a code change is premature without understanding whether the failure is caused by configuration, network latency, or an actual logic defect. The tester must first conduct root cause analysis to verify if the issue stems from the policy settings provided in the exhibit before suggesting code modifications.

Increase the timeout value to 600ms and retry the test.

Why it fails: Arbitrarily increasing the timeout is a guess rather than a systematic testing approach. The tester should perform tests to determine the optimal threshold for the timeout and retry limit under load, ensuring that the system handles failure gracefully rather than just masking the underlying performance bottleneck.

Report a critical defect for the OAuth2 protocol implementation.

Why it fails: Reporting a defect against the protocol itself is incorrect, as OAuth2 is a standard and likely not the cause of the failure. The failure is more likely related to how the application implements or configures the protocol under load, which must be verified through local investigation and performance testing.

Verifying that all software features work perfectly.

Why it fails: It is impossible to verify that software works 'perfectly' due to the constraints of time, budget, and the impossibility of exhaustive testing. The goal is to identify as many high-risk defects as possible to reach a level of quality that is acceptable for the intended user base.

Guaranteeing that there are no bugs remaining in the code.

Why it fails: Testing can show the presence of defects, but it can never prove their total absence. Claiming to 'guarantee' a bug-free system is misleading and goes against the fundamental ISTQB principle that testing reduces the probability of undetected defects but cannot ensure 100% perfection in any software system.

Component testing.

Why it fails: Component testing focuses on individual software units or classes in isolation from the rest of the system. It validates the correctness of the code's logic and internal functionality, but it does not concern itself with how the module interacts with other system parts.

Acceptance testing.

Why it fails: Acceptance testing is the final level of testing performed to confirm that the system meets the business needs and is ready for deployment. It focuses on the system as a whole from the user's perspective, rather than the low-level interactions between individual software modules.

Maintenance testing.

Why it fails: Maintenance testing is performed on an already operational system to verify the impact of changes or updates. While it may involve integration testing of the new changes, it is a category based on the system's lifecycle stage rather than the level of testing defined in the SDLC.

Verification of performance under high user load.

Why it fails: Static testing cannot evaluate dynamic system performance. Performance testing requires code execution, load generation, and system monitoring to observe how the application handles concurrent users. Static methods only deal with the static structure of the work product, not the system's runtime dynamic behavior.

Elimination of the need for dynamic testing entirely.

Why it fails: Static testing is a complementary activity, not a replacement for dynamic testing. Even with the most thorough reviews, some defects—such as environment-related issues or complex runtime edge cases—can only be identified through dynamic execution. Both are necessary to ensure comprehensive software quality throughout the SDLC.

The log level set to debug will cause an overflow error in the production database.

Why it fails: While high-verbosity logging can impact performance in production, it does not directly cause database overflow errors. The primary risk associated with debug logging is security exposure of sensitive data in logs, not the functional failure of database storage mechanisms during standard software execution or testing phases.

The exponential retry policy will increase the latency of the system during stress testing.

Why it fails: Retry policies are designed for resilience and fault tolerance. While they can affect timing, they are not the primary cause of latency during stress tests. The critical risk here is the permissive 'strict_mode: false', which hides potential integration failures that should be surfaced during testing activities.

The environment tag set to 'dev' indicates that the deployment is insecure by design.

Why it fails: An environment tag named 'dev' is a common naming convention and does not inherently define security protocols. The security posture is determined by the specific configuration parameters like 'strict_mode'. Static analysis of the configuration file must focus on the functional parameters rather than the metadata labels used.

Executing automated regression tests at the end of each daily build.

Why it fails: Regression testing is a form of dynamic testing that happens after code is produced. While it provides feedback, it is not considered 'early' because it occurs after implementation has already started or completed for that specific feature, missing the opportunity to prevent defects at the design stage.

Conducting a performance test on the integrated system before the final release.

Why it fails: Performance testing at the end of the SDLC is late-stage testing. While important for validating the system, it does not provide 'early' feedback. Problems found at this stage are significantly more expensive and time-consuming to fix because they often require deep architectural changes or complex code refactoring.

Reporting defects found during the User Acceptance Testing (UAT) phase.

Why it fails: UAT occurs at the very end of the SDLC. Defects discovered at this stage are the most expensive to resolve because they require changes to finished software. Providing feedback this late does not adhere to the principle of early testing or minimizing the cost of quality.

Testers are solely responsible for all quality activities within the project.

Why it fails: Quality is the responsibility of the entire team, not just the testers. Developers, business analysts, and product owners all contribute to quality through practices like unit testing, code reviews, and clear requirement definition. Placing the entire burden on testers creates silos and hinders effective continuous delivery processes.

Testers should focus exclusively on dynamic testing to prove the system works.

Why it fails: Testing is more than dynamic execution. Static testing, such as reviews and static analysis, is equally critical for catching defects early. Limiting the role to dynamic testing ignores the cost-saving benefits of preventing defects during the design and requirements phases, which is a fundamental tenet of software testing.

Testers should avoid participating in code reviews to remain unbiased.

Why it fails: Participation in code reviews is a highly effective way for testers to understand the system architecture and identify potential defects in logic. Being involved in the technical review process does not compromise objectivity; rather, it increases the tester's knowledge, allowing for more comprehensive and effective testing later on.

Manual exploratory testing of every build before it is moved to production.

Why it fails: Manual testing is too slow to support a continuous deployment model. Relying on manual testing creates a bottleneck that slows down the release cycle, preventing the team from achieving continuous delivery. Automated suites are required to handle repetitive tasks quickly and provide immediate feedback on build stability and quality.

Performing formal, document-heavy system testing cycles after every code merge.

Why it fails: Formal, document-heavy processes are too heavy for DevOps environments. These activities are time-consuming and create friction in the development pipeline, which contradicts the DevOps goal of rapid, iterative delivery. DevOps relies on lightweight, automated, and continuous feedback loops rather than batch-based, document-centric verification cycles.

Requiring a separate QA phase where developers are not involved in testing.

Why it fails: Separate QA phases create hand-offs and delays that break the DevOps flow. Collaboration between developers and testers is essential for rapid feedback. Encouraging shared responsibility for quality ensures that code is written with testability in mind, reducing the time required for bug fixes and deployments.

Elimination of the need for any dynamic testing in the later stages.

Why it fails: Static testing cannot replace dynamic testing. While it prevents many defects, dynamic testing is still required to verify the actual behavior of the running code, integration with hardware or databases, and overall system performance. Both approaches are necessary to provide high confidence in the final software product.

Automated code coverage analysis of the requirement document.

Why it fails: Static testing of requirements is a manual process involving reviews and analysis. Code coverage is a metric associated with dynamic testing, specifically applied to source code after it has been executed. You cannot calculate code coverage on a requirement document, as there is no executable code to measure.

Ignore the error as it only occurs under high load, which is not the primary focus.

Why it fails: Performance testing is a critical part of the SDLC. Ignoring performance-related errors like connection pool exhaustion leads to production failures under real-world usage. A robust system must handle expected load levels, so these errors indicate a defect that must be prioritized and corrected to meet non-functional requirements.

Increase the number of threads in the API gateway to mask the timeout.

Why it fails: Simply increasing threads is a reactive fix that often hides the underlying issue without resolving the resource exhaustion. This is poor practice as it ignores the root cause, which is a connection pool mismanagement, likely leading to similar issues in the future as the user base grows further.

Immediately roll back the last code deployment to the production environment.

Why it fails: Rolling back is premature without understanding the cause. If the issue is a standard configuration oversight, a rollback will not fix it. The tester must first investigate and confirm if the issue is code-related or environment-related before recommending any irreversible actions like rolling back a production deployment.

Testing is a distinct phase that occurs only after the final system integration.

Why it fails: In the V-model, testing occurs throughout the SDLC. Each phase—from requirements to coding—has a corresponding testing level (e.g., acceptance testing for requirements, system testing for architecture, and component testing for code). Limiting testing to the final integration phase is a misunderstanding of the V-model's structure.

Testing is used solely for defect detection at the very end of the development process.

Why it fails: The V-model is designed to prevent defects by incorporating testing early. By planning and designing tests alongside the development phases, teams can verify specifications early. Focusing only on defect detection at the end ignores the prevention benefits of the V-model, which is the primary purpose of the structure.

Testing consists only of the execution of automated scripts against the finished code.

Why it fails: The V-model includes static testing activities like reviews of documents and specifications. Limiting testing to automated script execution against code is incomplete, as it ignores the critical role of static analysis in ensuring that requirements and design are sound before the expensive coding process even begins.

To identify performance issues that might impact system scalability.

Why it fails: Performance issues are evaluated through dynamic testing, such as load or stress testing, where the code is actually running. Static testing, by definition, does not involve executing software, so it cannot be used to measure runtime performance characteristics or identify bottlenecks in system scalability or resource utilization.

To verify that the software meets all functional requirements through execution.

Why it fails: Verifying that the software meets functional requirements through execution is the definition of dynamic testing. Static testing is concerned with analyzing documents and code without execution. Therefore, this option incorrectly identifies the primary method and objective of static testing, which is primarily focused on prevention and early verification.

To generate test data for future automated testing sessions.

Why it fails: While static testing can help define the requirements for test data, it is not the primary objective of the process itself. The generation of test data is a separate preparation task within the test design process, not the purpose of static testing, which focuses on evaluating work products for defects.

The password length requirement is too short and will cause an execution error.

Why it fails: A password length of 8 is a standard security configuration and would not cause an execution error in the software. This is a policy decision rather than a technical defect. Static testing should focus on whether this policy meets security guidelines rather than assuming it causes an execution error.

The lockout duration is a configuration parameter that doesn't impact security.

Why it fails: Lockout duration is a critical security configuration parameter. It directly impacts how effectively the system can mitigate brute-force attacks. Dismissing it as having no impact is a dangerous misconception; testers must evaluate security policies to ensure they align with the organization's risk tolerance and threat model for the application.

The system will fail to compile because the policy is written in JSON format.

Why it fails: JSON is a standard data-interchange format and will not cause a compilation failure. The configuration is meant to be read by the system at runtime. The issue is not the format, but rather the adequacy of the security policy settings themselves, which must be validated during the static testing phase.

It ensures that the developers have less work to do because testers find all the bugs.

Why it fails: Testing is not a substitute for developer quality efforts. If testers find all the bugs, it means quality was not built into the development process. The goal is to collaborate, not to offload bug-fixing work. High-quality software results from developers and testers working together to prevent and fix defects throughout the SDLC.

It removes the need for communication between the development and testing teams.

Why it fails: Effective testing requires more communication, not less. Testing and development teams must be in constant dialogue to understand requirements, clarify expected behaviors, and ensure quality. Planning early actually increases the frequency and quality of this interaction, making it a vital part of a successful, collaborative development team environment.

It makes it impossible to change requirements once the project has started.

Why it fails: Early planning is not about freezing requirements; it is about clarifying expectations. Modern development environments expect change. The benefit of early planning is that it provides a structure that can accommodate change more effectively, as the testing team is already informed and ready to adjust their test cases as the project evolves.

The test team successfully implemented automated recovery procedures.

Why it fails: Service restarts are a recovery procedure, but they do not address the memory leak causing the 90% usage. The existence of an ERROR log followed by a restart indicates that the system is failing, not that the recovery is a success. True success would be preventing the memory exhaustion entirely.

The memory leak was identified and resolved during the early development phase.

Why it fails: If the memory leak had been resolved, the system would not be reaching 90% usage and triggering restarts. The logs confirm that the memory issue is still active in the current test environment, which means the testing process failed to identify or verify the fix for this defect early.

The log level configuration is too strict, causing unnecessary restarts.

Why it fails: Log levels indicate the verbosity of information, not the cause of system failure. Restarts are triggered by the logic of the application when the memory reaches 90%. Changing the log level would change what is recorded, but it would not fix the underlying memory exhaustion that is triggering the restart.

Acceptance testing by the product owner.

Why it fails: Acceptance testing is focused on validating whether the feature meets business requirements and user needs. It typically occurs after unit and integration testing are complete to confirm the feature is ready for release, rather than checking for regressions in existing system functionality.

System integration testing against all legacy systems.

Why it fails: System integration testing is a broad scope activity that checks the interaction between multiple subsystems. While important, it is usually scheduled as a periodic milestone or release-level activity rather than an immediate response to a single developer's small code commit.

Manual exploratory testing of the entire application.

Why it fails: Manual exploratory testing is valuable for discovering new defects and learning the application's behavior. However, it is not practical or scalable to perform a full manual regression sweep after every single code commit, as it would significantly hinder development velocity and feedback loops.

Executing test cases against a running application.

Why it fails: Executing test cases against a running application is the definition of dynamic testing. Dynamic testing requires the software to be in a runnable state so that inputs can be processed and outputs can be compared against the expected behavior to identify functional defects in the implementation.

Measuring the code coverage during unit testing.

Why it fails: Measuring code coverage during unit testing is part of dynamic testing because the code must be compiled and executed to collect coverage data. This activity focuses on verifying the dynamic flow of control and data within the software, rather than reviewing the static text of requirements.

Running automated integration tests in the CI/CD pipeline.

Why it fails: Running automated tests in a CI/CD pipeline is a dynamic testing activity because it involves building the software and running it through a series of automated checks. The objective is to verify the successful integration of system components through actual execution in a real execution environment.

The developer no longer needs to perform debugging.

Why it fails: Debugging remains a critical activity for developers regardless of the testing strategy. Writing tests first helps identify when a feature fails, but the developer must still analyze the code, trace the logic, and perform the necessary repairs to resolve the root cause of the failure.

The developer delegates all testing responsibilities to the QA team.

Why it fails: Test-First approaches actually increase the developer's involvement in testing. By writing tests themselves, developers take direct responsibility for the quality of their code. Delegating all testing to the QA team would contradict the principle of developer-led unit testing required for successful Test-Driven Development.

The developer waits for a test plan to be approved by the test manager.

Why it fails: Test-First approaches are designed to be fast and iterative, which is incompatible with waiting for formal test plans or bureaucratic approvals. The developer works in short cycles of creating a test, running it, writing code, and then refactoring to ensure immediate progress and feedback.