Software Testing 1 CSE 3411 SWE 5411: Assignment #1 Replicate and Edit Bugs
Software Testing 1 CSE 3411 SWE 5411: Assignment #1 Replicate and Edit Bugs
Editing Bugs
The purpose of this assignment is to give you experience editing bugs written by other
people. This task will give you practice thinking about what a professional report should
be, before you start entering your own reports into this public system.
Work with the current version of Open Office Calc
Join the QA project, use your FIT email address.
Read the instructions at http://qa.openoffice.org/issue_handling/project_issues.html and
http://qa.openoffice.org/servlets/ProjectIssues . Read the bug entry guidelines at
http://qa.openoffice.org/issue_handling/bug_writing_guidelines.html.
Find 5 bug reports in Issue Tracker about problems with Open Office Calc that appear to
have not yet been independently verified. These are listed in the database as unconfirmed.
If you search by project, you may find relevant bugs in the sc project (spreadsheet),
documentation project, dba (database), api (application programming interface), and ui (user
interface).
For each report, review and replicate the bug, and add comments as appropriate in the
Additional Comments field to the report on issuezilla.
The assignment that you submit to me should list the bug numbers. I will read the comments
you filed (if any) on the bug report. In addition, for each bug, tell me what was done well,
what was done poorly and what was missing that should have been there in the bug report.
Editing Bugs
Assignment Procedure
For each bug:
Review the report for clarity and tone (see first impressions, next slide).
Include comments on clarity and tone on the memo you send me (but dont make these
comments on the bug report itself)
You may edit the bug report yourself, primarily in the following ways.
Add a comment indicating that you successfully replicated the bug on XXX configuration
in YYY build.
Add a comment describing a simpler set of replication steps (if you have a simpler set).
Make sure these are clear and accurate.
Add a comment describing why this bug would be important to customers (this is only
needed if the bug looks minor or like it wont be fixed. It is only useful if you know what
you are talking about).
Your comments should NEVER appear critical or disrespectful of the original report or of
the person who wrote it. You are adding information, not criticizing what was there.
If you edit the report in the database, never change what the reporter has actually written. You are
not changing his work, you are adding comments to it at the end of the report
Your comments should have your name and the comment date, usually at the start of the comment, for
example: (Cem Kaner, 12/14/01) Here is an alternative set of replication steps:)
Are there follow-up tests that you would run on this report if
you had the time?
In follow-up testing, we vary a test that yielded a less-thanspectacular failure. We vary the operation, data, or
environment, asking whether the underlying fault in the code
can yield a more serious failure or a failure under a broader
range of circumstances.
You will probably NOT have time to run many follow-up tests
yourself. For evaluation, my question is not what the results of
these tests were. Rather it is, what follow-up tests should have
been runand then, what tests were run?
What would you hope to learn from these tests?
How important would these tests be?