Tag Archives: Test Tools

Short Posts, Testing

Document complex test setup information

Leave a comment

Testing systems which require complex and time consuming setup on the backend, initializing parameters, setting system conditions and flags, and using test tools can be challenging and fun, but often as testers we usually have a lot to cover and want to spend the majority of our time testing – which is what we should be doing.

Often in the chaos, we’re learning how and where to set up variables, conditions, flags, tools etc. to enable us to test our conditions and scenarios and observe what’s happening with the software we’re testing, while recording the results of our tests. During all of this, we often forgot to document and take note of the specific and complex setup required to test.

Sure we may remember how to set things up tomorrow, or the day after, but chances are, with the amount of things we’re testing, and the different types of test’s we’re doing, we wont remember them for long.

It may seem like there’s just not enough time to document complex test setup information, but taking some time to do so in whichever medium your project, team, or company uses, will save you and others on your team a lot of time and effort when it’s time to revisit the features. Take those fifteen minutes, you’ll be glad you did.

Testing

Test Tools

Leave a comment

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.