Test Management

INCIDENT MANAGEMENT

© 2005 Jalasoft Corp. All rights reserved.

Logistics

2 © 2005 Jalasoft Corp. All rights reserved.

Agenda

 Recognize the content of the [IEEE 829] incident

report.
 Best Practices for reporting and validating a PR.
 PR life cycle

3 © 2005 Jalasoft Corp. All rights reserved.

Terminology

 BUG
− A bug is another term for describing a defect in a software
program. If you start the product and it crashes, that’s a bug. If
you find a typo in the Help system, that’s considered a bug too.
To make long story short, a bug is an unexpected behavior from
the system under test.

4 © 2005 Jalasoft Corp. All rights reserved.

Terminology

 Incident Report
− A bug report is a document that contains all the necessary
information related to the bug. The form in which this report is
filled out depends on every company although changes are
minimum. A bug report has got several names given by the IT
industry along the years, some of the most common ones are:
− Incident Report
− PR > Problem Report
− Bug Report
− Defect Report.
− Etc..

5 © 2005 Jalasoft Corp. All rights reserved.

What to do after finding a Bug and before
writing a PR.

 So you think you found a bug..

6 © 2005 Jalasoft Corp. All rights reserved.

What to do after finding a Bug and before
writing a PR.

7 © 2005 Jalasoft Corp. All rights reserved.

What to do after finding a Bug and before
writing a PR.

8 © 2005 Jalasoft Corp. All rights reserved.

What to do after finding a Bug and before
writing a PR.

9 © 2005 Jalasoft Corp. All rights reserved.

What to do after finding a Bug and before
writing a PR.

10 © 2005 Jalasoft Corp. All rights reserved.

What to do after finding a Bug and before
writing a PR.

11 © 2005 Jalasoft Corp. All rights reserved.

What to do after finding a Bug and before
writing a PR.

12 © 2005 Jalasoft Corp. All rights reserved.

PR Components

 Issue Type:
− This field is used to classify PRs into Engineering and
Documentation. If the PR is a defect in the software, chose
Engineering. If this is an issue with documentation, either with
manuals or online help, chose Documentation.

13 © 2005 Jalasoft Corp. All rights reserved.

PR Components

 Title: Provide a concise one sentence summary of

the issue. Make it clear and understandable.
Remember that in reports this may be the only
information a manager knows about the issue.
− Tip for beginners: A very good title should explain where and
what the problem is. For this you should “imagine” that the bug
report has neither steps nor descriptions, only title. So you need
to explain everything just with the title, and it shouldn’t be too
long either. (Kind of hard but you will get used to it with
practice).

14 © 2005 Jalasoft Corp. All rights reserved.

PR Components

 Description: Elaborate more on the title. Say what

the observation was and how it differs from the
expected result.
− Tip for beginners: elaborate more about how you found it or
how it can be reproduced. If necessary try to explain how the
user will reproduce it doing common actions.

15 © 2005 Jalasoft Corp. All rights reserved.

PR Components

 Enhancement Request: This is a bug that is not an

unexpected behavior, but still you thing that by
doing some change in the system it will make it
better than it is right now, although it is working as
expected.
 Enhancement requests are usually found in the
User Interface, frequently when doing usability
testing

16 © 2005 Jalasoft Corp. All rights reserved.

PR Components
 Severity: The severity is a number that categorizes defects on how much
it affects the system under test. Severity ranges can change between
projects, you should ask you lead for information about your team’s
range and definition. Most of our clients use this range:
 1 – Catastrophic Product Failure - the defect results in the failure of the
complete software system, of a subsystem, or of a software unit
(program or module) within the system.
 2 - Prominent Functional Failure - the defect results in the failure of the
complete software system, of a subsystem, or of a software unit
(program or module) within the system. There is no way to make the
failed component(s) work; however, there are acceptable processing
alternatives, which will yield the desired result.
 3 – Average Functional Failure - the defect does not result in a failure,
but causes the system to produce incorrect, incomplete, or inconsistent
results, or the defect impairs the systems usability.
 4 – Minor - The defect does not cause a failure, does not impair usability,
and the desired processing results are easily obtained by working
around the defect. The defect is the result of non-conformance to a
standard, is related to the aesthetics of the system, or is a request for an
enhancement. Defects at this level may be deferred or even ignored.

17 © 2005 Jalasoft Corp. All rights reserved.

PR Components

 Found In Build: Enter the build number used for the

product version in which the issue was found.
 Target Release: This should default to a particular
version, typically the current version. Usually this is
determined by triage.
 Functional Area: Select the area of the product this
issue affects. This may be a component, a piece of
functionality in a GUI, etc.

18 © 2005 Jalasoft Corp. All rights reserved.

PR Components
 Reproduction Steps: Explain the complete steps taken
that manifested the issue.
− List any initial conditions.
− Provide any environment information, such as operating system,
etc.
− State which inputs into the system are generic and which ones
need to be a specific entry. For example, an issue may only arise
when entering a dash (-) in a field name.
− Mention if the issue occurs with other scenarios or environments.
− If it cannot be reproduced consistently, state the fact that it is
intermittent or was not very repeatable. You might also provide any
trends that usually cause it to occur.
− Be as clear and detailed as possible so that there is no ambiguity
on how to demonstrate. Be precise so it is not misinterpreted.
− Use good grammar and spelling. You don’t bad writing to distract
from communicating the issue.
− Put yourself in the developer’s position.
− Do not be judgmental or abusive in your language. Just the facts.

19 © 2005 Jalasoft Corp. All rights reserved.

PR Components

 Isolation: what you did to isolate the bug

 Workaround: Is there a workaround to get past the
issue and allow functionality to work? If so, provide
the steps here.
 Attachments: Put any files that will help in
debugging, such as log files, scripts, trace files, as
applicable. Provide screenshots of the observation.

20 © 2005 Jalasoft Corp. All rights reserved.

Practice:

 Practice: Write a Title for this bug:

− User approaches coffee machine and puts a cup in it. He
selects half the cup to be filled and press the start button. After
a few seconds the machine stops but he noticed that only a
quarter of the cup was filled.
− Assume that:
− The cup is the right size
− You fully understand how the machine works.
 User tries to start computer but the start button doesn’t start the
computer.
− While isolating you found that the power supply fusible is broken.

 We need: Title, Description, steps, actual results, expected results

and isolation.

21 © 2005 Jalasoft Corp. All rights reserved.

PR Validation

 PR validation is a very important phase of the bug

life cycle, in this phase you will either accept the
resolution or reject it.
 It is a big responsibility, if you validate PRs lightly
there is a change that you could accept a resolution
that was actually not fixing the problem, and the
bug will be released to customers.

22 © 2005 Jalasoft Corp. All rights reserved.

Example

 Those 'fine' deals could cost Dell.

 It's been rough times for Dell's Taiwan online branch, as
it was ordered by the Taiwan government to honor
orders for the
erroneously priced 19-inch LCD monitor for $15.
Unfortunately, Dell has committed several other pricing
errors that customers took advantage of.
 Dell racked in 26,000 customers purchasing nearly
140,000 displays, and based on those figures, that's
roughly over $18 million Dell could potentially lose.
 Imagine how the guy that validated that DOC PR is now
feeling!!

23 © 2005 Jalasoft Corp. All rights reserved.

PR Types

 PRs that were submitted by QE

− PRs submitted by yourself
− PRs submitted by another QE.
 PRs that were submitted by Development.
 PRs that were submitted by Customers. (tech
support)

24 © 2005 Jalasoft Corp. All rights reserved.

PRs that were submitted by QE

 PRs that were submitted by yourself

− If you remember it, just proceed with validation.
− If not, you need to reproduce following your steps
− Nice way to evaluate yourself!

25 © 2005 Jalasoft Corp. All rights reserved.

PRs that were submitted by QE

 PRs that were submitted by QE

− Reproduce PR and then validate it.
− If you were not able to reproduce, contact the QE teammate
that reported the bug.
− If the QE team mate is no longer available, contact the
developer that fixed the bug.

26 © 2005 Jalasoft Corp. All rights reserved.

Validating PRs that were submitted by
Development

 PRs submitted by development are usually very

light described; sometimes they don’t have
descriptions, steps, etc.
1. Just give it a try
2. If you didn’t have luck, contact the developer for
more information.
3. If you reproduced it. Update the PR!
4. Write a test case if there isn't one for this
scenario.

27 © 2005 Jalasoft Corp. All rights reserved.

Validating PRs that were submitted by
Customers (Tech Support)

 Reproduce (take a look at the environment).

 If you were not able to reproduce it, let your lead
know ASAP.

28 © 2005 Jalasoft Corp. All rights reserved.

Always add a note.

 If you either accept the resolution or rejected it you

need to ALWAYS add a proper note to the PR.
− Note example WRONG: (closing a PR)
− This PR is closed.
− Note example GOOD:
− This fix has been validated with build 630 and the
problem can no longer be reproduced. The coffee
machine is now filling half the cup when this
option is selected.

29 © 2005 Jalasoft Corp. All rights reserved.

Always add a note.

 Note example WRONG: (rejecting a PR)

− Rejecting resolution.
 Note example GOOD:
− This fix has been validated with build 630. Now the cup is not
filling a quarter less but it is filling a quarter more than the
specified. Therefore this PR is rejected.
− 1. Select half a cup to be filled.
− 2. press Start button
− 3. wait until the machine stops
− ACTUAL RESULTS: The cup is ¾ filled.
− EXPECTED RESULTS: The cup should be ½ filled.

30 © 2005 Jalasoft Corp. All rights reserved.

What to do when having several PRs to
validate in your queue

 When you have several PRs waiting to be validated

in your bug tracking tool’s queue, you need to start
with those with higher severity and priority. If you
have doubts contact your lead

31 © 2005 Jalasoft Corp. All rights reserved.

The PR life cycle.

 Depends on your workflow specified in the bug

tracking tool.
 The PR may get several different “States” along its
life cycle.
 Each “State” has an owner that needs to perform
an action to it.

32 © 2005 Jalasoft Corp. All rights reserved.

The PR life cycle.

33 © 2005 Jalasoft Corp. All rights reserved.

The PR life cycle.

34 © 2005 Jalasoft Corp. All rights reserved.

 Slide can be used to end your presentations—delete this text box

35 © 2005 Jalasoft Corp. All rights reserved.