Customizing Fields in ReQtest – Part 4: Bug Reporting

This is the fourth article in our five-part series about customising fields in ReQtest. You can read the preceding part here or start at the beginning .

Common fields in bug reports

• Title
• Problem Description
• Owner (See more details below.)
• Subsystem

• Status
  • Indicates the currently status of the error. Common status examples include:
    • New
    • Under correction/investigation
    • Ready – For retesting
    • Ready – Won’t fix
    • OK
    • Not to be corrected in this version
    • Not able to reproduce
    • Incorrect test case
    • Re-opened

• Priority
  • Description of how soon the problem needs to be addressed, e.g.:
    • Urgent
    • Correct before the next release
    • Correct when time
    • Should not be corrected

• Frequency
  • Description of how often the error occurs. This is used to decide the order in which bugs should be corrected.

• Consequences
  • For example: loss of data, security, usability problems.

• Complexity
  • Describes how difficult it is to fix the problem, e.g. easy, medium, hard.

• Severity
  • Implications for either testing or for business (depending on the test level).
  • Example:
    • Critical error (causes crashes or lost data)
    • Requirement not met (e.g. errors in calculations or missing functionality which affect but does not prevent the use of one or more essential/necessary features.)
    • Minor problem (e.g. spelling errors, flaws and infrequent errors)

Options for the owner field in bug reports

There are several different options for how the recipient’s name is handled when you create a bug report:

• The list of names is displayed with or without a default recipient.

• The field is not displayed.

• The list can contain the names of external users or not.

When ReQtest is used by a client who in turns encourage their supplier use ReQtest, and the supplier’s users are are given the role of external users, you probably want the list to contain external users as well as all other users.

More settings for bug reporting

There are more settings for the bug report form than for the other forms. For example, it is possible to make the bug report form briefer for external users so that it becomes easier for inexperienced users to create bug reports easily.

You can also hide certain fields, either when the bug is created or when it is updated. The aim is to make the form easier to fill in and hide information that is not available or that is unnecessary when the bug is created.

You could, for example, have a field where the developer must assess how long it will take to fix the error. Since this information is not available when creating the bug report, you can make the field visible only when the bug is updated.

A useful approach to organise the fields on the bug report form is to think about whether some of the fields need to be hidden in certain states or to external users.

Create bug reports via email

If you want users to be able to create bug reports by e-mail, you have to create an email address for this. You can easily do this from the settings menu.

This concludes the fourth post of our five-article series about customising fields in ReQtest. Stay tuned for our next and final checklist , which will cover global fields on ReQtest.