I haven’t blogged for ages and my writing feels rusty, but I’m back with a post about testing notes. I posted on Twitter that I shared my testing notes with people at work every day and four colleagues told me that they liked the notes. They liked them because they provided clarity and transparency about the status of testing for an important project. Some people on Twitter would like to see the notes so I’ll try to give you a good example in this post and also write a little about why these notes exist in the first place.
I started with these daily notes a couple of weeks ago. I’m involved with chain testing of a project that connects the work of many teams. Of course, testing at this phase (I feel so non-agile writing this word) is tough and slow. I noticed that we kept losing track of the status and tasks. That was because nobody bothered to write down anything during meetings and testing. A rookie mistake, basically.
I wanted to change the situation and the quickest win I saw was to start writing down more about what we were doing. I want to lead by example, so I shared my notes with everyone involved in the project: developers, analysts, testers, managers, product owners. With my notes, I aim to be transparent about what I have done for the project that day and give my view on the risks based on the issues that I’ve found. Over time, I added some things like the dashboard. It’s based on the “Low Tech Testing Dashboard” from Context Driven Testing, but it’s even simpler than that.
My aim of giving everyone an extremely simple overview seems to have worked. Managers like it especially because they don’t have time to read extensive reports and this keeps them up to date without a lot of bloat. I like it too because I don’t like to write extensive reports that no one reads and this helps me with testing (it’s like a small database that I can look back to).
If there’s one downside I have to name it’s that it’s a too simplistic version of reality. Because these notes are so short they don’t go into detail. I just hope that it’s also an invitation for people to ask me questions about my testing. I’ll gladly explain it to them.
Without further ado, here’s the template of my daily notes. It’s just a heuristic and the template can change almost daily, depending on my needs.
Title: Testing Notes [day + date]
[Summary of what was agreed during daily chain test standup, mainly if one of us had to do a task.]
[main testing area 1] A very short summary of what I’ve tested here and the issues I’ve found.
[main testing area x] repeat this for every main testing area
Summary of main issues: for the very TLDR people (*cough* managers?), one line per issue maximum. Only name the most impactful issues to avoid bloat.
Issue 1: describe in one line
Issue x: describe every other big issue in one line as well.
Trust / Status Dashboard: managers like this a lot because it provides information by a glance. The downside of this is of course that it’s an extremely simple model of reality. Below is an example dashboard with example values.
|what||trust level / status|
|main testing area 1||trust = low|
|main testing area 2|| low coverage testing is done, trust is okay for now. More |
testing will be done here
|main testing area 3||trust = xx|
|main testing area 4||“not started yet”|
|load test||in sprint, no results yet.|