Why you need to have a dashboard

Software testers are many things to many people. We are analytical, technical and above all, curious about the software that we are testing. And while those descriptions are true, the traits we hold alone can not summarise the value that we provide to software development teams..

There is a distinction between what something is and what something does.

For example, my car’s engine is noisy and needs maintenance to function. But I can’t say that my car is defined by those characteristics.

If I told someone with no knowledge of cars that information. They would have little idea of what I am talking about except discovering that car engines are noisy and need to be maintained. Whereas if I told them my car’s job is to enable me to drive anywhere I need to go and to allow me to get places much quicker than walking. They would have a better understanding of what a car is.

This idea stems from Richard Feynman who once said, “Names don’t constitute knowledge”.

I would take that one step further and say that descriptions alone don’t equal the purpose of something.

What is the purpose of a software tester?

“Well, to find bugs in software”.

Well, that might be part of a software tester’s purpose indirectly. But anyone can find bugs, be it a developer, product manager, or another stakeholder. Finding bugs is the by-product of the activities of a software tester. But I would argue that is not a tester’s responsibility to find bugs any more than it is the responsibility of a developer to write code.

The problem with this association of testers with bugs, and bugs alone. Is that we will associate a tester with being the ones who find problems.

Instead, I would describe a software tester as an information collector and provider. We use various techniques and tools to gather information about the quality* of a software product. Present that information to stakeholders and empower them to make well-informed project-based decisions.

*Note: Quality is a large topic, and its meaning varies depending on the context you are in. One thing is for sure though, quality is a team objective and not the sole responsibility of the testing team.

With this association, we should instead see testers as providing value to a team. Helping projects to run smoothly while contributing positively to the overall development process.

How to be an information provider

One of the best ways that I recommend to testers is once they have collected all their information related to the quality of software. Is to show their work to others, be it on an internal wiki system, a SharePoint drive for others to access. Or via a purposely built dashboard using a tool like Atlassian’s Jira or Microsoft’s Azure DevOps.

The reason for this is that not only is this helpful for others who want to know the status of a particular bug or know how many open tickets there are. But it also allows you to add value to projects immediately, and it helps to build a positive view of your software testing activities.

It also empowers others with a single point of access to gain the information they need without having to hunt around and send countless emails or instant message conversations.

Think of a dashboard as enabling others to understand the key information that you have gathered through your testing activities.

Key features of a testing dashboard

What you include on a testing dashboard can vary from team to team, so I highly recommend taking the time to understand and find out and important information that others are looking for. And automate the gathering and displaying within your dashboard.

Automated information collection is really the key here. A dashboard that includes information from manual sources is prone to becoming outdated quickly, and its usefulness is negatively hampered.

The most common information I like to include are:

Open Bugs (Per project/Feature ideally).

This makes it easy for me or anyone else, to assess the number of open bugs for a project or feature. And then plan accordingly.

User Stories and Test Cases

Being able to see active user stories in one place is something that makes my own life easier. I need not go hunting and can instead see all the current and upcoming user stories and their test cases in one place.

Automation code commits

If your automation framework is frequently updated. Then being able to see when a new release was made and whether you need to update your code base is super helpful.

A testing dashboard is essentially a tool that connects you with your customers (project management and other stakeholders). So the construction of one is an opportunity for collaboration with your internal customers (management), to provide the information they need to not only make their lives easier. But to also enhance the sharing of information within the team and boost the quality of deliverables and the feedback you receive.

I hope this post was useful. Please post comments of your experiences of using QA dashboards in the comments below. Also, feel free to connect with me on Twitter and LinkedIn.

• Category: Software Testing