The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Bug tracking in Excel

Hi,
my boss is away on vacation and left me in charge.
We do not have a bug tracker system. Instead the testers describe the bug on our wiki.
We are releasing our software tomorrow and I am fearing a rush of bugs from the customers.
I just want an extremely light weight bug tracker solution that we can use (configuration time about 1 h) while the boss is away.
When he comes back we will have to evaluate a better alternative, like Fogbugz.
I was thinking of making a spread sheet in Excel with drop down lists and hyper links to the bug description on our wiki.
With this approach we do not get any revision info but at least a categorization of bugs into fixed, verified etc.

Do any one have any experience with this approach?

Thanks,
Anon for this one
Sunday, September 30, 2007
 
 
You want to create a new bug tracking system the day before you release software to customers? You're braver than I am!

What's wrong with the wiki that you think Excel will fix? I wouldn't insert a temporary solution when there's already an existing one and you plan to start evaluating a third. Seems more likely to confuse the staff than anything else.
farmboy Send private email
Sunday, September 30, 2007
 
 
Hi farmboy,
in our Wiki we can only group in one "dimension".
I guess I could have groups for "New", "Fixed" and "Verified" since this is the most important aspect.
But we also need to sort on other "dimensions", e.g.
"Assigned to", "Priority" etc.
Anon for this one
Sunday, September 30, 2007
 
 
You have an impending software release, this could be a good time to try a new system _along-side_ an existing one. But it makes no sense to fluff up or revamp your process the day you need it. In fact, if you had buy-in about this scientific experiement of "which bug tracking system is better?" from your team a month ahead of time, and you all came together on how the experiment would work itself out--that's great. But at this point you don't want team confusion. Everyone should just know how to make their current system serve them to the best of its ability. That will be tough enough.
Li-fan Chen Send private email
Sunday, September 30, 2007
 
 
Excel is better than a wiki. you may want to include a link to the wiki page for your bug in excel.

just use the excel spreadsheet to provide a summary, submitted by, module, importance, date, maybe some other stuff.
Contractor
Sunday, September 30, 2007
 
 
If you are determined to implement a bug tracking system now, and the boss is away (hence he cannot do anything about what you do), and you are thinking of trying out FogBugz eventually, why not try it now?  You can set up every developer in your organization on FogBugz for a free 45-day trial without even giving them your credit card number.

The problem with an Excel-based bug system is that only one person can edit the spreadsheet at a time. That is a recipe for non-use and/or disaster.  In addition, there is no way to put in proper comments or to enforce anything at all.

If you're determined to try something new the day you launch, set up FogBugz today and start working with it tomorrow.  You'll find out soon enough if it will work for your needs.  Worst case: you simply stop using it after your free period ends.
Karl Perry Send private email
Sunday, September 30, 2007
 
 
And if you use FogBugz, Karl Perry will personally export by hand all of the bugs back into your Wiki if for some strange silly reason your company decides to use something else.
Li-fan Chen Send private email
Sunday, September 30, 2007
 
 
You know your situation better than anyone here, and what you can get working in the time you have. Excel will be labour intensive and, as Karl says only 1 person can edit it at any time. But if this suits what you want for now, then go for it.

Better to start with this simple approach and build up to the all singing version than to try and got for it straight away when you haven't got enough time to do it properly.
IanH. Send private email
Sunday, September 30, 2007
 
 
> my boss is away on vacation and left me in charge.

and

> We are releasing our software tomorrow and I am fearing a rush of bugs from the customers.


Watch your back ;-)
IanH. Send private email
Sunday, September 30, 2007
 
 
So new version of an application means "rush of bugs from customers"?
Victor N. Send private email
Sunday, September 30, 2007
 
 
from what I hear of some development environments, it does :-(
farmboy Send private email
Sunday, September 30, 2007
 
 
Been there. In a previous life, I worked for a company where the main programmer would release the new version of our product and go on holidays, leaving the number two programmer to deal with whatever needed dealing with. Glad it was him and not me.
less is more
Sunday, September 30, 2007
 
 
Why not use Access?

Or is that a dumb question?
Nate Send private email
Monday, October 01, 2007
 
 
I think much of this comes down to how large of a scale project, and how many developers.

If your just one developer, then, really, using Excel is not such a bad idea.

It is same thing for if as a single developer do you use source code control?

I see no problem with even using a word here.

If you telling me you have 10 developers, and a flow of features and bug fixes, then the whole issue changes here….

This is all about the right horse for the right course.

Your mention your use of a wiki is also a alternative here. I think the wiki is a great “gathering” spot for you to add information. The problem is slicing, dicing, reporting, and even just filtering features by “priority” is a spot where the wiki likely falls down.

Perhaps you modify the “gathering” system so you can cut and paste (or import) the data into excel so you can order, and display the data the way you need. Sure, this approach is a bit corny to resort to cut and paste into excel, but hey…you need something here, and necessity is the mother of quick invention.

It also not clear the number of support calls, bug fixes, and new feature requests you need to track for this project (or expect). I think the *size* of the client base you have will also reflect this issue.

One developer can make quite a good sized project, and you can well get away without much bug tracking.

However, often it not the number of developers, it is in fact the number of customers you have that drives your needs here.  So, you could have a volume of requests, and fixes that very warrants a full blown bug system.

Not knowing your needs, Excel just might be your ticket here…

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Albert D. Kallal Send private email
Monday, October 01, 2007
 
 
In addition to all the good advice other people have provided so far: I am a big fan of Mantis (http://www.mantisbt.org/). It's lightweight bugtracker that is free and has everything you need. All you need to get everybody up and running is a LAMP (Linux) or WAMP (Windows) system, which is extremely easy to setup using something like WAMP5 or XAMPP.
Jeroen Bouwens
Monday, October 01, 2007
 
 
http://www.mantisbt.org/

If you are going the 'free' route, Mantis is a good option. It took me a few hours to install, learn the system, test, create users and projects and be up and running. We've used it with teams of 7-8 people and it works fine. It's used as the bug tracker on a good number of Sourceforge projects. Or FogBugz.

You can use Excel or Access equally, you just have the problem of sharing the file with others.
Jason T
Monday, October 01, 2007
 
 
You could have this up and running in less than an hour:

http://ifdefined.com/bugtrackernet.html
TownDrunk
Monday, October 01, 2007
 
 
+1 for Karl Perry and Jason T

Just pick bug tracking system and start using it now.
I found many times that Excel sucks as a tool to capture requirements (AKA To Do list) or track bugs. Given tabular format and that you would have one cell to put bug description lead to situation when every bug is described by cryptic title instead of text paragraph with detailed explanation.

Excel is good for project managers because it is easy to assign status on each bug and then filter them or generate reports but it makes poor job for developers and testers to actually track and fix bugs.

I also vote for Mantis, when we had similar situation on one of my projects, it took us less than a day to figure out how to use Mantis and it was MUCH better than Excel spreadsheet.
Eugene
Monday, October 01, 2007
 
 
Yes, every bug tracker is better than Excel.

Personally, I don't like Mantis too much because of optical reasons (layout really sucks) and lack of workflow (you have to match bug status and solutions accordingly), but it is really a good tool compared to anything Excel can provide. If all you have is a webserver with PHP and MySQL, then Mantis is usually installed in less than 15 minutes and ready to go.

My preference is Trac, which is a good integration of a bug tracker, a wiki and a SVN repository browser. If you are happy enough to have a webserver running Python and using SVN as your version control system, then you should give Trac a try.
No good nickname left
Monday, October 01, 2007
 
 
www.unfuddle.com ... don't know if you can get submissions from unregistered users though
anonymous_coward Send private email
Monday, October 01, 2007
 
 
The Spreadsheet from Google Documents?

If you have something in Excel already you can easily import it, and as for collaboration... Hey, it's Google!

Apart from that, I second the "why not just Acces" comment if you need a database of any kind...
wauter Send private email
Tuesday, October 02, 2007
 
 
Excel is not the best option to track bugs. Bug descriptions can get pretty verbose, and depending on how you have formatted your spreadsheet, readability may go down as the descriptions get more wordy.

Instead go with Mantis. We have been using it for over 2 years now for a team of 5 developers and 1 QA person. It works very well for us.
Jigna
Tuesday, October 02, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz