Control of the test project

The test object

A single test item

A potential negative outcome

They can find defects missed by specificationbased and structure-based techniques

They don't require any training to be as effective as formal techniques

They can be used most effectively when there are good specifications

They will ensure that all of the code or system is tested

Evaluation

Summary of activities

Variances

Incident description

Static analysis tools and test execution tools

Review process support tools, static analysis tools and coverage measurement tools

Dynamic analysis tools and modeling tools

Review process support tools, static analysis tools and modeling tools

With static analysis, defects can be found that are difficult to find with dynamic testing

Compiling is not a form of static analysis

When properly performed, static analysis makes functional testing redundant

Static analysis finds all faults

Decide which tool to acquire

Decide on the main objectives and requirements for this type of tool

Evaluate the tool vendor including training, support and commercial aspects

Decide on standard ways of using, managing, storing and maintaining the tool and the test assets

P, Q and R

Q, S and T

P, Q and S

R, S and T

A test manager manages a collection of test leaders

A test manager is the leader of a test team or teams

A test manager gets paid more than a test leader

A test manager reports to a test leader

Software code

Requirements specification

Test designs

All of the above

Inspections are led by a trained moderator, whereas technical reviews are not necessarily

Technical reviews are led by a trained leader, inspections are not

In a walkthrough, the author does not attend

Participants for a walkthrough always need to be thoroughly trained

Incident

Defect

Mistake

Error

s = 4, t = 3, u = 2 and 5, v = 1

s = 4 and 5, t = 3, u = 2, v = 1

s = 1 and 5, t = 3, u = 2, v = 4

s = 5, t = 4, u = 3, v = 1 and 2

They depend on the tester's understanding of the way the system is structured rather than on a documented record of what the system should do

They depend on having older testers rather than younger testers

They depend on a documented record of what the system should do rather than on an individual's personal view

They depend on an individual's personal view rather than on a documented record of what the system should do

Feasibility

Usability

Maintenance

Regression

Unreachable code

Undeclared variables

Faults in the requirements

Too few comments

Early test analysis and design

Different test levels are defined with specific objectives

Testers will start to get involved as soon as coding is done

A and B above

Independent testing is usually cheaper than testing your own work

Independent testing is more effective at finding defects

Independent testers should determine the processes and methodologies used

Independent testers are dispassionate about whether the project succeeds or fails

Test plan

Test design specification

Test case specification

Test procedure specification

A group of test activities that are organized together

One or more test design specification documents

A test type

An ISTQB certification

2, 3 and 4

2 and 4

3 and 4

1, 2 and 3

Assess organizational maturity, strengths and weaknesses

Roll out the tool to as many users as possible within the organization

Evaluate the tool features against clear requirements and objective criteria

Identify internal requirements for coaching and mentoring in the use of the tool

Percentage of test cases written

Number of test environments remaining to be configured

Number of defects found and fixed

Percentage of requirements for which a test has been written

Unrealistic expectations, expecting the tool to do too much

Insufficient reliance on the tool, i.e. still doing manual testing when a test execution tool has been purchased

The tool may find defects that aren't there

The tool will repeat exactly the same thing it did the previous time

To identify new risks to system quality

To locate defect clusters in product subsystems

To check risk coverage by tests

To measure exploratory testing

Determine the extent of testing required for the product risks and the mitigation and contingency actions required for the project risks

Obtain the resources needed to completely cover each product risk with tests and transfer responsibility for the project risks to the project manager

Execute sufficient tests for the product risks, based on the likelihood and impact of each product risk and execute mitigation actions for all project risks

No further risk management action is required at the test planning stage

The test plan describes one or more levels of testing, the test design specification identifies the associated high-level test cases and a test procedure specification describes the actions for executing a test

The test plan is for managers, the test design specification is for programmers and the test procedure specification is for testers who are automating tests

The test plan is the least thorough, the test procedure specification is the most thorough and the test design specification is midway between the two

The test plan is finished in the first third of the project, the test design specification is finished in the middle third of the project and the test procedure specification is finished in the last third of the project

Negative feedback to the tester

Negative consequences that will occur

Negative consequences that could occur

Negative consequences for the test object

Test management and control

Test specification and design

Test execution and logging

Performance and monitoring

Understanding what managers value about testing

Explaining test results in a neutral fashion

Identifying potential customer work-arounds for bugs

Promoting better quality software whenever possible

Geographical separation of tester and programmers

The departure of the test manager during the project

The quality of the information used to develop the tests

Unexpected long-term illness by a member of the project team

V,W,YorZ

W,XorY

V,XorZ

W, X, Y or Z

Preventing defects in the system

Finding defects through dynamic testing

Gaining confidence in the system

Finishing the project on time

Data-driven and keyword-driven

Data-driven and capture-driven

Capture-driven and keyhole-driven

Playback-driven and keyword-driven

To verify the success of corrective actions

To prevent a task from being incorrectly considered completed

To ensure that defects have not been introduced by a modification

To motivate better unit testing by the programmers

To build confidence in the application.

To detect bugs in the application.

To gather evidence for a lawsuit.

To train the users.

Difficulty of fixing related problems in code

The harm that might result to the user

The price for which the software is sold

The technical staff in the meeting

A table containing rules for combinations of inputs to two fields on a screen

A table containing rules for interfaces between components

A table containing rules for mortgage applications

A table containing rules for chess

There is no time to test the change before it goes live, so only the best developers should do this work and should not involve testers as they slow down the process

Just run the retest of the defect actually fixed

Always run a full regression test of the whole system in case other parts of the system have been adversely affected

Retest the changed area and then use risk assessment to decide on a reasonable subset of the whole regression test to run in case other parts of the system have been adversely affected

5,4, 2,1, 3, 7, 6

4,2,5,1,6,7,3

5,4,2,1,7,3,6

5,1, 2, 3,4, 7, 6

Walkthrough

Inspection

Informal review

Management approval

Unexpected illness of a key team member

Excessively slow transaction-processing time

Data corruption under network congestion

Failure to handle a key use case

Gives quality information about the code without executing it

Checks expected results against actual results

Can detect memory leaks

Gives information about what code has and has not been exercised

8,42,82,102

4,15, 65, 92,159

10,50,75,100

5, 20, 40, 60, 80

Measuring response time on an on-line booking system

Checking the effect of high volumes of traffic in a call-center system

Checking the on-line bookings screen information and the database contents against the information on the letter to the customers

Checking how easy the system is to use

All statements belong in an acceptance test plan

Only statement I belongs in an acceptance test plan

Only statements I, II, and V belong in an acceptance test plan

Only statements I, IV, and V belong in an acceptance test plan

They are mainly used to assess the structure of a specification

They are used both to measure coverage and to design tests to increase coverage

They are based on the skills and experience of the tester

They use a formal or informal model of the software or component

A high-level outline of the test conditions and general steps to take

Every step in the test spelled out in detail

A high-level outline of the test conditions with the steps to take discussed in detail with another experienced tester

Detailed documentation of all test cases and careful records of each step taken in the testing

100% decision coverage is achieved if statement coverage is greater than 90%

100% statement coverage is achieved if decision coverage is greater than 90%

100% decision coverage always means 100% statement coverage

100% statement coverage always means 100% decision coverage

Test principles only affect the preparation for testing

Test principles only affect test execution activities

Test principles affect the early test activities such as review

Test principles affect activities throughout the test life cycle

Greater quality of code, reduction in the number of testers needed, better objectives for testing

Greater repeatability of tests, reduction in repetitive work, objective assessment

Greater responsiveness of users, reduction of tests run, objectives not necessary

Greater quality of code, reduction in paperwork, fewer objections to the tests

Develop system requirements, design specifications and usage models

Handle all test automation duties

Keep tests and test coverage hidden from programmers

Gather and report test progress metrics

V,W,YandZ

U, V, W and Y

U,XandY

V,W and Y

Component testing

Functional testing

System testing

Acceptance testing

The remaining 15 defects should be confirmation tested prior to release

The remaining 10% of test cases should be run prior to release

The system is now ready for release with no further testing or development effort

The programmers should focus their attention on fixing the remaining known defects prior to release

Traceability

Confirmation testing

Configuration control

Test documentation management

X,YandZ

V, X, Y and Z

W,XandY

V, X and Z

A bug report

A defect report

An incident report

A test summary report

Objectives should be generic for any test level

Objectives are the same for each test level

The objectives of a test level don't need to be defined in advance

Each level has objectives specific to that level

They find different types of defect

Using more techniques is always better

Both find the same types of defect

Because specifications tend to be unstructured

1 and 3 are true. 2 and 4 are false

2 is true. 1, 3 and 4 are false

2 and 3 are true. 1 and 4 are false

2, 3 and 4 are true. 1 is false

An inspection is led by the authors, whilst a walk through is led by a trained moderator

An inspection has a trained leader, whilst a walk through has no leader

Authors are not present during inspections, whilst they are during walkthroughs

A walkthrough is led by the author, whilst an inspection is led by a trained moderator

Is only run once

Will always be automated

Will check unchanged areas of the software to see if they have been affected

Will check changed areas of the software to see if they have been affected

Exhaustive testing is impossible

Defect clustering

Pesticide paradox

Absence-of-errors fallacy

Testing to see where the system does not function correctly

Testing the quality attributes of the system including reliability and usability

Gaining user approval for the system

Testing a system feature using only the software required for that function

Test tasks

Environmental needs

Exit criteria

Test team training

Summary

Impact

Item pass/fail criteria

Incident description

Performed by customers at their own site

Performed by customers at the software developer's site

Performed by an independent test team

Useful to test software developed for a specific customer or user

The arrival of a more-reliable competing product on the market

Delivery of an incomplete test release to the first cycle of system test

An excessively high number of defect fixes fail during re-testing

Failure to accept allowed credit cards