JubulaWikiBugGuidelines

Writing bug reports for Jubula

If you find, or suspect you have found a bug, then follow these steps to enter your bug report:

1. 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.
2. 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

Component

• 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
  

Other details

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).

Severity

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
  
• Enhancement = this is a missing feature, or a feature request

Description

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.

Further information on a bug report

Just a few of the points that help to make a bug report good:

• Adding log files, error messages and Chronon recordings to a bug report makes it easier for the team to analyze the problem.
• Your architecture - system, environment, Java version, SWT version, Eclipse version (where applicable)

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. If you want your bug to be fixed regardless of its priority, you can either contribute a fix or sponsor the development team for the fix. Contact us on the  jubula-dev mailing list.

Resolution

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.

Fixed

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.