sqa | doc | management
The start-up qa manager’s first 100 hours: bug database

The start-up qa manager’s first 100 hours: bug database

This is the first in an occasional series on being the first qa person in your engineering organization. Taking a cue from the oval office and putting our own spin on it: what does a qa manager need to accomplish in his or her first one hundred hours on the job? For this series, I assume that the qa manager is also the very first official qa engineer at the company.

Your first day on the job, there’s more to be done than you can possibly do alone. You need to spend time RIGHT NOW getting work done learning the system, setting up your environment, then testing. You also need to spend time RIGHT NOW setting up systems to be organized.  This last task is critical but not obvious: bug tracking systems, a documentation system, and a project management system enable future work and future productivity. You should work to put these system in place immediately.

Let’s today talk about bug tracking systems. What do you do?

If there is already an existing bug tracking system in place, you should simply use that system. It may not be to your complete liking. But development has already taken the time to set it up and use it; that tells me that the development is serious about process. So while part of your job may be to bring new ideas and your experience to the team, your job is also to integrate yourself with existing systems and processes.  Maybe a some future date you can convince the team to migrate to another system. Maybe. If it’s good enough, then that’s fine.

What if there is no bug tracking system yet in place? Let me save you from the tyranny of choice: if your organization is small (less than twenty people coding and testing), fast moving, slightly chaotic, and interested in just enough process, then I recommend you use ENTP’s Lighthouse. It’s hosted, it has a minimum of fields, and it’s just enough.  Most of all, it’s ready right now.

Don’t spend any more time researching what to use.

Why Lighthouse? To be sure there are many other good bug tracking systems out there. But the more popular, such as JIRA or Bugzilla are bloated pigs. They take too much time to set up and configure.  These massive bug tracking systems will take not only many hours or your time, but probably also someone from IT. JIRA, Bugzilla, and similar become projects unto themselves, instead of a tool to support the real project: whatever your software development team is working on.

At Playlist I regretfully  chose Bugzilla for our bug tracking system, having heard from others what a great system it is. It is a great system, if you have unlimited time and resources to work on it. I didn’t: I had real work to do. I spent many hours simplifying the Bugzilla bug entry and update forms – there were too many fields and the flow was overly complicated. Moreover our IT ran most of our internal systems on Centos Linux, a version that did not work well Bugzilla (here I blame the IT team for chosing this odd variant of Linux).  In particular, we were never able to get the graphical reports working due to some problematical graphics libraries.

More than just all the time spent setting up the system, it was the difficulty of adapting JIRA or Bugzilla to our workflow.  These tools force you to adapt to their work flow – how the builders of JIRA and Bugzilla think things should go, instead of how you all in your engineering group actually do things. This was by far my biggest complaint when evaluating JIRA and using Bugzilla; there are many comments on the various qa forums complaining about the same thing.

There are smaller scale systems, such as Mantis or BugTracker, which offer many features, but don’t fall in to bloated pig status. My strongest arguement against these systems is that they are not simple enough. Take a look at Lighthouse: there are very few fields, just six on the bug create form.  When I first saw how few fields there were, I thought there was no way that would work. But,  if your group is small, it really is all you need.  Later, if you grow, become geographically distributed, and have the budget to hire more people, maybe then you can consider a more complex, time consuming system.  Lighthouse might not scale well beyond a few dozen developers.

Finally, you might complain that ENTP charges a monthly fee, depending on the plan you chose. Let’s say for the sake of argument you choose their most expensive plan: the Gold plan which offers unlimited users and projects, for $100/month.  If you are looking into installing and configuring a pig like Jira or Bugzilla, you will spend may hours of your time, and probably others time, setting up and maintaining it.  Do the math: assume your time is worth at least $50 an hour, and same for your IT people: the answer becomes easy.

Remember, you’re there to help build software for an application or a website.  Implement a simple, clean bug tracking system that won’t take much time, and will free you up to do more important work. Good luck!

Disclaimer: I’m not getting paid by anyone from ENTP to write this, nor do I know anyone who works there.

Sorry, comments are closed for this post.