Writing bug reports for Jubula
If you find, or suspect you have found a bug, then follow these steps to enter your bug report:
- Check for duplicates in the Jubula bugzilla. If you find a bug that describes the same problem, then add your comment to it. If not, enter a new bug.
- When entering the bug, make sure you provide as much information as possible to help us understand the problem and reproduce it.
Information required for a bug report
- Use "Agent" to report problems with the AUT Agent
- Use "Core" to report problems when working with the ITE (Integrated Test Environment) - e.g. "unexpected error while editing Test Case"
- Use "RC" to report problems when working with the remote control components - e.g. "clicking button type x doesn't work on linux"
- Use "Tools" to report problems with the test executor, database tool and autrun command line clients
- Use "UA" to report problems with the user assistance - help, documentation, welcome pages or cheat sheets
- Use "UI" to report user interface problems
Enter the information required for the version you are using (if unspecified, then enter details in the bug report), the platform you are working on and the severity (next section).
The severity is how much the bug affects you as a user
- Blocker = complete feature loss, no workaround, perhaps data compromised
- Critical = feature loss, but with workaround
- Major = feature is difficult to use, leads user into errors, regardless of how feature is used
- Normal = feature is difficult to use when choosing one particular way of using feature
- Minor = actual feature is not affected, but odd behaviour
- Trivial = very unimportant, like typos
The description is the key to a good bug report. There are some excellent guides online:
- The Fine Art of Writing a Good Bug Report
- Asking smart questions,
- How to report bugs effectively
- Writing bugs from the Bugzilla team
Make sure you follow the principles outlined in these guides - it avoids ping-pong with bug reports where new details are requested at each step, and it reduces the time we need to identify, analyse and resolve bugs.
Triage and priority
The Jubula team has a weekly meeting to triage new bugs. During the triage meeting, the priority of the bug from the development perspective is set.
- P1 means that we will look at this immediately, and that it takes priority over all other current activities.
- P2 - P5 are the bugs that we plan as parts of our sprints. For the amount of time allocated to bug fixing in the sprint, we take as many bugs as will fit, starting at P2 and working down.
Escalation and de-escalation
If new information is added to a bug, then its priority may be escalated or de-escalated accordingly. Voting bugs up can also affect the priority.
Wontfix, invalid, worksforme
These resolutions will be justified in the comments. If you disagree, or have other / new information, then please feel free to reopen the bug with your comments.
Once a bug is planned for a sprint (for P2-P5 bugs) or has been assigned (P1 bugs) then the target milestone is set. The progress and the fix is documented on the bug.