Defects Review and Management

Question

The doubt or question i have is something every developer might be facing time to time. it is related to testing and development team and their perspective.

I have observed that most of the Defects which are getting logged are purely based on judgement rather than requirement. apart from that there is attitude that bugs which are getting logged has to be resolved which is causing lot of trouble and rework.

What we as developer should do? How to tackle these scenarios?

Approach which i have adopted so far is to reject the issues which are not as per the requirement.

Answer 1

This sounds to me like a break-down of communication at a couple of levels. Since you've also not stated what your position in the project is, I'll assume that you're a regular dev who's working under an architect.

Breakdown of Workflow

Firstly it sounds like there's not a properly defined way to handle bugs as they're entered into the tracking system. Someone has to rank them according to importance and then assign them to be fixed within budget and time-line constraints.

Even basic bug-tracking systems have the ability to classify, rank and document various aspects of the issue. If you feel like these features could be used better, have a discussion with your architect or manager.

Breakdown of Trust

More importantly, it seems like there's a little bit of defensiveness and mistrust of whoever your testers are.

Understand that their role is to act as the user, so it might be better if they're not too bogged down with the details of the requirements specification. If they're raising bugs for you, don't immediately assume that they haven't understood the requirements well enough; try and drill down into what exactly they were trying to do and why they landed at that use-case.

Also if it's something that keeps coming up then there might be something that wasn't properly defined in the requirements.

Summary

All in all, just understand that you and the testers are on the same team and that you'll are both just trying to make a better product for the user. After all, customers aren't going to get your requirements document; either the thing works or it doesn't.

Answer 2

I am very familiar with this problem!

Also, controversially, I believe it is caused by AGILE DEVELOPMENT!

Think about it. Agile tries to drive devs faster by getting them to concentrate on completing what is asked for and move on to the next task. This is great, but it puts a huge pressure on the person writing the spec. If they miss something out it wont get done.

Usually the person writing the spec or tasks is a project manager who a: is not technical and b: hasn't been given anything more than 'I want a Webernet page! you have 3 months!'

They get around the problem of 'no spec' by hiring testers and telling them 'Just raise anything you don't like as a bug'

Again this is fine, because Agile is supposed to be iterative. Those bugs can go back in the queue as requirements and you just spin the dev wheel until everyone is happy.

BUT! that dosnt happen. What happens is the task is not accepted as done because bugs, the project is delayed indefinitely and the devs are blamed for either being slow or writing buggy code.

My personal fix for this (as a dev) is to ask for the test cases to be written first.

If you know what the tests are, you can test your code before you release it to test and it should pass 100% of the time. Happy Testers, happy Devs

If the test list seems short, the PM can see it right there and say 'Oh surely it should also do this?' Happy PM