For which of the following activities in the fundamental test process would an incident management tool be most useful?

a. Test planning and control

b. Test analysis and design

c. Test implementation and execution

d. Evaluating exit criteria and reporting

Which of the following principles should be followed when introducing a test tool into an organisation?

(i) Assessing organisational maturity to establish whether a tool will provide expected benefits.

(ii) Requiring a quick payback on the initial investment.

(iii) Including a requirement for the tool to be easy to use without having to train unskilled testers.

(iv) Identifying and agreeing requirements before evaluating test tools.

a. (i) and (ii)

b. (i) and (iv)

c. (ii) and (iii)

d. (iii) and (iv)

Which of the following defects is most likely to be found by a test harness?

a. Variance from programming standards.

b. A defect in middleware.

c. Memory leaks.

d. Regression defects.

How can test execution tools be of most benefit during exploratory testing?

a. They can record user actions so that defects are easier to recreate.

b. They can be used to perform the regression aspects of exploratory testing.

c. They can help to mitigate the risk of low test coverage.

d. They can use data-driven tests to increase the amount of exploratory testing performed.

Which of the following types of test tool are most likely to include traceability functions?

(i) Performance testing tool

(ii) Requirements management tool

(iii) Configuration management tool

(iv) Static analysis tool

a. (i) and (ii)

b. (i) and (iv)

c. (ii) and (iii)

d. (iii) and (iv)

A test management tool is most likely to integrate with which of the following tools?

a. Performance testing tool

b. Test data preparation tool

c. Static analysis tool

d. Requirements management tool

Incident management tools are most useful during test implementation and execution as this is the stage at which the tool is used to raise, manage, retest and close incidents.

The data collected during the defect life cycle can then be manipulated into information that is useful for other activities within the fundamental test process.

Information on numbers of defects outstanding may be useful for evaluating exit criteria (option (d)). This information could also be used for planning future testing and for taking control (option (a)).

Incident management tools can also assist in test analysis and design (option (b)) as information about defects found when testing the previous release of the system could be used when analysing the type of testing required for the next enhancement.

Assessing organisational maturity (i) is very important when deciding whether to introduce a test tool, as implementing a tool in an immature test organisation with poor processes is unlikely to produce any benefits.

A quick return on the initial investment (ii) in a test tool is rare. See the graph in Figure 6.1.

Having a requirement that a tool should be easy to use for untrained and unskilled testers (iii) is generally a false hope. This is comparable with expecting someone who has never driven a car to be able to drive safely and effectively.

Agreeing requirements before evaluating tools (iv) is essential. Not to do so would be comparable with building and testing a system without requirements.

In conclusion, (i) and (iv) are good principles to follow when introducing a tool and (ii) and (iii) are not.

Variance from programming standards defects (option (a)) are found during the review or static testing process. Therefore a test harness is unlikely to find a defect in programming standards.

Memory leak defects (option (c)) could potentially be found by a test harness designed to run many test cases.

Regression defects (option (d)) could be found using many types of test tool.

Defects in middleware (option (b)) are generally more likely to be found by a test harness or a dynamic analysis tool than by any other type of tool (see Figure 6.5).

Exploratory testing is used when it is unclear what the system is supposed to do. Therefore test execution tools are of little use because expected results cannot be predicted.

However, the record feature of a test execution tool can be used to log the actions performed so that defects can be recreated (option (a)) and rectified more easily.

Requirements management tools (ii) have traceability because they enable test conditions and subsequently test scripts and defects to be traced back to requirements. Configuration management tools (iii) also need to trace the appropriate version of a test script to the release or version of a system or module.

Performance monitoring tools (i) and static analysis tools (iv) are designed for specific objectives. Neither of these tools particularly need traceability functions.

Requirements management tools (option (d)) often have interfaces with test management tools. In some cases they will be sold as a package or in other cases a test management tool may have its own requirements module. The use of such interfaces or integrated packages aids traceability from requirements through to test scripts and defects.

Performance management tools (option (a)), test data preparation tools (option (b)) and static analysis tools (option (c)) are unlikely to have an interface or be integrated with a test management tool. They serve different purposes and therefore there is little need for such interfaces.