A lesser known story about computer history is where the term software bug came from. As it turns out it has its roots in none other than an actual bug that flew its way into an old computer system. Once the operator identified and removed it, the term debugging was born.
Since then computer scientists have gone on to create reams of software chalk full of errors that causes it not to work. From logic errors, syntax errors, to the ultimate faux pas- the infinite loop- almost all software has bugs in it at some point. One twist in the software bug coding paradigm was pointed out by a previous coworker of mine. He observed that back in the old days syntax errors were bad and would cause the computer to beep fiercely at you and the entire program to come crashing to a halt. But in today’s software world they’re good. If you get a syntax error now you can almost always pin point the problem and quickly correct it. Other errors you might encounter in modern software projects can be difficult to track. For instance, data being corrupted somewhere along a lengthy process leaving little trace of how it happened. Ah, the joys of coding.
To aid and assist the software coders an industry of bug tracking software has evolved. These systems are full of features and options to help you log, track, and close the bugs found in your program. The competition in the bug tracking sector has driven people to add an increasingly large number of never to be used features. These have led to projects that can be considered feature bloat, which tend to slow developers down, and sometimes introduce bugs of their own!
Now there’s a simple offering for bug tracking, with Bugrocket. It’s a new online application that provides everything development teams need to track bugs without any unnecessary features. It’s dubbed, “A simple bug tracking system for small teams.”
The first thing to do with Bugrocket is to spend a few minutes taking the tour. I don’t say this to try to steer anyone towards their product unnecessarily- it’s actually rather entertaining. There’s a ‘bug rocket’ that flies from one slide to the next guiding you through the process. In the background the clouds move accordingly. It’s adds a nice touch.
Once registered you can create user accounts for the team and start logging bugs. This requires a minor amount of setup. First you create a project, such as, “Disco Web Site.” Each project consists of a series of lists. The first can be Alpha release, for instance. Each list represents a milestone within the project. Once the lists are created you can log bugs under each list. It’s really rather simple. Just like the rocket tour said it would be.
The bugs themselves have all the requisite features including title, who it’s assigned to, a bug number, comments section, and the ability to attach files. It starts in the triage phase, (also known as the denial phase). Then assigned, QA, and Closed. When closed it’s assigned a reason ranging from verified, duplicate, to works as expected. Far be it from QA to submit a bad bug report!
They say the difference between hardware and software is hardware you can hit with a hammer, software you can only cuss at. Although it doesn’t say so explicitly on their website, Bugrocket will reduce the amount of profanity expunged by a development team. It gives you the tools to effectively keep track of your software’s bugs without a dizzying array of features. With it teams can quickly and easily log, monitor, and close bugs. No hammers, or insecticide, are included.