ISTQB - ISEB | Certified Tester Foundation Level

A) Software testing may be required to meet legal or contractual requirements.

B) Software testing is mainly needed to improve the quality of the developer's work.

C) Rigorous testing and fixing of defects found can help reduce the risk of problems occurring in an operational environment.

D) Rigorous testing is sometimes used to prove that all failures have been found.

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.

The process of testing an integrated system to verify that it meets specified requirements.

The process of testing to determine the compliance of a system to coding standards.

Testing without reference to the internal structure of a system.

Testing system attributes, such as usability, reliability or maintainability.

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 organisation to fit the model and not vice versa.

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.

Correction of defects during the development phase?

Planned enhancements to an existing operational system.

Complaints about system quality during user acceptance testing.

Integrating functions during the development of a new system.

A) Regression testing and acceptance testing are the same.

B) Regression tests show if all defects have been resolved.

C) Regression tests are typically well-suited for test automation.

D) Regression tests are performed to find out if code changes have introduced or uncovered defects.

E) Regression tests should be performed in integration testing.

A) 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.

B) 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 spcifications, functional specifications or use cases.

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

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

A) Initiation, status, preparation, review meeting, rework, follow up.

B) Planning, preparation, review meeting, rework, closure, follow up.

C) Planning, kick off, individual preparation, review meeting, rework, follow up.

D) Preparation, review meeting, rework, closure, follow up, root cause analysis.

A) Informal Review.

B) Management Review.

C) Inspection.

D) Walkthrough.

E) Technical Review.

A) Static analysis can be used as a preventive measure with appropriate process in place.

B) Static analysis can find defects that are not easily found by dynamic testing.

C) Static analysis can result in cost savings by finding defects early.

D) Static analysis is a good way to force failures into the software.

A, B & D

A & C

A, B & C

A, C & D

A) Divides possible inputs into classes that have the same behaviour.

B) Uses both valid and invalid partitions.

C) Makes use only of valid partitions.

D) Must include at least two values from every equivalence partition.

E) Can be used only for testing equivalence partitions inputs from a Graphical User Interface.

a) Equivalence Partitioning, decision tables, state transition, and boundary
value.

b) Equivalence Partitioning, decision tables, use case.

c) Equivalence Partitioning, decision tables, checklist based, statement coverage, use case.

d) Equivalence Partitioning, cause-effect graph, checklist based, decision coverage, use case.

e) Equivalence Partitioning, cause-effect graph, checklist based, decision coverage and boundary value.

A) 3

B) 5

C) 2

D) 4

A. Deriving test cases from use cases is helpful for system and acceptance testing.

B. Deriving test cases from use cases is helpful only for automated testing.

C. Deriving test cases from use cases is helpful for component testing.

D. Deriving test cases from use cases is helpful for testing the interaction between different components of the system.

a) Experience, defect and failure data, knowledge about software failures.

b) Risk analysis performed at the beginning of the project.

c) Use Cases derived from the business flows by domain experts.

d) Expected results from comparison with an existing system.

Use Case Testing.

Condition Coverage.

Exploratory Testing.

Path Testing.

a) Decision testing.

b) Boundary value analysis.

c) Equivalence partitioning.

d) State transition testing.

a) The test manager plans testing activities and chooses the standards to be followed, while the tester chooses the tools and controls to be used.

b) The test manager plans, organizes and controls the testing activities, while the tester specifies, automates and executes tests.

c) The test manager plans, monitors and controls the testing activities, while the tester designs tests.

d) The test manager plans and organizes the testing and specifies the test cases, while the tester prioritizes and executes the tests.

a) Low quality of requirements, design, code and tests.

b) Political problems and delays in especially complex areas in the product.

c) Error-prone areas, potential harm to the user, poor product characteristics.

d) Problems in defining the right requirements, potential failure areas in the software or system.

a) Thoroughness measures, reliability measures, test cost, schedule, state of defect correction and residual risks.

b) Thoroughness measures, reliability measures, degree of tester independence and product completeness.

c) Thoroughness measures, reliability measures, test cost, time to market and product completeness, availability of testable code.

d) Time to market, residual defects, tester qualification, degree of tester independence, thoroughness measures and test cost.

a) R4 > R5 > R1 > R2 > R3 > R7 > R8 > R6 > R9.

b) R1 > R2 > R3 > R4 > R5 > R7 > R8 > R6 > R9.

c) R1 > R2 > R4 > R5 > R3 > R7 > R8 > R6 > R9.

d) R1 > R2 > R3 > R7 > R8 > R4 > R5 > R6 > R9.

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

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

c) Independent testers do not need extra education and training.

d) Independent testers reduce the bottleneck in the incident management process.

a) Skill and staff shortages.

b) Poor software characteristics.

c) Failure-prone software delivered.

d) Possible reliability defect (bug).

a) The number of test cases using Black Box techniques.

b) A summary of the major testing activities, events and its status in respect of meeting goals.

c) Overall evaluation of each development work item.

d) Training taken by members of the test team to support the test effort.

a) Impact, incident description, date and time, your name.

b) Unique id for the report, special requirements needed.

c) Transmitted items, your name and you’re feeling about the defect source.

d) Incident description, environment, expected results.

a) 1, 2, 3, 5.

b) 1, 4, 6, 7.

c) 2, 3, 4, 7.

d) 3, 4, 5, 6.

a) A table with test input data, action words, and expected results, controls execution of the system under test.

b) Actions of testers recorded in a script that is rerun several times.

c) Actions of testers recorded in a script that is run with several sets of test input data.

d) The ability to log test results and compare them against the expected results, stored in a text file.

a) To evaluate how the tool fits with existing processes and practices.

b) To determine use, management, storage, and maintenance of the tooland test assets.

c) To assess whether the benefits will be achieved at reasonable cost.

d) To reduce the defect rate in the Pilot Project.

a) To build traceability between requirements, tests, and bugs.

b) To optimize the ability of tests to identify failures.

c) To resolve defects faster.

d) To automate selection of test cases for execution.