The implementation of a Test Management
or Application Life Cycle (ALM) tool should be approached in the same way as any other IT project. These tools, once setup, will touch on, not only the software engineering team, but operations, project management, customer support and many other aspects of the business.
Getting the implementation wrong can be a costly exercise. Not only will you fail to see the expected return on investment but ultimately you’ll impact the quality of the products you’re releasing to your customers. And there are countless examples of companies whose reputations have been adversely affected by bad product releases.
Fundamentally you need to approach the implementation of a test management or ALM tool as a project. That means you write the business case, you build the product, you test before roll out, you deploy, manage and then end of life. Every single one of these phases is important. Here’s why.
Before you roll out a solution you need to build the business case. The business case is instrumental in working out if and why this is a good thing to do. More on writing the business case in this “Writing The Business Case for Automated Software Testing and Test Management Tools
” white paper
Once you’ve selected the right test management tool you need to look at how you install, setup and configure the solution. Even if you aren’t undertaking any customization of the tool it’s worth while specifying, in a formal document, how the solution will be setup and configured. This is usually a good time to look at existing business processes, enhance those processes and use the tool to support those enhancements. As always once you have a good spec you’ll find the construction (or in this case configuration) far more straightforward.
Once setup don’t overlook the importance of testing. As specialists in QA there is always a temptation for you and I to overlook this phase. Yet running through a few use cases or a small pilot project can tell you reams about how well a test management tool will work when rolled out across multiple projects. Iron out the issues and perfect the process you want to implement by piloting first. It’ll save days of effort further downstream.
Rollout and deployment of a test management solution is where you make or break it. Think about if you’re looking for people to voluntarily adopt this or if you’re going to enforce usage of the tool. Quite often for a QA team adoption and uptake is swift and simple. The QA team see the benefits of working with a dedicated tool rather than using Word or Excel and will adopt voluntarily. Adoption with teams beyond QA can be a different ball game though. More in this post on test management systems and user adoption
Operations (maintenance and support)
Once we’re live it’s unlikely things will run smoothly forever. You’ll need a dedicated team (or person) to cover the maintenance and support. This is likely to be at both an IT level (e.g. for installing product updates) and at end user level (e.g. how should a user work with the tool to follow our defined process).
End of life
Yes, at some point the solution will become obsolete. Might be 5 years time. Might be 50 years time. It will happen though. Ask yourself can you get data out easily? Can you archive projects? The typical scenario is that you are under some regulatory rules that say you must keep data for x number of years. If you can’t get your data out of the tool then you need to keep the tool running and licensed for x number of years, even if you aren’t using it. Whilst this part of the project may seem a long way off it’s important not to forget it.
This isn’t just about selecting a tool and then just using it. When we start looking at implementation of a test management tool or ALM solution as a project it forces us to answer the question “why are we doing this?” Successful implementation is key to the business making informed business decisions and the quality of the products you produce. Following good project management principles is key to ensuring that success.