Test note techniques in an issue tracker

Here are some ideas how to plan, track, report, note your testing in an issue tracker.

All can be combined as you want them to.
Do you have another idea? Would you tell me that?

What I am used to using

These ideas are based on my experience with issue trackers like Jira.
Those have a description text at the top and a comment section below.

Description:

Comments:

1. Technical issues with editing - A Warning

Depending on your issue tracker, you might be able to simultaneous edit safely or not.
Take a careful look.

Description

On Jira (server) the description is not safe for simultaneous editing. The last editor wins and overwrites others' changes. Maybe you can restore lost information from history, but that is just a laborious workaround.
Therefore coordinate with other editors.

An alternative is to use another place which allows save simultaneous editing.
This might by a cloud-shared document or a Wiki like Confluence.

Comments

At Jira comments can only be edited by the author.
If you intend a simultaneous edition you should not go for this.

(Not) Auto saving

Your issue tracker might not have auto-save. Save often, otherwise you might lose progress.

2. How to organize your notes in general

General structure

How to organize your notes chronologically.
You can do both either by comments or multiple sections in the issue description.  

One place

You have one place where you gather all your ideas, notes, findings, exclusions etc.

Incremental

For every new session/approach you create a new comment/section/instance. Older comments focus might be versions or test sessions.

As long as you are at the same session you keep editing the same comment.
When you change the focus, finalize the old comment and create a new one.

Here you can apply Session-based testing from James Marcus Bach.
Make every comment a new session.

Leading structure 

How to mainly separate your notes.

Functions - for complex tickets

For more complex tickets I make a list for every function and details to test where I include all deviations.
I prefer here a mind map, but at least Jira does not support this without a plugin.

Example

• Checkout with credit card
  • security number
    • correct
      • …
    • wrong
      • …
  • changing between different cards
• Checkout with debit card
  • …

Deviations - for simple tickets

When the tickets are comparable small and easy to understand what to test I just create a list of my deviations.
Simple means mostly anything which fits in a short and flat list.
e.g. just a few variations of simple function.

Example

1. Error X at variant A
2. Error Y when doing D
3. Strange behavior Z, when doing E. Who much is this ok?

Status of the elements

How to place a status of an element.This goes in hand with a Leading by Functions as you note all information. Its not that applicable for just noting deviations.

By item - for complex tickets

You add the status to each item individually.

Example

• Checkout with credit card
  • security number
    • correct
      • ❌Not working because XYZ
    • wrong
      
      • ✅works, a hint is show
      • ⚠️The hint text could be improved …
  • changing between different cards

By status - for simple tickets

You order items by status. This works as long as you do not have to move many items around.
It would be nice to have a tool which lets you add the status item and then get a report by status…

Example

• To discuss
  • B has a strange behavior because …
• To fix
  • Error X at A …
  • Error Y at D …
• To test
  • E
  • F
• OK
  • C

Most tickets are complex therefore most times I go for One Place, a Leading by Functions and Status by Item.

3. Helpful additions

Structures to use for information

What you use depends on the topic you are testing.
You might also us both in one tickets.

Lists

I use them, often with depth, for complex topics which have many individual details.
They might start small and can become bigger.

Examples are all shown in this article.

Tables

They are good for:

• when you have types of information (by columns) shared for similar points (by rows)
• Also for exchange with others (e.g. when you have a bug list in a issue)

Exchange

Example

• Finding: The issue you found. A short header and a longer description
  • You can also have a dedicated column for the description
• State: This about what actions should be done next. "Who is next".
  • Here you need shared understanding with all collaborating coworkers.
• Comment: Documenting further details and decision.
  • You can have different comment columns. 

Information types

Example

States

States should make your notes scannable about where you have to continue with what and where you are you done (having not set a state means I'm either working or have to work on that).
For the discussion with others I find it important to highlight where I either found a bug or where I'm blocked by something. 

You can either write them out or use symbols. You also can use uppercase intentionally to highlight some.

Examples

• ERROR: 
• ❌
• OK
• ✔️

Next topics

As this is mostly about how I make my notes I plan to write next about how to use your notes in collaboration with others and what ways I know to structure your collaboration by artifacts.