Annotating testing notes

I’m lucky in my current role to the independence to test how I see fit. I don’t have somebody forcing me to use a tool that doesn’t work for me. After weeks of plaguing my boss to pay for a JIRA Capture licence, I eventually got my way!! I have used JIRA Capture Test Sessions briefly at a previous company and found it to be a simple but very effective tool for capturing testing notes.

A JIRA Capture Test Session is essentially a note attached to your JIRA ticket which allows test session findings to be annotated. You can

Screen Shot 2016-02-02 at 4.32.31 pm

Example of an annotated test session

Test Session notes broken down

Test Session notes are split into 3 distinct sections (the above example shows only the Background and Checks sections).

  • Background
    • Lists which browsers, devices, environments, branches, operating systems, etc. that underpin your tests
    • You can include additional notes and assumptions, including areas you consider to be outside of the scope of your testing. At least, this way you are making it explicit to the PO what has and has not been tested.
  • Checks
    • This lists everything you know that needs checking before you start testing. This list will be based on acceptance criteria and any other areas you believe may be affected i.e. areas that require regression testing.
  • Notes
    • This is where you document all of your noteworthy observations and comments that are not explicitly listed in the acceptance criteria but believe should be highlighted to the PO.

Below is a list of icons we use to annotate our notes along with how and why we use each icon. A full list of icons can be found here.

  • no_problem_to_report– (/) – Means no apparent issues found while testing, feature seems to behave as expected
  • needs_to_be_fixed– (x) – Something is broken, missing or does not work as expected and must be fixed. Developers only have to look at the (x) icons. They know they can ignore everything else in the Test Session
  • ready_for_test– (y) – used by developers to indicate when an issue is ready for test i.e. it moves from (x) to (y)
  • fyi – (i) – something we believe is worth highlighting to your Product Owner (think of it as an FYI). If the PO wants this item to be updated/fixed, we would change the (i) to (x) so developers know to fix this
  • question– (?) – question we need to ask UX/Product Owner, designer, etc.
  • blocker – (!) – used to indicate a test scenario is currently blocked

The Downside

JIRA Capture Test Sessions do have some downsides but for me, the pros definitely outweigh the cons. I’ve listed some things to keep in mind when using this Atlassian tool.

  • There are 2,000 character limits to each note within the overall Test Session (you can add multiple “notes” to your Test Session). Ideally, your notes should never exceed this limit but it all depends on how many issues you find while testing!
  • Other than the test session creator, only the person assigned to it can edit. The creator always has edit privileges. This can be a problem if there are more than 1 developers working on the associated feature
  • If 2 people are editing and refreshing the page at the same time, sometimes their updates may overwrite the other persons
  • You can’t add embed images in your test session
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s