0

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.

user130934
  • 3
  • 1
  • How do you handle bugs in the requirements specification. – James McLeod May 11 '15 at 09:57
  • 3
    Who is reporting these defects? Who is entering them into the defect tracking tool? Is anyone performing any kind of triage on the defects to ensure they are valid before assigning them to a developer? Are these all defects or could they be enhancement requests or requirements changes? Are your requirements complete and clear or could these defects be misunderstandings between the development team and the test team or users who are reporting them? – Thomas Owens May 11 '15 at 10:07
  • Bugs are getting reported and entered in system by testing team. Yes, that is good suggestion that defect/bugs needs to be verified before passing it to development. – user130934 May 12 '15 at 07:19

2 Answers2

3

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.

jlouzado
  • 146
  • 4
  • Agreed, Tester should not be bogged down with requirement but what happens sometimes is bugs/defects gets logged just for sake of logging the bugs or increasing the count. it sometimes becomes tendency of tester that higher the number of bugs means they are doing better job. I guess this can be solved by discussing these bugs/issues with PL. – user130934 May 12 '15 at 08:33
  • right, the pressures on them might lead to them logging extra bugs as well to take the count higher. Ultimately it might help to just go talk to them and make sure you'll get on the same page. Maybe propose that they increment a recurrence counter if they see an old bug again instead of creating extra ones. – jlouzado May 12 '15 at 11:30
-4

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

Ewan
  • 70,664
  • 5
  • 76
  • 161