Free CTFL practice test: 30 questions with answers

The principle that testing shows the presence of defects, not their absence, means a clean test run lowers risk without proving the product is defect-free. Exhaustive testing is impossible in practice, defect clustering does not make the rest of the product safe, and passing tests do not prove every requirement is met.

A human error leads to a defect in a work product, and when that defect is executed under the right conditions it can cause a failure. The other options swap the terms or wrongly attribute failures to the test environment.

Testing reveals failures that come from defects, whereas debugging is a development activity that locates and fixes the defect behind a failure. The first option reverses the two roles, the second gets the timing wrong, and the third misses that the two activities differ in purpose.

Testware is all the artifacts produced for testing, such as test cases, test data, scripts and environment items. The other options limit testware to scripts, confuse it with the test basis, or wrongly describe the product under test as testware.

Testing reduces the risk of failures in production and provides information that stakeholders use to decide whether a release is ready. It cannot guarantee zero defects, and it does not replace requirements analysis, reviews or static analysis.

Shift-left moves testing activities earlier, so integration testing starts as components become available and testers take part in reviews that catch interface problems sooner. Postponing or removing testing, or delaying planning until code freeze, does not make defects cheaper to find.

Component testing, also called unit testing, checks individual modules or classes in isolation, often with stubs or drivers standing in for missing parts. The other options describe levels that work on the whole system, its operational readiness or the interaction between parts.

Confirmation testing reruns the failed test to verify that the fix works, and regression testing reruns other tests to detect unintended side effects. The other combinations describe test types that do not verify a specific fix and its side effects in that order.

Maintenance testing is triggered by modifications, migrations and retirement of a system that is already in use. The other options describe new development or planning work that happens before any change to an operational system.

Non-functional testing covers quality characteristics such as performance and usability, and confirmation testing reruns a failed test after a fix. Functional testing occurs at many levels, white-box testing is based on code structure, and change-related testing is not limited to post-release sessions.

Static testing reviews work products such as requirements and code without executing them, whereas dynamic testing runs the software and observes its behaviour. The other options reverse the two definitions or wrongly claim that static testing needs an execution environment.

An inspection is the most formal review type, with defined roles, entry and exit criteria, and metrics used to improve the process. Informal reviews and walkthroughs use far less structure, and an email exchange between two people is not a formal review.

The scribe, also called the recorder, documents anomalies, decisions and action items during the review meeting. The moderator leads the meeting, the author revises the work product, and reviewers examine it and report findings.

Static analysis detects issues such as unused variables without executing the program, and such findings can indicate dead code or a quality concern. The other options wrongly claim a certain crash, a dynamic failure or a requirements defect.

Static testing finds defects early, before code is executed, and it can detect deviations from coding standards. Measuring response time under load and confirming platform behaviour require dynamic testing, and usage statistics come from production monitoring.

Boundary value analysis tests the values at each edge of a partition and just outside it, here 17 and 66 as invalid and 18 and 65 as valid. Typical values, evenly spread values and arbitrary extremes such as 0 and 100 do not focus on the boundaries.

Decision table testing covers combinations of conditions and their resulting actions, which suits complex business rules. Statement testing is a white-box technique, state transition testing suits systems that move between states, and error guessing depends on experience rather than a combination table.

Decision testing exercises both outcomes of each decision, and full decision coverage implies full statement coverage. Statement coverage does not check decision outcomes, and white-box tests rely on the code structure rather than being designed without it.

Error guessing is an experience-based technique in which testers anticipate likely defects, such as expired cards or negative amounts, from past knowledge. The other options are specification-based techniques that derive tests from input edges, interactions or partitions rather than experience.

Equivalence partitioning needs one representative value from each valid and invalid class, so 0.2 kg covers the low invalid class, 10 kg the valid class and 35 kg the high invalid class. The other sets miss a class, cover only valid values, or use values that do not represent the stated partitions.

Risk-based testing focuses effort where the likelihood and impact of failure are highest, and frequent change raises the likelihood. Spreading effort evenly, testing easy areas first, or skipping a frequently changed high-impact module ignores that risk.

A late test environment is a project risk because it threatens the schedule and project success rather than the quality of the product. Product risk concerns the quality of delivered software, and residual risk describes what remains after mitigation; calling it not a risk ignores its schedule impact.

Test control means taking corrective action when progress deviates from the plan, such as reprioritising tests and reallocating people. Collecting status data is test monitoring, archiving testware is test completion, and writing a strategy is test planning.

Configuration management identifies and controls versions of the test items and testware so that results can be traced to exact versions. Risk management, test estimation and defect triage address other activities and do not record which versions were tested.

A defect report must let others reproduce the failure, so numbered steps with expected and actual results are essential. Stakeholder lists, cost estimates and proposed code changes may be useful later but do not help reproduce the problem.

Test automation is most valuable for repetitive regression checks, which it runs faster and more consistently. It does not replace exploratory testing or guarantee detection of all defects, and scripts still need maintenance when the application changes.

Automation makes information about testing, such as results history, statistics and trends, easy to obtain and supports objective assessment. Failed tests still need human analysis, no suite guarantees detection of all defects, and scripts still need maintenance when the application changes.

Fragile scripts for a frequently changing feature can make maintenance cost more than the benefit, a well-known automation risk. Tools do not rewrite requirements or remove the need for test design skills, and scripts that never check anything give false confidence rather than a maintenance problem.

Keyword-driven automation describes test steps as keywords in tables, with reusable implementation code behind each keyword. Capture-replay records and plays back user actions, data-driven automation varies only the input data, and generating tests from code is not keyword-driven automation.

A test data preparation tool generates realistic, anonymised or synthetic data so that real personal data is not needed. Model-based testing tools generate test paths, defect tracking tools record failures, and static analysis tools inspect code rather than produce data.