Bug Tracking In a Startup Environment!

Discipline is a must have for everybody involved in a bug tracking session. However startups are usually proud with their informal and creative atmosphere where such necessary parts of the project as the one we are currently talking about are causing boredom, frustration and even irritation. Surely there are ways of overcoming such attitude and that is exactly why we all are here. To discuss them accordingly.

Why bug track?

I believe we are all adults here with some minimal experience and even if we are not, well, even a kid should understand why software requires testing and bug tracking. Software that was not tested is software that was not fixed. Software that was not fixed is bad software. Nobody wants bad software when there are lots of great alternatives. The math is easy.

So what are your options?

  • Fast, often releases can do real magic. The most troublesome defects are the ones that have been around and not fixed for like ages. Open bugs are not something your team should hesitate with. Fast and often releases are practically eliminating such issues.
  • No opinion equals a solution. If an issue is reported it requires fixes instead of ‘it’s a feature’ kind of comments. You had something similar last week? You don’t believe the bug is curtail? All that are just opinions, and how do they help to achieve your common goal? Oh, right, they don’t. So either solve something or don’t get in the way.
  • One more thing. A bug may be either open or it’s closed. Surely your tools will allow you with richer functionality and dozens of possible statuses, however we are talking some serious business her. If you are in a startup time is more than money. Time is air and food and water. That means playing around with different ‘untriaged’ bugs is a waste. Your bugs are either open and somebody’s working on the case or they are closed and the team moved on.
  • Make sure you all have the same definition of a closed bug. Discussions on this matter are not leading the team anywhere when the process is already running. Most scenario go like this: developer fixes the bug and closes the ticket. Try it all way around and let the person that has spotted the bug decide whether it may be closed. This saves you from like a thousand other issues. And don’t try discussing bugs on meetings as it will take enormous amounts of time and effort. There is a tester that has located the bug and the developer responsible for fixing it. These two are enough to get the thing done without involving everybody. Other people have other work to do, right?

There is one more way though, your team may easily contact software testing services providers and rid themselves from the extra trouble but where is the fun of that, right?


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017

×