Writing Effective Defect Report
Writing Effective Defect Report
Course Prerequisite
N/A
Course Timetable
Agenda
Situations
Someone said that: “Defect writing is an effortless and
elementary job and one just needs to write whatever is
being observed and convey it in some form. Is is correct?”
The answer is NO. You will know the reason why after
going through out the course.
… Situations
Objectives
This course is designed for testers who will
fact to write defect report during their
executing tests.
After this course, You will know:
Characteristics of defect report
How to create an effective defect report
Precise
Isolate
Generalize
Recreate
Impact
Debug
Evidence
9 © 2008 IBM Corporation
GDC VN – WPLC Team
Condense
Condense - Example
I was setting up a test whose real intent was to detect memory errors. In the
process I noticed a new GUI field that I was not familiar with. I decided to exercise
the new field. I tried many boundary and error conditions that worked just fine.
Finally, I cleared the field of any data and attempted to advance to the next
screen, then the program halted. Several retries revealed that anytime there is not
any data for the "product description" field you cannot advance to the next screen
or even exit or cancel without halting.
Accurate
–Is it really a defect? Could it be user error, setup problem
etc.?
–Before writing up the problem consider
• Is there something in the setup that could have caused this?
• Could an incomplete cleanup, incomplete results, or manual
interventions from a previous test cause this?
• Could this be the result of a network or some other
environmental problem?
• Do you really understand how this is supposed to work?
Accurate - Example
Situation: There is a build and it was installed successful
–On side of test, the server is Windows NT server 4.0, the
program cannot work well – some functions like search, Add
new record, etc did not work correctly. (Wrong results after
searching, Lost data when saving …)
Neutralize
It is a well-known fact that software testers carry bad news about
the software and therefore they sometimes face unpleasant
reactions.
Don’t attacking developers, criticizing the underlying error,
attempting humor, or using sarcasm can create ill with
developers and divert attention from the bigger goal: increasing
the quality of the product.
The cautious tester confines defect reports to statements of fact.
Neutralize - Example
I logged to system as Administrator. I went to Manage User screen. Although
there is no User, but the “Delete”, “Details” buttons are still enabled. I have
never seen any screens like this. I don’t understand a reason why someone
can implement a screen like this and I hope I never see any funny defect like
this again!
I tried to click on them, nothing happen for “Details” button, but for “Delete”
button, I got run error message and the program was terminated. An expert
programmer can prevent any defect like this soon.
Precise
Precise - Example
Issuing a cancel print when job is in PRT state (job is already in the printer and
server is waiting to receive print complete from printer) causes the port to not
time out. The printer never returns to a READY state and indefinitely displays
"PRINTING IPDS FROM TRAY1" in the op-panel.
Isolate
After trying to reproduce the failure, the tester should then
proceed to isolate the defect. It will help developers a head
start on debugging.
Consider the following when isolating problems
–Try to find the shortest, simplest set of the steps required to reproduce the failure
–Ask yourself if anything external to the specific code being tested contributed to
the problem
–If your test has multiple input conditions, changing certain variables, such as
system configuration, boundary of values or something like that, that may alter
the symptom of the failure.
Isolate - Example
Using Windows NT, Launch the application, Open some screens such as Users,
Facilities, Event Rooms, … Then Close all of them. Click on “X” button at the top
right of screen to close the program. It seems the program was not really
terminated. I had to kill the program by opening Task Manager and select “End
Process” function.
In fact the issue only relates to Close function of the program. If user just launch
the program then Close it right away, the same error.
The issue is only occurred with Windows NT platform. The program was
terminated well with Windows XP, or Windows 2000 Pro, Windows 98.
Generalize
Generalize - Example
I went to User screen, View details of an user, make some changes. Then I
went to other screens. I got message with title “CnB”
At the User screen, I selected to delete a message, I got message with title
“C&B”
… I got message with title “Conference & Banqueting Module”
Please make sure that We just using one Title in this screen, That is
“Conference & Banqueting Module”
There are a lot of Title on common message like "CnB", or "C&B System", or
"C&B Module" or "Conference & Banqueting Module". Just use one and only
one public variant for this Title and everyone must follow, Please see
attachment to know more details.
Re-create
Testers should check reproducibility of a defect before writing a
defect report.
A good rule of thumb is three attempts to repeat the defect before
writing the report.
Consider:
–Should explain exactly what is required to do the re-create.
• List all the steps, include the exact syntax, file names, sequences, etc.
• Document the shortest, easiest means of re-creation.
• Gather all the relevant information that may provide useful information to the person who has to
try and fix the problem.
Re-create - Example
Trashed contents of new file that I created by formatting some text in Arial font.
Steps to reproduce:
1. Started SpeedyWriter editor, then created new file.
2. Typed four lines of text, repeating “The quick fox jumps over the lazy brown
dog” each time.
3. Highlighted all four lines of text, then pulled down the font menu and
selected Arial.
4. All text became corrupted into control characters, numbers, and random
binary data.
Impact
Impact - Example
I logged to system as Administrator. I went to Manage User screen. There are
some users, I selected one and tried to click on “Delete” button. I got run-time
error message and the program was terminated.
Log into system as Administrator. Go to Manage User screen. There are some
users, Select one and tried to click on “Delete” button. Got run-time error
message and the program was terminated.
This defect should be considered a Fatal defect and need to fix as soon as
possible before the program go to next phrase.
Debug
Debug - Example
Log into system as Administrator. Go to Manage User screen. There are some
users, Select one and tried to click on “Delete” button. Get run-time error
message and the program was terminated.
This defect should be considered a Major defect and need to fix as soon as
possible before the program go to next phrase.
Evidence
What will prove the existence of the error? Documentation or
images?
Consider
– Provided both the expected results and the actual results? Is there documentation that
supports that expected results?
– Don’t assume everyone sees things the same way you do.
– Don’t expect people to read between the lines and draw the same conclusions as you.
– Don’t assume that 3 weeks from now you will remember why you thought this was a bug.
– Think about what it is that convinced you that this is a bug and include that in the report.
Evidence - Example
I logged to system as Administrator. I created a reminder (Its status is now Not
Completed). When the time of reminder is reached, I got an alert message for
the reminder, Then I went to see the Status of the reminder, It is still “Not
Completed”. It should be changed to “Over due”
Log into system as Administrator. Create a reminder (Its status is now Not
Completed). When the time of reminder is reached, Get an alert message for
the reminder, Then go to see the Status of the reminder, It was still “Not
Completed”. It should be changed to “Over due” – Please refer to Configuration
Reminder Use Case version 1.2, at section 5.2
Defect report
Title
Steps to Reproduce
Are you really providing the exact information how to reproduce a defect?
Now, what is meant be ‘exact information’?
Most of the time a tester thinks that it will be easy for the developer to
understand whatever he assumes and with this assumption, many
important steps are sometimes skipped.
Correct terminologies and appropriate naming conventions should be
used while writing the steps. One should always keep it in mind about the
clarity in providing the information and systematically note down the
steps accordingly.
Ask yourself: can this defect be reproduced by anyone who reads your
defect report?
You need to state clearly about what is happening while performing the
steps mentioned in the defect report. This has to be extremely specific
and all the results how the software behaves should be mentioned
without missing anything.
Expected results
Additional Information
Comments/Discussion History
Attachments
Summary
Report the defect
–Getting the problem fixed with the least amount of effort
–The proper information is provided is more important
than superior writing skills