Fundamentals of Testing practice questions

Testing proves the absence of defects.

Why it fails: Testing can never prove that a system is completely free of defects. Even if a specific path is tested, other combinations or environmental factors might trigger a crash. This principle is a fundamental misconception in testing, as comprehensive testing is impossible for complex systems, meaning some issues will always persist.

Defect clustering.

Why it fails: Defect clustering refers to the phenomenon where most defects are found in a small number of modules. While this crash might be in a clustered area, the scenario focuses on the identification of a defect through testing rather than the distribution of defects across the entire software application codebase.

Exhaustive testing is feasible.

Why it fails: Exhaustive testing is impossible for most modern systems due to the infinite number of input combinations and logical paths. Attempting to test every possible scenario is not practical or cost-effective. Testers must use risk-based approaches and test design techniques to select a representative subset of test cases.

Testing is a sub-activity of quality assurance.

Why it fails: While testing is part of a broader quality management approach, calling it a sub-activity of QA is technically inaccurate. QA focuses on process improvement and defect prevention, whereas testing is a product-oriented activity focused on verification and validation. Both are distinct disciplines that support overall quality management in organizations.

Testing activities must be completed before quality assurance starts.

Why it fails: QA activities occur throughout the entire software development lifecycle, beginning at the requirements phase. Waiting until testing is finished would defeat the purpose of QA, which is to prevent defects from being introduced during design and coding. QA should be integrated into the workflow to ensure quality throughout development.

Quality assurance and testing use the same set of tools.

Why it fails: QA and testing often use different tools. QA tools might focus on process documentation, version control, or audit compliance, while testing tools focus on automation, test management, or defect tracking. While some overlap might exist, the primary tooling for each discipline is tailored to their specific objectives and tasks.

The number of testers available.

Why it fails: While the number of testers influences the duration of testing, it does not change the total 'effort' (man-hours) required. Effort is determined by the scope and complexity of the task, regardless of how many people are assigned to complete the work, though team size impacts the timeline and resource allocation.

The color of the test report branding.

Why it fails: Cosmetic factors like report branding have no impact on the technical effort required for testing. Effort should be focused on activities that add value, such as defect identification, risk analysis, and test execution. Focusing on trivial matters wastes resources that should be dedicated to ensuring the quality of the software.

Exhaustive testing is impossible

Why it fails: Exhaustive testing refers to testing all combinations of inputs and preconditions, which is generally not feasible for complex systems. While the developer is testing, the specific act of fixing a identified defect is more closely related to showing the presence of defects than to addressing total coverage.

Defect clustering

Why it fails: Defect clustering suggests that a small number of modules usually contain the majority of defects. While this is an important principle, this scenario focuses on the individual discovery and resolution of a single fault rather than observing the distribution or concentration of defects across the entire software application.

Pesticide paradox

Why it fails: The pesticide paradox states that if the same tests are repeated over and over, eventually they will no longer find any new defects. This scenario involves an initial test execution and a fix, not the repetitive execution of existing test cases that have lost their effectiveness over time.

Test Analysis

Why it fails: Test analysis focuses on determining the scope and conditions of testing based on requirements. Since execution has already started and a database connection error has occurred, the analysis phase for this specific feature is already complete and cannot be the primary activity affected by the error.

Test Planning

Why it fails: Test planning occurs at the beginning of the project to define the strategy and schedule. While a major infrastructure failure might force a revision of the test plan, the immediate, real-time activity being performed when a log like this is generated is test execution, not planning.

Test Completion

Why it fails: Test completion happens after the project or test cycle concludes. The error indicates an active, ongoing testing session. Therefore, the team is far from the completion phase, where they would be collecting metrics and evaluating the exit criteria for the entire release or test cycle.

Defect clustering

Why it fails: Defect clustering implies that most defects are found in a small number of modules. While this might be true, the act of prioritizing based on business importance rather than predicted defect density is a risk-based approach, not a direct application of the defect clustering principle itself.

Pesticide paradox

Why it fails: The pesticide paradox refers to the reduction in the effectiveness of repeated test cases. It does not relate to the prioritization of features based on risk or business criticality. Prioritizing payment processing is a strategic decision based on impact, not a reaction to test case performance over time.

Absence of errors fallacy

Why it fails: The absence of errors fallacy suggests that finding no bugs does not mean the system is useful. This is unrelated to the decision-making process of prioritizing high-risk modules. The tester is choosing what to test based on impact, not making assumptions about the state of the software.

Test Design

Why it fails: Test design is the process of creating test cases and scenarios based on requirements. Changing an infrastructure policy requires environment management, not test design. Designing tests while the system is blocked would be unproductive and a waste of the test team's time and project resources.

Test Execution

Why it fails: Test execution is currently blocked by this policy. While the team might try to execute tests and fail, the correct process to handle an environment blocker is Test Monitoring and Control. Simply continuing to attempt execution without addressing the block is an inefficient approach to managing the test cycle.

Test Implementation

Why it fails: Test implementation focuses on creating test data and setting up the environment. While modifying the policy is technically a form of environment setup, the role of identifying this as a blocker and managing the response belongs to the monitoring and control phase of the fundamental test process.

The personal preference of the individual developer.

Why it fails: Test strategies should be based on objective criteria such as requirements, risks, and project standards. Individual preferences from developers are not a valid basis for a project-wide test strategy, as they do not provide a scalable or defensible approach to quality assurance across a large team.

The number of lines of code in the project.

Why it fails: While code size can indicate complexity, it is not a direct factor for test strategy. A small, highly critical module requires more attention than a large, low-risk module. Using lines of code as a primary driver would lead to ineffective test planning and poor resource allocation.

The programming language used for the development.

Why it fails: While technical stack matters for tool selection, the programming language itself is rarely the primary driver for a testing strategy. The context of the application—its purpose, users, and safety requirements—is far more significant than the syntax used to implement the features, making this a secondary consideration at best.

The number of hours the test team worked last week.

Why it fails: Working hours are a team management metric, not a factor in testing strategy or approach. The context of testing is determined by the system's goals, risks, and environment, not by the scheduling or productivity of the testing staff. Including this as a factor confuses operational management with quality engineering.

Testing is context-dependent.

Why it fails: While context-dependence is a principle, it refers to adjusting the strategy based on the environment and goals. Choosing to test one field over others is a prioritization decision, not a context-dependent adjustment of the overall methodology. This answer does not address the limitation of the testing scope correctly.

Defect clustering.

Why it fails: Defect clustering explains that bugs are often found in specific areas, but relying on this to ignore other areas entirely is a misapplication. Even if bugs cluster in the auth logic, the other fields (lockout duration, auth attempts) must be verified to ensure the whole system is stable and functional.

Testing shows the presence of defects.

Why it fails: This principle states that testing proves bugs exist, but it doesn't dictate how to select test cases. The issue here is the selection of the test scope, not the interpretation of the results. This principle is relevant to the *outcome* of testing, not the *planning* phase of selecting inputs.

Test execution.

Why it fails: Test execution is the act of running the tests and comparing actual results with expected results. It reveals that a failure occurred but does not investigate why. Execution is a verification activity, whereas finding the root cause of these specific cascading errors requires diagnostic analysis beyond simply running tests.

Test monitoring.

Why it fails: Test monitoring involves checking the status of testing activities against the plan. It is a management task focused on tracking progress, such as percentage of tests completed. It does not involve deep technical analysis of system logs or code to determine why a software component has failed unexpectedly.

Regression testing.

Why it fails: Regression testing is performed to ensure that changes made to the software have not adversely affected existing functionality. While it might be performed after a fix is implemented, it is not the activity used to diagnose the root cause of the current failure shown in the log exhibit.

Rigidly following the initial test plan.

Why it fails: Sticking to a rigid plan when requirements change is counterproductive. The test plan should be a living document that adapts to project changes. If testers do not update their approach, they risk testing obsolete features and missing critical new functionality, which would result in poor software quality and missed defects.

Waiting for final requirements before starting testing.

Why it fails: Waiting for final requirements often leads to delays in the project timeline. Testers should get involved early to provide feedback and identify potential issues before the code is written. By starting early, even with incomplete requirements, testers can help clarify the scope and prevent potential misunderstandings during development.

Focusing only on automated test scripts.

Why it fails: Automated scripts are difficult to maintain when requirements change rapidly. Investing heavily in automation too early without stable requirements leads to high maintenance costs and frequent script failures. Testers should prioritize exploratory testing and manual verification until the requirements become more stable to ensure efficiency and effective risk management.

Testers find fewer bugs as they spend more time on a module.

Why it fails: This describes the natural decrease in defect density as a system matures, but it does not specifically describe the pesticide paradox. The paradox is about the test suite's diminishing ability to find new bugs, not necessarily the amount of time spent or the inherent quality of the module itself.

Automated tests are less effective than manual tests.

Why it fails: This is a misconception. Both manual and automated tests have their own strengths and weaknesses. The pesticide paradox applies to any test suite, regardless of whether it is manual or automated, if the test cases remain static and are not updated to cover new functionality or different execution paths.

Testing becomes more expensive over time.

Why it fails: While testing costs can fluctuate, the pesticide paradox specifically refers to the effectiveness of test cases, not the cost. While updating tests does incur a cost, it is a necessary investment to ensure that the testing remains relevant and capable of uncovering new defects within the evolving software system.

Exhaustive testing of all features.

Why it fails: Exhaustive testing is impossible in practice. Even if it were possible, it is not efficient. In high-cost-of-failure projects, you need to focus on what matters most, rather than wasting time on trivial features. A risk-based approach is far more strategic than attempting to test everything with equal intensity.

Testing only the UI components.

Why it fails: Focusing only on the UI misses critical back-end logic, API interactions, and integration points where high-impact failures often occur. If the project has a high cost of failure, it is essential to test the entire system, not just the user-facing parts, to ensure overall reliability and security of the application.

Automated regression testing only.

Why it fails: Regression testing ensures existing features remain working, but it does not address the risk associated with new functionality or complex logic. Relying solely on regression testing leaves the project exposed to new bugs and architectural flaws, which can be catastrophic in a high-stakes environment requiring thorough and comprehensive quality verification.

Verification is for developers, validation is for testers.

Why it fails: Both testers and developers participate in both verification and validation. Testers verify requirements through reviews and validate functionality through execution. Developers perform verification during unit testing and validation during integration. These are concepts applied to the entire software development process, not roles assigned exclusively to specific job titles or departments.

Validation is done early; verification is done late.

Why it fails: Both processes occur throughout the entire development lifecycle. Verification starts with requirements and design reviews, while validation can start with prototypes and user feedback sessions. Waiting until the end to perform either verification or validation is a major risk that can lead to costly late-stage rework and project failure.

Verification is testing; validation is debugging.

Why it fails: Neither verification nor validation is synonymous with debugging. Debugging is a corrective action taken when a failure is found. Verification and validation are methods of ensuring that the software quality is maintained throughout the development process, whether through documentation review, static analysis, or dynamic testing and execution.

To guarantee that the software is bug-free.

Why it fails: No testing process can guarantee that software is completely bug-free. The goal of testing is to reduce the probability of undiscovered defects through systematic investigation and verification. Claiming that software is bug-free is a fundamental misunderstanding of the limitations of testing and the nature of complex software development.

To find as many bugs as possible.

Why it fails: While finding bugs is a core activity, the ultimate goal is to provide quality assurance and confidence. Simply chasing the highest number of bugs might not be effective if those bugs are trivial. The objective is to find significant, impactful defects that improve the overall reliability of the system.

To automate as many test cases as possible.

Why it fails: Automation is a means to an end, not an objective in itself. The goal is not to have the highest number of automated tests, but rather to have effective tests that ensure quality. Over-automating can lead to high maintenance burdens and can distract from critical exploratory testing activities.

Checking if the code correctly parses the JSON file.

Why it fails: Checking if the JSON is parsed correctly is a verification activity. It ensures that the system handles the input format as specified by the technical design. It does not address whether the policy itself is appropriate for the business or if it effectively protects the application from real-world threats.

Verifying that the password length is exactly 12 characters.

Why it fails: Verifying that the implementation matches the requirement (12 characters) is a verification task. It checks internal consistency with the specification. It confirms the system was built 'right' according to the document but doesn't validate if a 12-character password is actually sufficient for the organization's security needs.

Running a syntax check on the JSON configuration file.

Why it fails: A syntax check ensures that the file format is valid JSON. This is a purely technical verification activity. It confirms the file is readable by the system but tells the tester nothing about whether the policy values inside the file are correct or if they meet the business's security requirements.

The list of identified defects.

Why it fails: A list of identified defects is a test output or artifact generated during test execution. It is not the source material for creating tests. The test basis must exist before testing starts, while defect reports are produced as a result of testing activities throughout the software development lifecycle.

The source code of the application.

Why it fails: While source code can be used for white-box testing, it is not the primary test basis for functional testing. The test basis should be the requirement and design documents that specify the intended behavior. Relying on source code alone assumes that the code itself is the specification, which is incorrect.

The test execution report.

Why it fails: A test execution report is a final summary of testing results. It is generated after testing is performed. It cannot be used as a test basis because it does not provide the information about what the system is supposed to do; it only records what happened during the test execution phase.

Confirmation testing.

Why it fails: Confirmation testing (re-testing) only checks if the original bug has been fixed. It does not verify if the fix caused other parts of the application to break. While essential, it is insufficient on its own when code changes are involved, because it only covers the specific issue reported originally.

System testing.

Why it fails: System testing is a broad phase focused on testing the whole integrated system. While it might uncover the new issue, it is not the most efficient way to verify a specific fix. Regression testing is the targeted approach required to ensure that the code change hasn't negatively impacted stable functionality.

Static testing.

Why it fails: Static testing involves reviewing documentation or code without executing it. While it can identify potential issues early, it cannot verify the behavior of the software after a code change. Dynamic testing, specifically regression testing, is required to detect the runtime side effects caused by the developer's new code changes.

Executing test cases on the system.

Why it fails: Executing test cases is a form of dynamic testing, not static. It requires the software to be running. Static testing is defined by the absence of code execution, focusing instead on documentation, design diagrams, or source code analysis to find errors before the system is actually built or deployed.

Running a performance load test.

Why it fails: Performance load testing is a dynamic activity that measures system behavior under simulated stress. It requires the application to be running in an environment. Since it involves executing the software to gather metrics, it is categorized as dynamic testing, not static testing, and is performed after the system is implemented.

Performing user acceptance testing.

Why it fails: User acceptance testing is a dynamic testing phase performed by users to ensure the software is fit for purpose. Because it involves interacting with the running software to validate requirements, it is a form of dynamic testing, which is distinct from static techniques like reviews or static code analysis.