8 Ways to Improve your Test Case Management Practices and Make Your Team Agile, Productive and Happy

You know that feeling when your team hold you responsible for their misery? I’m sure you do!

The sheer exasperation in their eyes, and the accusing looks darted at you for not doing more to make their lives easier. The curse of testers is that they’re always scrambling to meet project deadlines, regularly working weekends. Long work days don’t help with keeping up morale and energy levels.

There’s the pile of defects that needs trawling through for those that are unnecessary, irrelevant, or worse still, duplicates from previous testing. You’ve tried everything to get ahead of the curve. Yet, despite all the effort, everyone seems to be pulling up your team constantly for being late – with planning, with delivery.

If this rings true in your ears, you’re not alone. Luckily, it’s not impossible to fix either.

Read on to learn about common test case management mistakes, and how to get around them.

1. First up, the biggie – There isn’t a central test repository

Case Management takes on a lot of significance when your team are working on projects/changes that are collectively part of medium-to-large IT programmes.

Why? Because there is a level of repeatability in the testing delivered in each of these projects.

For instance, you could be delivering an upgrade to a new version of your product to a client that are currently on an older version in all their markets. By nature, upgrade is a repeatable process.

You’d think lack of a central repository is a rookie error, but then again, you’d be surprised at how prevalent it is. Test managers regularly screw up by allowing individual projects to maintain their own test repositories.

This is an poor habit that isn’t easy to shake off. When your team are managing so many test plans each (multitasking is another malady that affects the masses), it is an easy (and lazy) decision to create a separate test area for each project – ignoring interdependencies and overlaps.

Test managers should consider the value and productivity boost a central repository would bring. There may be other projects covering some common ground, or may have actually already tested some of your scope. And in a lot of cases, they might have already found and fixed some of the defects that your testers might ‘discover’ all over again.

All this mindlessness leads to a host of other issues…

2. The same test cases are created multiple times

Scripting a test case is a time-intensive task. And it doesn’t help when your team script the same test case over and over. Even if they’re copy-pasting (or downloading/uploading), ultimately there is a lot of inefficiency and wastage of time.

Duplication of effort becomes a daily problem, not easily discovered unless you know to look for it. And when you’re trying to reduce duplication and increase re-use, the manual nature of this endeavour consumes too much time and effort, making it undesirable and even more inefficient.

When you manage a central repository of test cases for a system, you are enabling your team to ‘subscribe’ to the cases they feel are relevant to the particular project they are working on at any moment. Additional, new test cases captured at project level should go into the repository first, allowing other projects to benefit.

3. Tagging is confusing, or virtually non-existent

Let’s say you did try to create a central test bank – but it is utterly unusable. Testers don’t know how to look for a particular test case – because the conventions used to identify each case are not consistent. This confusion leads to the same issues as not having a repository in the first place – duplication and time leakage.

When you start thinking global, priorities like tagging will become quickly visible and important. Tagging will help your team look for and discover test cases quickly, promoting re-use. When consistent tagging conventions are practiced across your team, then the repository will also grow at breakneck pace, reducing duplication even further.

For example, when I was helping a client with improving their Case Management practices, one of the first things we introduced were rules for tagging. Being a multi-platform airline ticketing agency, it was critical for the team to tag every case with its function, sub-function, channel, device, customer type, agent type etc.

This practice – while initially painful – started reaping almost immediate results when testers could go online to the repository, filter relevant test cases for a project/enhancement, and sort of ‘drag and drop’ them onto a test plan.

Here is an example of a test case repository in ReQtest filtered to show only the subsystem named Email. This way we can quickly pick and reuse test cases when doing regression testing, for example.

4. Test cases are executed twice (and most often, many more times) – even when unnecessary, irrelevant

The more you test your product, the better. At the same time, you shouldn’t allow unnecessary duplication of test efforts.

Identify opportunities to ‘pass’ test cases without actually executing them – because other projects/phases may have already tested these. For example, can you get a UAT tester to pass a test case for look and feel by just simply reviewing SIT screenshots? You should be able to. It’s obviously not always that simple. There will still be a majority of cases that need to be tested separately.

By devising ways to avoid unnecessary testing, you’re reducing your testers’ workload, making them more productive. And allow them to focus on additional testing that could improve your product even further (say, a couple more Exploratory test sessions because they have the time). Or just pocket the saved time for more pressing things.

5. The same defects are raised again, just with different IDs – on different projects, and often on the same project.

Especially when you’re working on large Agile initiatives where multiple scrums coordinate to deliver software, it is quite possible for defects to be duplicated. It is not so much that the same defects are raised again, as much as it is the effort that goes into vetting each defect and more or less relying on memory recall to confirm which ones are duplicates.

Good case management allows you to see the link between a test case and all the defects that are related to it. When your team do see the link, instead of duplicating defects they could just add another instance of a defect to its original.

This also gives your team one more way to identify severity for a defect – if it impacts more than one project or scrum, the defect will need bumping up to the next level of severity.

6. Defects triage becomes a sham

This one is self-explanatory. Agile or Waterfall, triage is a reality if you’re working in a big-project environment. There are so many defects and only so much finite resource to fix them, that you need to find ways to measure which defects are important or urgent enough to be resolved.

Triage helps with the decision-making. Only, without a good repository and ability to see the link between a case and all defects related to it, it becomes hard to rank each defect in relation to the other.

Remember, the impact of poor triage capabilities extends beyond your team – they affect the developers the most, as these are the guys that ultimately fix defects. If your testers can’t triage defects effectively, your developers may end up working on defects that are not necessarily the highest priority. When you’re close to releasing software to your customers, the effectiveness of your triage process is the difference between delivering a product with all serious customer-impacting issues fixed, and not.

Link and track related or duplicate defects – this will help kill duplicates when an original defect is fixed, and improve triage. Duplicates will provide implicit prioritization – defects with duplicates should be considered more important than others, and will reduce the number of unique defects that actually need triaging – saving time and effort.

7. Projects that are inter-linked have their own project areas

While this is technically outside your remit, it is your responsibility as Test Manager to exercise adequate influence on programme/department-level project management practices. Why, you ask? Because these practices will directly enhance or impede your ability to deliver your job effectively.

For instance, if your team are delivering testing for a medium-to-large sized programme, you’re probably staring at anywhere from three to a dozen projects that need testing support. Now imagine each of these projects have their own project areas on RTC, JIRA, or whatever else you’re using. Code branches, test documentation, mapping user stories to test cases, etc. will become highly disjointed. The same user stories need to be copied over or re-created in each project area that needs them.

There will be many versions of the code floating around, each with their own sub-set of additional functionality – some of which is duplicated across code branches. Test planning and execution becomes inefficient, with a significant amount of duplication.

Go for a global product backlog, with each project having its own release backlog that always subscribes from the product backlog. This will allow Test Planning and Management at a global level as well, giving the macro-view that comes with central repositories.

With drag-and-drop test case management solutions, planning for a test cycle will become a breeze. Identifying scope for testing becomes easier, and so does pulling together a test plan. With centralization also comes the macro-view of what is happening elsewhere in your organization, increasing reusability and traceability and while reducing redundancy appreciably.

8. Finally, you don’t have the right tools

The right tools will complement your efforts at improved test case Management. Test planning, execution and analysis can all become infinitely easier when you have a tool suite tailored for test case management.

Of course, we use our own ReQtest software for test management and test case management. Traceability allows you to see which requirement a test case is based on, and which bug reports are linked to a particular test case.

ReQtest software also offers simple integration to third-party systems such as JIRA, letting you easily migrate all your projects to a new platform.

What is your experience of Case Management? Do you have any ideas for making Case Management more effective? Discuss your views in the comments section below.