Free CTFL practice questions

Software testing is a set of activities to discover defects and evaluate the quality of software artifacts.

Testing has two purposes in its definition: discovering defects and evaluating quality. Its test objects are software work products in general, not only running code. Removing the causes of failures is debugging, and improving the process is quality assurance. Executing software to show that it works is the misconception that testing is just running tests.

1. Recall the two parts of the definition: discover defects, evaluate quality.
2. Remove the option that describes debugging (finding and removing causes).
3. Remove the option that describes process improvement (quality assurance).
4. Reject the narrow view that testing only executes software to show it works.

Exam tip: Testing = discover defects + evaluate quality of any software work product.

The chosen SDLC influences the scope and timing of test activities, the detail of test documentation, test techniques and approach, the extent of test automation, and the tester's role.

How much a team documents its testing depends on the lifecycle: sequential models tend to produce detailed documents up front, while Agile prefers lightweight work products. The other options are fundamental definitions and principles of testing. They are tempting because they are true statements, but they hold in every lifecycle and so are not influenced by it.

1. Recall the list of things the SDLC affects: scope and timing, documentation detail, techniques, automation, tester role.
2. Check each option against that list.
3. Recognise that terminology and principles are lifecycle-independent.
4. Choose the level of detail of the test documentation.

Exam tip: The SDLC changes how testing is done, not what testing terms and principles mean.

Almost any work product can be examined by static testing, as long as people can read and understand it (for reviews) or it has a structure a tool can check (for static analysis).

Requirements, code, test plans, test cases, backlog items, test charters, project documentation, contracts and models can all be examined statically. The exception is a work product that is difficult for humans to interpret and should not be analysed by tools, such as third-party executable code, where legal restrictions apply. The contract and the test charter are tempting because they are not technical artefacts, but being readable is what qualifies a work product for a review.

1. Ask whether people can read and understand each work product.
2. Ask whether a tool may legally and practically analyse it.
3. Notice that the executable is unreadable to people and off-limits to tools.
4. Choose the third-party executable.

Exam tip: If people can read it, it can be reviewed; third-party executables are the classic exception.

The syllabus classifies test techniques into three categories according to what the test cases are derived from.

Black-box techniques use the specified behavior, white-box techniques use the internal structure, and experience-based techniques use the testers' knowledge and experience. Collaboration-based work is covered separately as an approach; static/dynamic and reviews describe kinds of testing; and a list mixing an alias, a strategy and one individual technique is not the classification.

1. Recall what each technique category is derived from.
2. Separate technique categories from kinds of testing, strategies and individual techniques.
3. Note that collaboration-based items are called approaches, not techniques.
4. Choose black-box, white-box and experience-based.

Exam tip: Three technique categories: black-box, white-box, experience-based.

A test plan describes the objectives, resources and processes for a test project.

The test plan documents the means and schedule for achieving the test objectives, helps ensure the test activities meet the established criteria, and serves as a means of communication with the team and other stakeholders. Test cases and procedures hold execution detail, while progress and completion reports describe testing that has already happened.

1. Ask whether the document looks forward (planning) or backward (reporting).
2. Separate planning documents from test design and execution work products.
3. Pick the option about how and when the objectives will be achieved.

Exam tip: Test plan = how and when the test objectives will be met; reports describe what already happened.