Here we test again!

Question#1:
You are an experienced test analyst who has been assigned to a new project that is very important to your company.
Management has decided that the development model to be used will be the V-model. You have been given the task of
participating in the review process for the project from beginning to end.

Which of the following statements describes how you prepare for each review in the project, and why it is important?
Choose TWO options.

Answer Set:
• A. Prior to the requirements review, you read the requirements document, checking that the requirements are unambiguous,
complete and testable. The more defects found and fixed at this stage, the less found later on.
• B. In preparation for the integration test plan review, you read the architecture specification in order to consider dependencies
between the components that are being integrated, so that the integration is performed efficiently.
• C. During a system test plan review, you review the defects found during component test, to determine which components
need more testing, and which test techniques would be most useful.
• D. For the system test plan review, you create user stories which will be used to see whether the system will be tested in the
same way it will be used.
• E. In preparation for component test design review, you read the design document and the code of the component being
developed and tested, in order to ensure that testing covers everything.
One more test
Easytravel is a card which is used for paying journeys on buses and undergrounds. User can
store credit to the card at Easytravel Loading Machines and the system automatically
deducts the fee of the journey while the user shows the card to the card reader at a bus or
at the underground station.
You are working on an Easytravel system maintenance team and the following use case has
been given to you for reviewing.
USE CASE: ADD TO EASYTRAVEL BALANCE FROM CREDIT CARD
Use case ID: UC-201201
Purpose: User is increasing the balance on their Easytravel card.
Actors: user
Pre-conditions: User has a valid Easytravel card and a credit card.
Main scenario & Exceptions (on the right):
End result: User’s Easytravel balance has been increased with the selected amount and the
equal amount has been charged to the credit card.

Consider the following criteria for a good use case:

Which of these are true regarding this use case? Pick TWO.

Answer Set:
• A. The main path in the use case is clearly defined.
• B. All alternative paths are clearly identified.
• C. User interface messages are defined.
• D. There is only one main path in the use case
• E. Each path (main and alternatives) is testable.
And the last one!
You are reviewing the following requirements specification document:
The following is the checklist you are using for this review:
1. Is each requirement testable?
2. Does each requirement have acceptance criteria listed?
3. Is a use case calling structure available (if applicable)?
4. Are the requirements uniquely identified?
5. Is the specification versioned?
6. Is there traceability visible from each requirement to the business/marketing
requirements?
7. Is there traceability between the requirements and the use cases?
You are reviewing the specification above with the provided checklist. Assume you have
access to the document that provides more information about the screen layout. Which
of the items on the checklist are NOT met by the specification?
Answer Set:
• A. 4, 6, 7
• B. 1, 2, 3
• C. 2, 4, 5
• D. 3, 5, 7
Test analyst
Module 6: Defect Management
Bases on the ISTQB Advanced level syllabus
Version 4.0
Language: English
Training program

1. Testing process
2. Test management: Responsibilities for the Test Analyst
3. Test Techniques
4. Testing Software Quality Characteristics
5. Reviews
6. Defect Management
7. Test Tools
Module contents

• Defect Management
• When Can a Defect be Detected?
• Defect Report Fields
• Defect Classification
• Root Cause Analysis
Terms

• Defect taxonomy
• Phase containment
• Root cause analysis
Terms

Defect
Defect is a flaw in component or system that can cause the component
or system to fail to perform it’s required function

Defect Taxonomy
A system of hierarchical categories designed to be a useful aid for
reproducibly classifying defects

Phase Containment
The percentage of defects that are removed in the same phase of the
software lifecycle in which they were introduced

Root Cause Analysis

A source of a defect such that if it is removed, the occurrence of the
defect type is decreased or removed
Expected -> Actual

Incident
(anomaly)

Expected Actual
result result (Test
(Test Design) Execution)

Defect
When Can a Defect be Detected?

The earlier a defect is

detected and

Static testing
corrected, the lower
the cost of quality Requirements Test execution
reviews
Code reviews

Dynamic testing
Design reviews
When Can a Defect be Detected?
Phase containment – if defect was introduced and found in the same phase
The Test Analyst should record the phase in the lifecycle in which the defect
was:
• Introduced
• Found

Defect was Defect “escape”

introduced and to a later phase
found in the
same phase
Test again

When a defect is found in the same phase in which ir was introduced, what
happens to the cost of the defect?

Answer Set:
• A. It is increased
• B. It is eliminated
• C. It is minimized
• D. No change
And this

What is the primary purpose of root cause analysis?

Answer Set:
• A. To reduce the costs of defects by finding them quickly
• B. To determine which developer has caused problem
• C. To improve the process by learning from common causes of issues
• D. To improve time to market by identifying areas that do not need testing
Module contents

• Defect Management
• When Can a Defect be Detected?
• Defect Report Fields
• Defect Classification
• Root Cause Analysis
Defect Report Fields
An actionable defect report is:
•Complete – all the necessary
information
•Concise – no extraneous Complete Concise
information
•Accurate – the information in
Accurate Objective
the report is correct and clearly
states the expected and actual
results as well as the proper
steps to reproduce
•Objective – professionally
written statement of fact
Defect reports should include
Functional and Non-functional Testing defect reports

• The information should be oriented toward clearly identified scenario

in which the problem was detected
• Steps and data required to reproduce that scenario
• Expected result
• Actual result

Non-functional defect reports require more details regarding

• Environment
• Performance parameters (e.g., size of the load)
Usability failure
Very important to state what the user expected the software to do.

If requirements/standards did not cover the usability aspects

use the "reasonable person"

"reasonable person" determines that the usability is unacceptable.

Testing time #6

A recently hired tester has been reporting a large number of defects in a part
of the code that has been traditionally stable. On further investigation, the
developers have determined that these reports are all false positives.
Which of the following would be the correct root cause for these defects?

• A. Tester error
• B. Logic error
• C. Documentation issue
• D. Configuration issue
One more #7

You are working on a product that is designed to be an application that will run in
a browser o a desktop or a mobile device. The software looks fine on the desktop,
but you are seeing issues with screen formatting when using mobile devices. It
was clearly started in the requirements that the application was to run on both
desktop and mobile devices, along with a list of the browsers to be supported.
Given this information, at what phase in the project was this defect likely
introduced?

• A. Requirements
• B. Design
• C. Testing
• D. Deployment
Module contents

• Defect Management
• When Can a Defect be Detected?
• Defect Report Fields
• Defect Classification
• Root Cause Analysis
Defect Classification 1/3

• Review
•
Project activity that Audit
• Inspection
resulted in the defect • Coding
being detected • Testing

Project phase in which • Requirements

the defect was • Design
introduced
Defect Classification 2/3

• Requirements
Project phase in •
•
Design
Code review
which the defect was • Integration test
detected •
•
System test
Acceptance test

• Requirements
•
Suspected cause of •
Design
Interface
defect •
•
Code
Data
Defect Classification 3/3

• Once
Repeatability • Intermittent
• Reproducible

• Crash
• Hang
• User interface error
Symptom • System error
• Performance
Defect Classification
Once the defect has been investigated, further classification may be possible:

Root cause - the mistake that was made that resulted in the defect, e.g., process, coding
error, user error, test error, configuration issue, data issue, third party software, external
software problem, documentation issue

Source – the work product in which the mistake made, e.g., requirements, design,
detailed design, architecture, database design, user documentation, test
documentation

Type – e.g., logic problem, computational problem, timing issue, data handling,
enhancement
Defect Classification
When the defect is fixed (or has been deferred or has failed confirmation),
even more classification information may be available, such as:

Resolution Corrective action

• Code change • Requirements review
• Documentation change • Code review
• Deferred • Unit test
• Not a problem • Configuration documentation
• Duplicate • Data preparation
• No change made
 Defect Classification
Based on severity and priority
• Mission safety impact
• Project schedule impact
• Project costs impact
• Project risk impact
• Project quality impact

Based on resolution
• Fixed or verified
• Closed or not a problem
• Deferred
• Open or unresolved

However:
•Too many classification fields will make opening a defect somewhat time consuming
•It is important to weigh the value of the data being gathered against the incremental cost for every
defect processed
Tests

Which TWO of the following may more You have been testing an application that tracks
frequently need to be explained in greater real estate transactions. There have been repeated
detail for nonfunctional defect reports than issues with “corner cases” in production. You have
determined that these problems are due to issues
for a functional defect report? with a particular set of addresses – those having a
space in the name of the city.
Answer set: Which of the following would be a valid root cause
classification for these defects?
A. Screenshots confirming the actual result
B. Steps to reproduce the defect Answer set:
C. Environment A. Missing requirements
D. Level of load on the system at the time B. Incorrect design implementation
of failure C. Data handling
E. Actual results D. Calculation error
Module contents

• Defect Management
• When Can a Defect be Detected?
• Defect Report Fields
• Defect Classification
• Root Cause Analysis
Root Cause Analysis
Main purpose of root cause analysis
• Support process changes that will remove root causes that are responsible for a significant portion of
the defects
Root cause analysis is usually conducted by the person who investigates and either fixes the problem or
determines the problem should not or cannot be fixed.
This is usually the developer.
Typical root causes include:
Incorrect
Unclear Missing Wrong Incorrect design
interface
requirement requirement requirement implementation
implementation

Calculation
Code logic error Hardware error Interface error Invalid data
error
Literature

ISTQB Documents
• [ISTQB_AL_OVIEW] ISTQB Advanced Level Overview, Version 1.0
• [ISTQB_ALTM_SYL] ISTQB Advanced Level Test Manager Syllabus, Version 1.0
• [ISTQB_ALTTA_SYL] ISTQB Advanced Level Technical Test Analyst Syllabus, Version 1.0
• [ISTQB_FL_SYL] ISTQB Foundation Level Syllabus, Version 2011
• [ISTQB_GLOSSARY] Standard glossary of terms used in Software Testing, Version 2.2, 2012

Books
• Graham Bath, Judy McKay, “The Software Test Engineer’s Handbook”, Rocky Nook, 2008, ISBN 978-1-933952-24-6
• Boris Beizer, “Black-box Testing”, John Wiley & Sons, 1995, ISBN 0-471-12094-4
• Rex Black, “Managing the Testing Process (2nd edition)”, John Wiley & Sons: New York, 2002, ISBN 0-471-22398-0
• Rex Black, “Pragmatic Software Testing”, John Wiley and Sons, 2007, ISBN 978-0-470-12790-2
• Hans Buwalda, “Integrated Test Design and Automation”, Addison-Wesley Longman, 2001, ISBN 0-201-73725-6
• Mike Cohn, “User Stories Applied: For Agile Software Development”, Addison-Wesley Professional, 2004, ISBN 0-321-20568-
5
• Erik van Veenendaal, “Practical risk-based testing – The PRISMA approach”, UTN Publishers, The Netherlands, ISBN
9789490986070
• Glenford J. Myers, “The Art of Software Testing”, John Wiley & Sons, 1979, ISBN 0-471-46912-2