So, to part 2. Another 10 ideas on how you might improve your test management process. No point waffling. So here we go.
Write a usage guide – Often writing things down helps clarify the process. Processes grow up over time and morph into something that we never really expected. Something that’s never really efficient either. Now it does take a bit of effort and time but it’s worth it. Trust me. Sit down and take an afternoon to document the processes you follow (the real ones, not ones think you’d like to be following) and the way in which you use your test management system. This is an undertaking that will not only help you clarify what your team are doing but will help you analyse ways in which you can improve things. It’s like putting something under the microscope. When you see what you’re doing under a microscope you’ll be in for some surprises.
Prioritise work – Yes everyone talks about prioritising work. Yes everyone has a go at it. Yet how many of us stick at it? How many of us manage to embed prioritisation into the core of our working practices. It takes discipline and consistency to see continuous benefits from sitting down and prioritising our work. Funny thing is as QA engineers we’re actually quite good at it. I mean we prioritise defects and assign defects day in day out. What if you applied that rigour to your day to day work?
Ask for feedback – How often do you ask someone for feedback on the way you and your team are performing? Never? Well try it. Ask the development manager what he thinks of the job the QA team carry out. Don’t be surprised if what you get back is negative. It’s human nature to pick holes in things. I’m guessing though that the development manager will be so surprised that you’ve asked that you’ll actually get some quite positive feedback too. Asking for feedback is difficult. Yet in many ways people respect you for it. They respect you even more if you go away and act on that feedback too.
Test case capture – You’ve heard of suggestion boxes that people like HR managers implement within a workplace? Well why not use a similar approach and implement a suggestion box for testcases? No I’m not suggesting you start asking the tea lady to come up with ideas. What I am suggesting is that you have an easy way to capture ideas for testcases from people outside of the QA team. So clients, customers, end users and developers. Developers especially. Developers are likely to have many ideas whilst coding a feature for ways in which the feature can be checked. Make it easy for them to capture those ideas and feed them back to the QA team. I’ll guarantee that you’ll improve the effectiveness of your coverage.
Review workflow – Sit down with a QA engineer and follow what he or she does. Note the steps they take, the data captured and the processes which they follow. Best to document what you see so that you can analyse it later. When you stand back and observe (and I mean observe, not interfere) you’ll get a view of what is going on that is somewhat different to the perspective you had previously. If you’re disturbed by what you see don’t blame the QA engineer. Blame the process that you’ve allowed to develop with a lack of guidance and steering. Don’t forget that once you’ve identified the issues you’re most of the way to solving them.
Add external users – How insular is your QA effort? How much input do you get from people and teams external to the QA team? Well there are customers, end users, project managers, product bosses, beta testers and more that all have a vested interest in what you do. Why not bring them further into the fold and get them closer to what you do? Give them access to your test management tools. Allow them access to the reports that are generated. Give them the capability to review documents. Let them write testcases. Just get them involved.
Track some different statistics – How long have you been using the same reports? To what extent are other stakeholders just bored with seeing the same data you churn out each week? Does anyone pay attention to the reports you create? If they don’t ask them what they want to see. Generate some different reports and ask them if it’s useful. Just a small bit of change can help wake people up to what you’re doing and help make them more aware of what’s important.
Centralise useful information – I’m a huge fan of writing test plans. Putting information down on paper helps to shine a light on everything we need to be considering as part of a QA project. What I’m not a fan of is that once written these plans seem to disappear into obscurity on some hard drive somewhere never to be seen again. Information is for sharing. Get it in a central location where everybody has access to it and everybody can contribute. I like to see everything in a test management tool. So a place where everyone is visiting and accessing day in day out. The idea is to keep important information in front of everyone every day. Think about where most of your team spend their time on your intranet and consider making documents and info available there.
Consider the end user – it’s all too easy to forget that we’re in this to make the end user happy. So when was the last time you spoke with an end user then? For many we’re so far removed from the end user that we have absolutely no visibility or idea about what they want. For this reason I’m always very keen to get involved at the start of a project with the UAT aspects. Get your QA engineers talking to the end user about UAT right at the start. It’s amazing what a bit of forethought on the UAT stage can feed back into the upfront design and development in the early stages of a project. And if nothing else it gets your QA team talking to the end user. And that can’t be a bad thing.
Create a 5 year plan – Ha! A five year plan I hear you say. I don’t know what’s happening next week let alone in 5 years time. Well you many not know what’s likely to be happening with new projects in 5 years time but I bet your team would appreciate some commitment to the development of their careers over the next 5 years. And then add in things like replacing obsolete QA environments, pre-empting new technologies, implementing tools and new test management processes. Add a few things like that and 5 years starts to look like a surprisingly short amount of time. Even if your plan ends up being just a wish list (rather than a full blown plan) you’ve got something to work towards. And that has to be better than just allowing the winds of change to batter you from every angle over the next few years. Harness those winds and go in the direction you want to go.
That’s it for another 10 thoughts on improving your test management process. Ten more to follow tomorrow.
