Effective Bug Reporting

Often bug reports lack key pieces of information and Customer Support must send them back torequest more information. We don’t want to mistakenly resolve an issue incorrectly, so providing a complete bug report helps ensure the best results. We want to spend as much time as possible fixing bugs – to that end, high quality bug reports help us spend less time deciphering the issue and more time resolving it. Here are the guidelines on how to create a great bug report that will enable IT to take action on it quickly:

“Steps to Reproduce” – this should be the exact steps (all clicks, buttons selected, criteria entered) that you performed to get to the page where the error occurred. These should also be the exact steps you will take to confirm this is working correctly when we go to test. The steps should also include all specifics such as organization selected or student SSID entered, if applicable. If the error occurs with any of the choices on a given page or report, the simplest steps to generate the error may be reported.

Steps to reproduce the bug are the most import part of a bug. Investing a little extra time in this area helps developers immensely. When creating repro steps:

  • Always try to recreate the bug before writing the report
  • Walk through the steps of your bug and make sure you didn’t leave out a step.
  • Could someone reproduce the issue without familiarity with the application or features?
  • Start your reproduction steps from where you logged-in; don’t assume the person reading the bug knows how to navigate to the application.

“Expected Result” – what you expected to see/have happen when following all steps outlined above.

“Actual Result” – what you actually experienced/saw when following all steps outlined above.

Of course, screen shots are generally very helpful, but they don’t replace well written, “Steps to Reproduce.” The bug should still be captured in text, even if a screenshot is attached. If you see a SQL error with lots of text, a copy of just the text is helpful too.

Here’s a bug sent in an email by a userwho has not been given any guidelines:

There is a bug with the Race / Ethnicity reporting, at least in the Quick Views enrollment report. If you filter on some Race/Ethnicity categories – and then break out by Race/Ethnicity – it displays the wrong categories. For example, I chose only Asian, Native H/Pac Islander, and Two+ races … but then the table actually shows Blacks instead of Asian. Not sure if the numbers are right but the label wrong, or the other way around.

And I don’t know if the problem is spread through multiple reports or only in this one.

Now, here’s the Bug I created from that email (after much investigation on how to re-create the error!):

Steps to reproduce: Go to Quick Views, Select "Students," then Enrollment and choose the "Enrollment by Year" report. Leave default to October; Select "View Report Options," Select "View/Edit" in Break out by Category, select the '+' by the Break Out to display additional options: check the "Ethnicity/Race" box. Select, "View/Edit" in Filter Criteria; un-check boxes next to: All Grades and Gender. Select '+' next to Ethnicity/Race and un-check: American Indian/Alaskan, Black/African American, Hispanic/Latino of any race, Not Provided, and White. Then select, "RUN REPORT."

Expected result: Report displays statewide results for only the selected ethnicity/races: Asian, Native Hawaiian/Other Pacific Islander, Two or More Races

Actual result: Report displays statewide results for: Black/African American, Native Hawaiian/Other Pacific Islander, Two or More Races

*See file attachments for screen shot of report and original customer story reported

Without all of the text to support the “Steps to reproduce,” the IT Developer and Tester would not know how to ensure the issue had been corrected.