ISTQB-2010-2011-7

When time for testing has run out.

When all planned tests have been run

When the test completion criteria have been met

When no faults have been found by the tests run

Because testing is good method to make there are not defects in the software

Because verification and validation are not enough to get to know the quality of the software

Because testing measures the quality of the software system and helps to increase the quality

Because testing finds more defects than reviews and inspections.

Code inspection

Coverage analysis

Usability assessment

Installation test

It is led by a trained leader, uses formal entry and exit criteria and checklists

It is led by the author of the document to be inspected

It can only be used for reviewing design and code

It is led by the author, uses checklists, and collects data for improvement

Both functional and non-functional requirements are to be tested

Only functional requirements are tested; non-functional requirements are validated in a review

Only non-functional requirements are tested; functional requirements are validated in a review

Only requirements which are listed in the specification document are to be tested

Testing is the same as quality assurance

Testing is a part of quality assurance

Testing is not a part of quality assurance

Testing is same as debugging

Because it is an industry standard

Because errors are frequently made during programming of the different cases near the ‘edges’ of the range of values

Because only equivalence classes that are equal from a functional point of view are considered in the test cases

Because the test object is tested under maximal load up to its performance limits

Should be able to understand a functional specification or requirements document

Should be able to understand the source code.

Is highly motivated to find faults

Is creative to find the system’s weaknesses

Needs configuration management just like requirements, design and code

Should be newly constructed for each new version of the software

Is needed only until the software is released into production or use

Does not need to be documented and commented, as it does not form part of the released software system

Statement testing

Equivalence partitioning

Error- guessing

Usability testing

As polite, constructive and helpful as possible

Firm about insisting that a bug is not a "feature" if it should be fixed

Diplomatic, sensitive to the way they may react to criticism

All of the above

9,10,11,22

9,10,21,22

10,11,21,22

10,11,20,21

Large

Small

Difficult to write

Difficult to test

State analysis

Coverage analysis

Dynamic analysis

Memory analysis

White box

Glass box

Structural

Functional

State transition testing, code testing, agile testing

Equivalence partitioning, state transition testing, decision table testing

System testing, acceptance testing, equivalence partitioning

System integration testing, system testing, decision table testing

I, II and III are correct

I is correct

I, III and IV are correct

I, II and IV are correct

Is nothing to do with testing

Is a partial measure of test thoroughness

Branch coverage should be mandatory for all software

Can only be applied at unit or module testing, not at system testing

10,11,21

3,20,21

3,10,22

10,21,22

Reducing test time

No change

Increasing test time

Can’t say

Performance testing can be done during unit testing as well as during the testing of whole system

The acceptance test does not necessarily include a regression test

Verification activities should not involve testers (reviews, inspections etc)

Test environments should be as similar to production environments as possible

Complete testing of software is attainable if you have enough resources and test tools

With automated testing you can make statements with more confidence about the quality of a product than with manual testing

For a software system, it is not possible, under normal conditions, to test all input and output combinations.

A goal of testing is to show that the software is defect free.

How well you know a particular technique

The objective of the test

How appropriate the technique is for testing the application

Whether there is a tool to support the technique

100% Equivalence class coverage

100% Condition coverage and 100% Statement coverage

100% Statement coverage

100% Multiple condition coverage

1, 2, capacity -1, capacity, capacity plus 1

0, 1, capacity, capacity plus 1

0, 1, 2, capacity plus 1, a very large number

0, 1, 10, 100, capacity, capacity plus one

For two components exchanging data, one component used metric units, the other one used British units

The system is difficult to use due to a too complicated terminal input structure

The messages for user input errors are misleading and not helpful for understanding the input error cause

Under high load, the system does not provide enough open ports to connect to

Less than 1, 1 through 15, more than 15

Negative numbers, 1 through 15, above 15

Less than 1, 1 through 14, more than 15

Less than 0, 1 through 14, 15 and more

To show that system will work after release

To decide when the software is of sufficient quality to release

To find as many bugs as possible before release

To give information for a risk based decision about release

Logic-based testing

Use-case-based testing

State transition testing

Systematic testing according to the V-model

2

Indefinite

1

4

Design based

Big-bang

Bottom-up

Top-down

Faults in program specifications are the most expensive to fix.

Faults in code are the most expensive to fix.

Faults in requirements are the most expensive to fix

Faults in designs are the most expensive to fix.

A goal is that no more failures will result from the remaining defects

A goal is to find as many failures as possible so that the cause of the failures can be identified and fixed

A goal is to eliminate as much as possible the causes of defects

A goal is to fulfil all requirements for testing that are defined in the project plan.

IEEE 829

IEEE 610

BS7925-1

BS7925-2

They help you find defects rather than failures

They are used by developers only

They require compilation of code

They are useful only for regulated industries

A walkthrough does not follow a defined process

For a walkthrough individual preparation by the reviewers is optional

A walkthrough requires meeting

A walkthrough finds the causes of failures, while formal review finds the failures