SQTL : ISTQB Paper 4

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.

I, II and III are correct

I is correct

I, III and IV are correct

I, II and IV are correct

The test manager should do only automated regression testing.

The test manager is justified in her decision because no bug has been fixed in other modules

The test manager should only do confirmation testing. There is no need to do regression testing

Regression testing should be done on other modules as well because fixing one module may affect other modules

Static analysis tools are used only by developers

Compilers may offer some support for static analysis

Static analysis tools help find failures rather than defects

Static analysis tools require execution of the code to analyze the 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

Statement Coverage = 1, Branch Coverage = 2

Statement Coverage = 2, Branch Coverage = 2

Statement Coverage = 1, Branch Coverage = 3

Statement Coverage = 2, Branch Coverage = 4

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

Automation is likely to fail because of frequent changes and lack of experience

Automation is likely to fail because of GUI automation is not the right way to automate

Automation is likely to succeed because automation is very useful for frequent changes

Automation is likely to succeed because the team has been trained on tool.

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.

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.

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

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

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

Interoperability (compatibility) testing, reliability testing, performance testing

System testing, performance testing

Load testing, stress testing, component testing, portability testing

Testing various configurations, beta testing, load testing

Not enough qualified testers to complete the planned tests

Software delivery is behind schedule

Threat to a patient’s life

3rd party supplier does not supply as stipulated

Number of detected defects, testing cost;

Number of residual defects in the test object.

Percentage of completed tasks in the preparation of test environment; test cases prepared

Number of test cases run / not run; test cases passed / failed

Static analysis tools produce statistics during program execution

Configuration management systems allow us to provide accurate defect statistics of different configurations

Stress testing tools examine the behaviour of the test object at or beyond full load

Performance measurement tools can be used in all phases of software life-cycle

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

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

Visa, Master, Amex;

Visa, Master, Amex, Diners, Keycards, and other option

Visa, Master, Amex, any other card, no card

No card, other cards, any of Visa – Master – Amex

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

Logic-based testing

Use-case-based testing

State transition testing

Systematic testing according to the V-model

100% branch coverage

100% condition coverage and 100% statement coverage

Equivalence class and boundary value coverage

No other white box coverage criterion is guaranteed to be fulfilled 100%

2

Indefinite

1

4

Because configuration management assures that we know the exact version of the testware and the test object

Because test execution is not allowed to proceed without the consent of the change control board

Because changes in the test object are always subject to configuration management

Because configuration management assures the right configuration of the test tools

The test object, the test material and the test environment

The problem reports and the test material

Only the test object. The test cases need to be adapted during agile testing

The test object and the test material

Because the tools for automated testing require too much effort for learning

Because the maintenance of the test system is difficult

Because the test robot tools are restricted in their ability to recognize outputs

Because the test robot needs to be supported by a test management.

(I) and (II) are correct

(I) through (IV) are correct

(III) through (V) are correct

(I), (II) and (IV) are correct

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

Developers would typically use i and iv; test team ii and iii

Developers would typically use i and iii; test team ii and iv

Developers would typically use ii and iv; test team i and iii

Developers would typically use i, iii and iv; test team ii

Finding faults in the system

Ensuring that the system is acceptable to all users

Testing the system with other systems

Testing from a business perspective

Black box test design techniques all have an associated test measurement technique

White box test design techniques all have an associated test measurement technique

Cyclomatic complexity is not a test measurement technique

Black box test measurement techniques all have an associated test design technique

Inspection is the most formal review process

Inspections should be led by a trained leader

Managers can perform inspections on management documents

Inspection is appropriate even when there are no written documents

Calculating expected outputs

Comparison of expected outcomes with actual outcomes

Recording test inputs

Reading test values from a data file

Re-testing ensures the original fault has been removed; regression testing looks for unexpected side-effects

Re-testing looks for unexpected side-effects; regression testing ensures the original fault has been removed

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

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

Only important in system testing

Only used in component testing

Most useful when specified in advance

Derived from the code

Walkthrough

Inspection

Management review

Post project review

Component testing

Non-functional system testing

User acceptance testing

Maintenance testing

Setting up forms and databases

Analysing metrics and improving processes

Writing the documents to be inspected

Time spent on the document outside the meeting