Jan 29

Test Tools

I’ve used & learned how to use quite a few test tools over the course of my career thus far (and continue to do so) and one thing I’ve always believed in was that a test tool should aid you in your testing but shouldn’t define or limit the way you test or what you test.  About a week ago a fellow Software Tester I follow on Twitter, Benjamin Yaroch tweeted “A tool should help you accomplish a task, not dictate how the task is done.” I couldn’t agree more – but I will keep the scope and focus of this post on test tools (as opposed to tools in general) & bug/defect tracking tools in particular. I think my next post will be on SOA Test tools I’ve used.

I’ve been fortunate to have worked at companies and with teams that chose test tools that aided in what we did and what we were aiming to accomplish. I’ve also seen instances where because a particular test tool was available, it was chosen to be used within teams or projects where it wasn’t the best fit, which resulted in the way things were done to be built around the capabilities & features of the tool.

I’ve been asked “what is the best bug/defect tracking tool to invest in and use?”  My answer is that it depends on different things. Who will use it? How will they use it? Who will read the bugs? Who will update the bugs & the information in the bugs? Does the tool need to do more than track bugs?

A few years ago I was the principle software tester in a Software R&D team (one of the best teams I’ve ever had the opportunity to work with), we worked using an Agile SCRUM methodology and one of the tools we used was Rally Project Manager (which does a lot more than just serve as a bug/defect logging tool). For how we used it (user stories; associated bugs/defects; work effort estimates; time estimates; task breakdowns; acceptance criteria; sprint planning, burn down charts; measuring velocity etc …) I can’t think of a better tool I have used for the purpose we needed it for. The tool aided us in what we wanted & needed to accomplish – we didn’t modify the way we worked or the way we did things around the tool.

Currently I’m working on a project where I’m using HP Quality Center. The tool is a great fit for what we need it for (tracking new features & associated info; screen captures, bugs/defects). In this instance Rally Project Manager would not be the best tool – it would be overkill to use it.

I’ve worked on some independent projects with a small team where we used Microsoft Excel to keep track of bugs/defects.  It was easy for every member of the team to view, read, update information. It was great for how we intended to work and use it.

All this to iterate, test tools should serve a purpose – aid in what you’re doing, not define how you’re doing it.