ISTQB Software Testing Quiz 12

1. When conducting reviews, psychological sensitivity is required. Which mistake often occurs when conducting reviews and may lead to interpersonal problems within teams?

Testers and reviewers expect that defects in the software product are already found and fixed by the developers.

Due to time constraints, testers and reviewers do not believe they can afford enough time to find failures.

Testers and reviewers communicate defects as criticism against humans instead of against the software product.

Testers and reviewers are not sufficiently trained to accurately identify failures and faults in the item under review.

I think this one is fairly obvious. While there may be some truth in the others, the personal criticism that can happen in reviews (which is part of human nature) would be the biggest problem.

Explanation

I think this one is fairly obvious. While there may be some truth in the others, the personal criticism that can happen in reviews (which is part of human nature) would be the biggest problem.

2. Which of the following are test management tool capabilities?

i) The enforcement of coding standards.

ii) Support for requirements traceability activities.

iii) The generation of testing progress reports.

iv) Generation of test process improvement information.

Ii, iii & iv

I & ii

I, iii & iv

Iii & iv

Think about Quality Center (and, to a lesser extent, JIRA). It can do everything except enforce coding standards (in fact, we don't store the code inside the tool, so how could it possibly enforce coding standards).

Explanation

Think about Quality Center (and, to a lesser extent, JIRA). It can do everything except enforce coding standards (in fact, we don't store the code inside the tool, so how could it possibly enforce coding standards).

3. Which of the following might be a concern of a test group relying on a test design tool?

The tool may not generate sufficient tests for verifying all aspects of the test object.

The tool’s playback function may not work the same for all testers’ workstations.

The tool might take too much time to run, putting the schedule at jeopardy.

The tool’s test logs may require that the test group upgrade the server memory.

Please note that this question is talking about a test DESIGN tool, not a test automation tool. A test design tool generates test inputs automatically from requirements (stored electronically) or from code. Answers B, C & D are not a concern because these are infrastructure issues that can easily be resolved.

Explanation

Please note that this question is talking about a test DESIGN tool, not a test automation tool. A test design tool generates test inputs automatically from requirements (stored electronically) or from code. Answers B, C & D are not a concern because these are infrastructure issues that can easily be resolved.

4. Which of the following statements about the benefits of deriving test cases from use cases are true?

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

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

iii) Deriving test cases from use cases is helpful for unit testing.

iv) Deriving test cases from use cases is helpful for testing the interaction and interference between different components.

I

I & ii

Iii

I & iv

Use case testing is a black box test design technique in which test cases are designed to execute user scenarios. So in the context of this question we can eliminate iii, because developers doing unit testing will tend to use white box techniques. Statement ii is ridiculous, because it's too narrow. Statement i is clearly true. And for statement iv, use cases can help us understand how the whole thing hangs together, so this one is also true.

Explanation

Use case testing is a black box test design technique in which test cases are designed to execute user scenarios. So in the context of this question we can eliminate iii, because developers doing unit testing will tend to use white box techniques. Statement ii is ridiculous, because it's too narrow. Statement i is clearly true. And for statement iv, use cases can help us understand how the whole thing hangs together, so this one is also true.

5. For the following piece of code, how many test cases are needed to get 100% statement coverage:

Read (Colour) // Input colour from user
IF (Colour == “Red”) THEN
    Call Roses(Colour)
ELSEIF (Colour == “Blue”) THEN
    Call Violets(Colour)
ELSE
    PRINT “User is no Shakespeare”
SaveToDatabase(Colour)

5

3

1

2

The best way of doing these questions is to draw a flowchart. We have 4 statements we need to cover: Call Roses, Call Violets, PRINT and SaveToDatabase. In our first test case we can choose "Red" as the colour, and this will do Call Roses. In our next test we can choose "Blue" as the colour, and this will do Call Violets. In the last test we can choose any colour except Red or Blue, and this will do the PRINT. Note that every test will do SaveToDatabase (because it's unconditional), so we now have our 4 statements covered with 3 tests.

Explanation

The best way of doing these questions is to draw a flowchart. We have 4 statements we need to cover: Call Roses, Call Violets, PRINT and SaveToDatabase. In our first test case we can choose "Red" as the colour, and this will do Call Roses. In our next test we can choose "Blue" as the colour, and this will do Call Violets. In the last test we can choose any colour except Red or Blue, and this will do the PRINT. Note that every test will do SaveToDatabase (because it's unconditional), so we now have our 4 statements covered with 3 tests.

6. An estimate of resources should be made so that an organisation can create a schedule for testing. Which of the following approaches can be used for creating an estimate?

i) A skills-based approach, in which the estimate is based on all the testers’ skills.

ii) An expert-based approach, in which the owner or other expert creates the estimate.

iii) A metrics-based approach, in which the estimate is based on previous testing efforts.

iv) A bottom-up approach, in which each tester estimates their work and all estimates are integrated.

Ii, iii & iv

I, iii & iv

I & iv

Ii & iii

The problem with approaches i & iv is that they relate to the testers who are involved. Of course, this will definitely influence the schedule. However, according to the ISTQB Syllabus, expert-based and metrics-based are the only two. I think the idea here is that when we are doing a resource estimate (which is a fairly high-level thing) we don't take the specific skill sets of the people into account (which is a lower-level consideration). Also, at the planning stage, we may not even know which testers will be involved.

Explanation

The problem with approaches i & iv is that they relate to the testers who are involved. Of course, this will definitely influence the schedule. However, according to the ISTQB Syllabus, expert-based and metrics-based are the only two. I think the idea here is that when we are doing a resource estimate (which is a fairly high-level thing) we don't take the specific skill sets of the people into account (which is a lower-level consideration). Also, at the planning stage, we may not even know which testers will be involved.