:

Writing Good Bugs

Most of the instructions for Writing Good Issues still apply.

• Meaningful title
  • Indicate what is wrong
  • Example: "BOP Application" as a title is too wide open to interpretation. One tip is to think of being in your user's/client's shoes and reading the title as part of the Release Notes. Ask yourself, "would the title make any sense in such a stand-alone fashion?"
    Contrast the two:
    "Bug Fixed: BOP Application"
    "Bug Fixed: BOP Application Form missing fax number"
• Clear description
  • What is wrong
  • Add expected or desired behavior
• Choose the component, if known. Otherwise, development will categorize it
• Record as much context as possible
  • Where you were testing (if multiple environments)
  • What you were doing that led to the bug
  • What steps are required to reproduce the bug
  • Any specific identifier for the data (e.g., an ID, a title)
• Add any helpful screenshots
• Indicate the severity of the bug (see below)

Severity

When we receive a PRODUCTION bug, we have to immediately determine the nature of the bug. Basically, we need to know if we should fix it ASAP because it is causing major problems for our customers, or if it can wait.
To evaluate a bug so that we can determine the severity, we need to have enough additional information in the following fashion (for example):

Severity	Impact to the user getting their job done
SEV 1	Cannot perform their job. Loss of data, time, and/or money. No workaround exists.
SEV 2	Can perform their job, but it takes much longer than it should. Workaround exists.
SEV 3	Bug is annoying, workaround exists.
Importance	Indicate the likelihood of this occurring, or the importance of getting it fixed

The SAMPLE table below outlines the response times based on the level of severity of the bug.
* Issues of Critical or High severity levels must be reported via telephone to receive these response times.

Contents

bugs should have all that is necessary for the developer to:

1. know the problem via a test/demonstration (i.e., it needs to be repeatable),
2. troubleshoot, and
3. verify the problem is gone via the same (and possibly other) tests/demonstrations.

Be thorough

Reading:	MG-1243@JIRA Underwriter questions - yes/no choices When switching a yes/no choice from yes to no, the NO field does not value on the first selection. See screen printing. No to Yes is working but Yes to NO required two clicks. Happening in both "Appliances - Household" and "Apartment/Condo." I didn't check the other classes of business yet.
Leaves me wondering:	Is it the UI? Can you see this behavior in Diner? In other parts of the Qstnr 3? Is it the data? Does this happen on every UW question? ...on every question with a Yes/No? ...on only some questions? ...on only questions that have rules? ...on only questions that are made visible by rules? ...on only choices that participate in rules?