ISTQB 1 - 3

Availability of tools to support the proposed techniques.

The budget allowed for training in proposed techniques.

Available skills and experience in the proposed techniques.

The willingness of the test team to learn new techniques.

It does not require familiarity with the code.

It is cheaper than using developers to test their own code.

It avoids author bias in defining effective tests.

Testers are better at finding defects than developers.

We can never be certain that the program is bug free.

We have no definite stopping point for testing, which makes it easier for some managers to argue for very little testing.

We have no easy answer for what testing tasks should always be required, because every task takes time that could be spent on other high importance tasks.

All of the above

Finding defects

Gaining confidence about the level of quality and providing information

Preventing defects.

Debugging defects

Define when to stop testing

End of test level

When a set of tests has achieved a specific pre condition

All of the above

Planning and control

Test closure activities

Analysis and design

None

I, ii, iii is true and iv is false

Ii,iii,iv is true and i is false

I is true and ii,iii,iv are false

Iii and iv is correct and i and ii are incorrect

Test Analysis and Design

Test Implementation and execution

Test Closure Activities

Evaluating exit criteria and reporting

Checking test logs against the exit criteria specified in test planning.

Logging the outcome of test execution.

Assessing if more tests are needed.

Writing a test summary report for stakeholders.

Creating test suites from the test cases

Executing test cases either manually or by using test execution tools

Comparing actual results

Designing the Tests

Test Implementation and execution

Test Analysis and Design

Evaluating the Exit Criteria and reporting

Test Closure Activities

Test Analysis and Design

Test Implementation and execution

Test Closure Activities

Evaluating exit criteria and reporting

Requirements

Documentation

Test cases

Improvements suggested by users

I,ii,iii are true and iv is false

I,,iv are true and ii is false

I,ii are true and iii,iv are false

Ii,iii,iv are true and i is false

Is impractical but possible

Is practically possible

Is impractical and impossible

Is always possible

Test Analysis and Design

Test Planning and control

Test Closure Activities

Evaluating exit criteria and reporting

Regression testing

Maintenance testing

Confirmation testing

None of the above

Prove that the remaining defects will not cause any additional failures.

Run all of the tests that are defined for the test object as quickly as possible.

Prove that all faults have been identified through thorough testing.

Cause as many failures as possible so that faults can be identified and corrected

Automated tests allow better statements of confidence about the quality of software products.

For a software system, it is normally impossible to test all the input and output combinations.

Exhaustive software testing is, with enough effort and tool support, feasible for all software.

The purpose of software testing is demonstrating the absence of defects in software products.

Developer and independent testing will overlap and waste resources.

Communication is limited between independent testers and developers.

Independent testers are too slow and delay the project schedule.

Developers can lose a sense of responsibility for quality.

Determine the productivity of programmers

Eliminate the need for future program maintenance

Eliminate every error prior to release

Uncover software errors

Incorrect program behavior due to a fault in the program

Bug found before product Release

Bug found after product Release

Bug found during Design phase

When the code is complete.

When the design is complete.

When the software requirements have been approved.

When the first code module is ready for unit testing

Lack of technical documentation

Lack of test tools on the market for developers

Lack of training

Lack of Objectivity

Quality is job one

Zero defects

Conformance to requirements

Work as designed

2 is a valid reason; 1,3,4 & 5 are not

1,2,3,4 are valid reasons; 5 is not

1,2,3 are valid reasons; 4 & 5 are not

All of them are valid reasons for failure

You shorten the time required for testing

You do the best testing in the time available

You do more effective testing

You find more faults

Execution

Design

Planning

Check Exit criteria completion

To freeze requirements

To understand user needs

To define the scope of testing

All of the above

Re-testing is running a test again; regression testing looks for unexpected side effects

Re-testing looks for unexpected side effects; regression testing is repeating those tests

Re-testing is done after faults are fixed; regression testing is done earlier

Re-testing uses different environments, regression testing uses the same environment

Re-testing is done by developers, regression testing is done by independent testers

All the planned tests have been run

Time has run out

All faults have been fixed correctly

Both A. and C.

It depends on the risks for the system being tested

Is not important

Increases as we move the product towards live use

Decreases as we move the product towards live use

Is more expensive if found in requirements than functional design

Can never be determined

To know when a specific test has finished its execution

To ensure that the test case specification is complete

To set the criteria used in generating test inputs

To know when test planning is complete

To plan when to stop testing

I, iii & iv are true. ii & v are false

Iii is true, i, ii, iv & v are false

Iii & iv are true. i, ii & v are false

I, iii, iv & v are true, ii us false

I & iii are true, ii, iv & v are false

Develop and prioritizing test cases, creating test data, writing test procedures and optionally, preparing test harness and writing automated test scripts.

Logging the outcome of test execution and recording the identities and versions of the software under test, test tools and testware.

Checking test logs against the exit criteria specified in test planning.

Verifying that the test environment has been set up correctly.

To know when a specific test has finished its execution

To ensure that the test case specification is complete

To set the criteria used in generating test inputs

To determine when to stop testing

An error

A fault

A failure

A defect

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.

More work gets done because testers do not disturb the developers all the time.

Independent testers tend to be unbiased and find different defects than the developers

Independent testers do not need extra education and training.

Independent testers reduce the bottleneck in the incident management process.

A, C and D and E are true; B is false.

A, C and E are true; B and D are false.

C and D are true; A, B and E are false.

B and E are true; A, C and D are false.

Testing pinpoints (identifies the source of) the defects. Debugging analyzes the faults and proposes prevention activities.

Dynamic testing shows failures caused by defects. Debugging finds, analyzes, and removes the causes of failures in the software.

Testing removes faults. Debugging identifies the causes of failures.

Dynamic testing prevents causes of failures. Debugging removes the failures.

Testing to see where the system does not function properly

Testing quality attributes of the system including performance and usability

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

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

Testing for functions that should not exist

Top down

Big-bang

Bottom up

Functional incrementation.

To ensure that all of the small components are tested

To ensure that the system interfaces to other systems and networks

To ensure that the integration testing can be performed by a small team

To specify how the software should be divided into components

To specify which components to combine when, and how many at once

Updating tests when the software has changed

Testing a released system that has been changed

Testing by users to ensure that the system meets a business need

Testing to maintain business advantage

Component testing verifies the functioning of software modules, program objects, and classes that are separately testable, whereas system testing verifies interfaces between components and interactions with different parts of the system.

Test cases for component testing are usually derived from component specifications, design specifications, or data models, whereas test cases for system testing are usually derived from requirement specifications, functional specifications or use cases.

Component testing focuses on functional characteristics, whereas system testing focuses on functional and non-functional characteristics.

Component testing is the responsibility of the technical testers, whereas system testing typically is the responsibility of the users of the system.

Acceptance testing is always the final test level to be applied.

All test levels are planned and completed for each developed feature.

Testers are involved as soon as the first piece of code can be executed.

For every development activity there is a corresponding testing activity.

To adapt the models to the context of project and product characteristics.

To choose the waterfall model because it is the first and best proven model.

To start with the V-model and then move to either iterative or incremental models.

To only change the organization to fit the model and not vice versa.