Skip to main content
Jump to: navigation, search

Difference between revisions of "JubulaWikiBugGuidelines"

(New page: = Writing bug reports for Jubula = If you find, or suspect you have found a bug, then follow these steps to enter your bug report: #[https://bugs.eclipse.org/bugs/buglist.cgi?query_for...)
 
Line 6: Line 6:
 
#When entering the bug, make sure you provide as much information as possible to help us understand the problem and reproduce it.<br>
 
#When entering the bug, make sure you provide as much information as possible to help us understand the problem and reproduce it.<br>
  
== Information required for a bug report<br> ==
+
== Information required for a bug report<br> ==
  
=== Component<br> ===
+
=== Component<br> ===
  
*Use "Agent" to report problems with the AUT Agent<br>
+
*Use "Agent" to report problems with the AUT Agent<br>  
*Use "Core" to report problems when working with the ITE (Integrated Test Environment) - e.g. "unexpected error while editing Test Case"<br>
+
*Use "Core" to report problems when working with the ITE (Integrated Test Environment) - e.g. "unexpected error while editing Test Case"<br>  
*Use "RC" to report problems when working with the remote control components - e.g. "clicking button type x doesn't work on linux" <br>
+
*Use "RC" to report problems when working with the remote control components - e.g. "clicking button type x doesn't work on linux" <br>  
*Use "Tools" to report problems with the test executor, database tool and autrun command line clients<br>
+
*Use "Tools" to report problems with the test executor, database tool and autrun command line clients<br>  
*Use "UA" to report problems with the user assistance - help, documentation, welcome pages or cheat sheets<br>
+
*Use "UA" to report problems with the user assistance - help, documentation, welcome pages or cheat sheets<br>  
 
*Use "UI" to report user interface problems<br>
 
*Use "UI" to report user interface problems<br>
  
=== Other details<br> ===
+
=== Other details<br> ===
  
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).<br>
+
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).<br>  
  
=== Severity<br> ===
+
=== Severity<br> ===
  
The severity is how much the bug affects you as a user<br>
+
The severity is how much the bug affects you as a user<br>  
  
*Blocker = complete feature loss, no workaround, perhaps data compromised<br>
+
*Blocker = complete feature loss, no workaround, perhaps data compromised<br>  
*Critical = feature loss, but with workaround<br>
+
*Critical = feature loss, but with workaround<br>  
*Major = feature is difficult to use, leads user into errors, regardless of how feature is used<br>
+
*Major = feature is difficult to use, leads user into errors, regardless of how feature is used<br>  
*Normal = feature is difficult to use when choosing one particular way of using feature
+
*Normal = feature is difficult to use when choosing one particular way of using feature  
*Minor = actual feature is not affected, but odd behaviour<br>
+
*Minor = actual feature is not affected, but odd behaviour<br>  
 
*Trivial = very unimportant, like typos<br>
 
*Trivial = very unimportant, like typos<br>
 +
 +
=== Description<br> ===
 +
 +
The description is the key to a good bug report. There are some excellent guides online:<br>
 +
 +
*[http://www.rbcs-us.com/images/documents/Fine-Art-of-Writing-a-Good-Bug-Report-%28Slides%29.pdf The Fine Art of Writing a Good Bug Report]<br>
 +
*[http://www.catb.org/~esr/faqs/smart-questions.html Asking smart questions], <br>
 +
*How to [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html report bugs effectively], [https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html ]<br>
 +
*[https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html Writing bugs ]from the Bugzilla team<br>
 +
 +
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. <br>
 +
 +
  
 
<br>
 
<br>

Revision as of 03:29, 26 June 2012

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

Description

The description is the key to a good bug report. There are some excellent guides online:

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.



Back to the top