Any recommendations for bug tracking software?

**privateeye** · 5 March 2006, 13:15

Jira by Atlassin - popular but I think its a bit cr#p - web based but amateurish so ideal if its an (Fr)Agile project. Alright for small teams

Test Track Pro by Seapine - highly configurable for workflows etc - web based and email enabled great for the more serious users such as projects using Best Practices ITIL etc etc. I beleive it integrates with CVS and Subversion but not sure. Great for much larger teams.

Not sure of licence cost for either.

**mcquiggd** · 5 March 2006, 13:38

Ta...

Initially we are looking to use it on our own small project (10 people) but the PM is keen to adopt any procedure that makes the group more efficient / him look good so Ive been asked to follow up my suggestion with a product recommendation..

Initially it will be 10 people, with one project, later it could be 80 people with multiple projects (c20).

**RSoles** · 5 March 2006, 14:57

Bugzilla?

One thing to remember is that it's the processes that surround the tool that will make or break the project, not the tool itself.

For example, I recently worked in a software testing role. Our 'process' was supposed to be for me to test the software and e-mail any bugs to a designer who entered the details into bugzilla, investigated and fixed the bug, closed off the bug report.. Easy, right? Naaaaah.

I found (loads of ) bugs, E-mailed them to the designer who couldn't reproduce them, didn't recognise them when I walked him through them, sat on them, lost them, everything to hide the bugs in 'his' code.

Management ran some statistics and went ballistic at how few failures the QA guys were picking up. Of course the designers were little angels, bug fix times down to a matter of hours (after weeks of my chasing the bugs to be entered).

It's important that QA (or equivalent) raise the bugs, enter all the details,
pass the bug to design who answer it (fix or bounce it) and then pass it back to QA for retest and clearing. </Rant>

edit:
Oh and Bugzilla's freeware.

RS.

**privateeye** · 5 March 2006, 15:15

Originally posted by RSoles

One thing to remember is that it's the processes that surround the tool that will make or break the project, not the tool itself.

Very true thats why I prefer Test Track Pro - you define your processes and incorporate them into test track which can be used to enforce the process. It is very intuitive for the users and protects them from having to know all the processes as most of it can be automated. Very good for change requests etc.

Another one to consider are the group of tools from Collabnet.

**mcquiggd** · 6 March 2006, 01:24

Originally posted by RSoles

Bugzilla?

One thing to remember is that it's the processes that surround the tool that will make or break the project, not the tool itself.

My thoughts exactly, but, I was trying to find a way to steer the disparate opinions on 'process' into at the very least a single point of contact, between the UI and Backend teams... they dont understand our technology, we dont understand theirs (you could say .Net v1.1 vs Progress Open Edge 10b)...

I spent the first two months of the contract creating a framework for both standalone and multiple page wizard type interfaces (which often interract), a workflow procedure, common error handling, logging etc, and authorisation / security, plus custom templates for Web Forms, Wizard Forms, etc

Now the UI team is a few days ahead of the database team - due to circumstances rather than to any lack of talent on their part it has to be said - we have a framework that lets us easily create 14 page wizard type interfaces in a day with one developer, but the backend team havent been given the time to write the web services we need to actually make them work...

So, now I am suggesting a bug / issue tracking system so we, as the UI team which tends to lead the flow of development of the project, can request a piece of backend business logic to be created which we can work with in advance, log errors, and generally know who to talk to for a particular issue to save time for all of us.... and incorporate this into the testing phase etc....

In tandem, im trying to get agreement from the senior Progress guys to work in a fashion that suits us all... they are working on several projects, we UI guys are working on just the one. Tricky situation, I have a lot of time for the database guys (and lady), but the project will falter unless we start some sort of basic methodology.

**salty** · 8 March 2006, 15:10

Originally posted by RSoles

Management ran some statistics and went ballistic at how few failures the QA guys were picking up. Of course the designers were little angels, bug fix times down to a matter of hours (after weeks of my chasing the bugs to be entered).

It's important that QA (or equivalent) raise the bugs, enter all the details,
pass the bug to design who answer it (fix or bounce it) and then pass it back to QA for retest and clearing.

edit:
Oh and Bugzilla's freeware.

RS.

Firstly: Introductions: I'm both QA and Project Manager for a large multi national company, and have been in this role for around ten years. I've previously been employed by Rational, Microsoft and a few other multi-nationals of note.. so I speak from experience.

A lack of bug discovery is symptomatic of one of two things:

Either

The software constructed is of such a high quality, that defect discovery rate isn't low at all- it is the expected fine rate.

However, I'd suggest that the reason for a lack of defect discovery is down to poor planning borne from poor process.

Step back a minute and thing of what "Quality" actually means. IIRC Meyer in the late 1970's descibed it as "Meets requirements". He eventually revised his comment, but the basis of his definition remained the same. If the project requirements are poor, then the implementation of functional specifications -> test documentation will be inadequate.

The traditional philosophy of software construction has been :

(1) Code
(2) Test
(3) Bug fix

The issue here is that the application testing is happening far too late in the project lifecycle. The QA group need to be involved at the conception of the project both to understand what is expected of the application, and what is expected of them with regards to testing.

You've also made no mention of unit nor integration testing by development. If you can catch issues prior to hand off to QA, then QA won't have to work upon a broken build. Even if the integration test flushes out issues- they're known about and the QA lead can make a judgement call as to whether they want to take a build or not.

Finally, are you employing testers or test engineers? There's a vast difference between the two. Testers will push buttons. Test engineers will determine test cases/documentation that will stress the application and provide confidence that the product being delivered to market is of a known quality.

**janey** · 8 March 2006, 16:03

Originally posted by salty

Step back a minute and thing of what "Quality" actually means. IIRC Meyer in the late 1970's descibed it as "Meets requirements". He eventually revised his comment, but the basis of his definition remained the same. If the project requirements are poor, then the implementation of functional specifications -> test documentation will be inadequate.

Please come work here!!!!!!!!!!

**salty** · 8 March 2006, 16:18

Originally posted by janey

Please come work here!!!!!!!!!!

I am expensive

**janey** · 8 March 2006, 16:24

Originally posted by salty

I am expensive

won't be me who's paying!

doubt the existing PM would be very happy tho.. plus he'd be the one to employ you.. doubt that's going to happen!

Any recommendations for bug tracking software?