A long time ago I coded a now defunct modelling tool to help me with my testing. Half the battle with managing and reporting testing involves deciding how you will model it for the project you work on.
Generic Modelling
The generic set of formal modelling techniques I use, I often map on to:
- Entities
- Lists
- Hierarchies
- Graphs
When using Jira, I have access to Entities and Lists.
Lightweight Subjective Status Reporting
On a recent project we wanted a lightweight way of tracking progress/thoughts/notes over time. I really wanted a subjective ‘daily’ summary report which provided interested viewers insight into the testing without having to ask.
As part of my normal routine I have become used to creating a daily log and updating it throughout the day. Ofttimes creating a summary section that I can offer to anyone who asks.
How to do this using Jira?
We created a custom entity called something similar to “Status Tracking Summary”.
Every day, someone on the team would create this, and title it with the date “20 November 2013”.
We only really cared about the title and the description attributes on the entity.
The description took the form of a set of bullets that we maintained over the day to document the status e.g.
- waiting for db schema to configure environment
- release 23.45 received - not deployed yet
- ... etc.
Over the day we would maintain this, so at the end of the day it might look like
- db schema and release 23.45 deployed to environment
- initial sanity testing started see Jira-2567
- ... etc.
I initially thought that the title would change at the end of the day to represent a summary of the summary e.g. “Environment setup and sanity testing”, “Defect retesting after new release”. But this never felt natural and added no real value so the title normally reflected the date.
Typically, as a team of 3-4, we had 5 - 15 bullets on the list.
Use Dashboards to make things visible
To make it visible, we added a “Filter” on this entity, and added Filter display gadget to the testing dashboard which displayed the last 2 status updates.
This meant that anyone viewing the testing dashboard could see subjective statements of progress throughout the day, and historical end of day summaries throughout the project.
But people don’t like writing reports
I have grown used to tracking my day through bullets and actions that I take it for granted that everyone can do this. Still, I had initial concerns that not everyone on the team would add to the status and I might have to chase.
Fortunately that didn’t happen.
The team used the Dashboard throughout the day to see what defects they had allocated to them, and to work on tasks and defects in the appropriate state. Therefore they always saw the subjective daily status report when they visited the Dashboard and updating it became a natural task during the day.
You can report Daily, with mininal overhead
Very often stakeholders ask us to prepare daily reports. I find that creating, and updating, a summary log throughout the day often satisfies that requirement.
As a team, building it into our documentation process throughout the day added very little overhead and made a big difference to the stakeholders had to our testing.
