So here we go for the next 10 ideas on enhancing your test management process.
Split things up differently – Maybe you currently assign your staff based on projects. What about if you looked at a completely different approach and had a sub team that focuses on integration testing, some QA engineers that concentrated solely on user acceptance. Or maybe it’s time to embrace the agile way of life and embed QA engineers directly with the development team. Nobody says we have to be one big QA team where each member is focused on only his or her project. Experiment with something new.
Check availability stats – How much time did you waste last year because of system down time? And I’m not just talking about your test management tool here. I’m talking about email, environments, source code control systems. System down time, any system, wrecks our productivity. Look to see which systems caused you problems last year. Consider moving to the cloud maybe or building in more resilience. We moved to cloud based email last year. We had two outages each of about 1 hour. Yep, pretty inconvenient but still way more up time than we’ve had with managing it in house
Document management – QA is more than just plans, testcases and files full of results. You have design documents, specifications, project plans, etc, etc. Documents come in from all aspects of a project and the QA team needs to have visibility. Push for a consolidated tool to manage this across the whole project. If that isn’t going to fly then try to have some internal QA process that collates all the relevant documents and makes them accessible and visible to the whole QA team. Too often the teams are so focused on testing (as they should be) that they miss much of the important documentation being created outside of the team. Ultimately it’s best if we take responsibility for collecting that information and disseminating it
Look for gaps – What are you missing? If you sit down with colleagues and look for gaps you’ll probably find you’re missing quite a lot. Areas of testing that aren’t covered. Non functional requirements that aren’t being tested. Design documents that aren’t being reviewed. Document this and keep a track of it. When somethings written down it tends to hold more weight when shown to project managers when you’re arguing for more resources
Look for duplicates – Take time out to look for test cases that are duplicated. Or even better look for whole areas where effort is being duplicated. In larger and distributed teams it’s not unheard of to find two different QA engineers testing the same piece of functionality. If you’re really pushed for resources you may even find it beneficial to look at the unit testing that the dev team are carrying out and make sure you aren’t just repeating what they’re doing. If you find issues of duplication it may be worth looking at how you’re organising your QA effort in your test management tool. Perhaps you can make improvements in the way you structure your data help ensure that it’s easier to spot duplication of effort
Setup dashboards – How many of us have just settled for the standard dashboards that come with our test management tool? It’s easy to forget that dashboards can convey some very useful information. Yet we tweak them a little when we first install and setup our new tool then completely forget about them. Sit down with your team and other external stake holders and find out what information they’d like to see on a daily basis. If necessary find someone else within the organisation or an external company to create exactly what you need. Quite often dashboards that are supplied out of the box don’t show what you need. So invest a little time and money and implement dashboards that meet your exact needs
Integrate with your source code control tool – When we have a good process in place for our QA team we take it for granted that we have tracability between requirements, testcases and defects. Why not take that traceability a step further and link the code changes your dev team make to the defects that prompt those code changes? It’s relatively simple to link a test management tool that tracks defect to the source code control tools like Subversion. So when a developer is assigned a defect he or she makes updates to the code. When they check that code into the source code repository those changes and check ins are recorded in the defect as well. That way when a developer comes to modify the same files in the future they can see from the source code control tool which defects prompted the change. And likewise when you look at a defect you can see exactly what was changed to resolve the issue
Archive old projects – The tidy desk, tidy mind saying is often quoted. These days it’s not so much about a messy desk but about how messy the organisation of our data is once we’ve stored it within an application. So how much data is floating around that you don’t use anymore? How much of that data is hindering your ability to operate efficiently? Have a spring clean and archive what you are no longer using
Analyse usage – Are you really getting the maximum benefit out of using a test management tool? Are you only using a fraction of the features? Are certain members of staff hardly using the tool at all? You could sit down and list all the features your tool offers you. Or maybe just flick through the user guide for 30 minutes picking out features you didn’t know about. Once you have that list evaluate each list item asking yourself do we use that feature? Do we ‘need’ to use that feature or would it be useful? You’d be surprised how many features you didn’t even know about that could make a big difference to the way in which you conduct your day to day business. Once you have a list set about working out how best to implement these features and educating your team on how they should use them.
Use tablets – If you have a web based test management tool have you thought about seeing if it’ll work with a tablet device? For many QA engineers we’re not always working at our desks but up and down working between different lab environments. Having a tablet device that goes everywhere with you can make it easier and more efficient for capturing data. Whether that data might be capturing testcase ideas or just recording results. Just put a little time aside to evaluating if tablets could help improve your test management process.
That’s another 10 ideas for your to consider. Another 10 to follow on Thursday and another 10 on Friday. Feel free to add your own ideas in the comments below.
