Any recommendations for bug tracking software?

[expat]

Step back a minute and thing of what "Quality" actually means. IIRC Meyer in the late 1970's descibed it as "Meets requirements".

Saw a comment about attitides to this on the US board:

I remember some years ago when I was doing a gig for a Japanese owned company. They local management was all Americans, but they were kept on a very short leash by their bosses in Tokyo who were constantly trying to get rid of us. One day we received a report which proved that the Japanese coders were almost 10 times more productive than the American contractors.

We countered with a report that showed the code they delivered was about 5 times more likely to break, even though it had passed their rigorous testing process.

The problem was that they coded exactly what the specs said. No more. No less. For example, the spec said to present a screen with 4 choices - A, B, C, D. When the user selects A do somethihg, when the user selects B do something else and so on. Worked great. But when a user typed "E" the program crashed. We reported this simple flaw and showed them a similar program written here. When the user typed "E" it generated an error message and waited for a valid response.

They triumphantly produced the spec and pointed out that no where did it say to generate this message.

We wondered how this made it through the testing phase, Turns out this problem came up several times, but the testers never reported it because they assumed it was their own fault for not following the instructions.

[salty]

It seems like the requirements document was inadequate, as were the functional specifications.

I was having this exact conversation with my boss yesterday. Requirements are by nature open to interpretation. In order for everyone to sing from the same songsheet, reviews of documentation need to be conducted- not just by the author and Project Manager- but by the whole project team.

The example you've highlighted about the absense of an error message. If the QA and Dev group were in the requirement creation meeting- this is something that would have been easily flagged up.

The message here is:

Move the QA involvement effort UP the cycle, and leave the traditional "oh, we'll do the testing later" ehos behind.

Testing for the known is a simple affair, whereas testing for the unknown is the tricky bit.

[janey]

I'm not a PM but I have been a project leader (all the hassle but none of the glory) and I worked under a PM who came from the same school of thought and salty here and I have to say I agree whole heartedly.

The team I was in (pre-the fab PM) was notorious for producing (or not producing as the case usually was) awful software. Post- the fab PM, the team became one of the strongest in the company, and was leading the way with process and quality.

I can not agree more wholeheartedly with what you say salty... I know what you say works as I've seen it in action.

I tried to take what I learnt from him into my role as proj leader and in a major company wide project my team finished our side of the project months in advance of everyone else... in fact I think some of them are still going now and this was over 6 months ago!

[BlasterBates]

I must say for this type of thing I just knock up an Access Database, or even an Excel sheet, both perfectly adequate.

[DimPrawn]

I think what really works is an end to end system.

It is best to have integrated system where problems reports can be logged centrally and change requests can be raised against the pr's.

Then the source repository (version control) is linked to the cr system so that all changes and labels are against these change requests.

All code associated with cr's are reviewed by the best designers and coders in the company before being put into a dev build

The build of software is automated and preferably continuous and any source that breaks the build is flagged up.

As each dev build is made automated deployment systems move them up to test where automated test scripts probe for failures.

Once past test, the problem reports are closed or further pr's are raised.

This is how I have worked in the past and it works very well.

The downside is the cost of these end to end quality systems and the time it takes to get them up and running, but boy do you meet deadlines with ease.

HTH

[VectraMan]

I must say for this type of thing I just knock up an Access Database, or even an Excel sheet, both perfectly adequate.

My old job we just used mesages in public folders in Outlook. Not a brilliant system, but it worked and everything else we looked at seemed to be a) expensive, b) a lot of effort to setup, and c) tended to dictate the way you work rather than working for you. The important thing is to keep track of everything, it doesn't really matter how. Absolutely the worse thing to happen is to have a system everybody hates so much that they try not to use it.

[DodgyAgent]

I am not technical, but reading your posts has given me some insight into testing and Quality management. I am going to see a client tomorrow who has a problem finding programmers who will fix bugs. They want people who have C C++ and a grounding in low level languages such as Assembler. Why do they not offshore the work to India? why is it difficult to find bug fixing programmers? and why do they want people with such strong skills?

help appreciated

[DimPrawn]

Fixing a bug, without just putting bodge code in place, often requires quite a lot of refactoring and sometimes attending to design flaws in the system.

Hence anything but a trivial bug requires a strong knowledge of the architecture and design and good problem solving and coding skills.

A sensible company that values quality will put their best people into the support team, especially if the product is rather "flawed" and overly complex.

Not just some numpty in India with 6 months experience an MCSD he bought from Mumbai for $10 and a vague grasp of the English language.

HTH

[DodgyAgent]

DP, I cannot tell you how helpful that is thanks

[privateeye]

I am going to see a client tomorrow who has a problem finding programmers who will fix bugs.

Most programmers consider bugfixing as a bore and want to be involved only on new work. Its work often given unfairly to juniors as not many people enjoy it. As a release manager I would say it is one of the most important jobs and requires skills that go across many disciplines - as first you have to analyse where the bug actually is front-end backend etc etc. Most programmers just like coding but don't like the analysis work involved with finding complex bugs.