You Tester! do you know why it's not working?It's not a bug?--How you feel if any developer say something like this.Yes it really hurts right! but always complaining is not a solution.we need to improve ourselves.But how? This is a million dollar question to us (QA-Team).Lets discuss to cope up with this problem:
well one way to cope is by not being over-dramatic about it
another solution might be to read theBug Advocacy paper from Cem Kaner
( aside - when was this written - 1994 ? and still people are being referred to it. )
and anyway, I stop testing when it is time to ship ;)
Give me a million dollars and I'll tell you the answer...
Actually, here's my two cents worth for free.
1. I never 'complain' to developers. I articulate and report where the software and or business requirement has not been met.
2. As a practioner of QA and Testing it's our job to improve ourselves and we typically use CIP to do this.
3. As for 'hurting', typically the battle scars make us thick skinned and it's not usually meant to be personal.
Sorry mate. Continuous Improvement Process. Google it. Testers will typically review the good, the bad and the ugly to make sure that the lessons are learned from. If we don't use CIP, we don't evolve and grow and without growth there's just boredom and stagnation.
I think the best thing about our job is that a lot of it is in our own hands. If we stop feeling sorry for ourselves and try to actually present the testers point of view in a professional manner we can succeed!
I often find that both the Developers and the testing team believe that they are at war with each other, which does not have to be the case!
I really get along with the development teams, and it is not that I don't hear statements like it is not a bug and so on but it is just that we need to be objective, logical and try to provide all the necessary information so decisions can be taken!
I am reading the book, 'Perfect Software and other illusions about testing' by Gerald Weinberg, I'd say it is a must read! And it will provide you with a lot to think about and do! I will be doing a review for it shortly as well!
bug is a bug...no matter whether developer's accept their mistakes or not...A good tester has to convince a developer for a bug....convincing is also a one part of tester's job
Well, how do you KNOW it's a bug? You can observe behavior that does not seem right to you, and if the spec if not complete (typically the case), or non-existent, then who are you to say it's a bug? You can present your findings to the developer, who, will most likely be defensive, or in some rare instances, agree that you've found a legitimate bug.
But if you find yourself in the situation where the developer disagrees, then your options are somewhat limited. If your organization has a Change Control Board (CCB), they may make a decision, but will most likely defer to the developer.
Sometimes you just have to move on - you document your findings and that's it.
bug is a bug. Thats right !! let the developers say what they want to. Actually they are hope less. They themselves dont know how they wrote the code. Actually a developer by Knowledge never replies to a tester like that. Because if the developer had wrote the code from his own mind then they themselves say that " Oh i got it u r right i missed the logic or something else".
On other side of coin, if the developer used GOOGLE for all his coding, he himself doesn't know where the flaw actually is. They just try to avoid the extra effort by making non sense statements.
If you got such situation where developer is saying its not a bug, and you are sure that its a valid and super critical bug. You can draft a mail to him and cc the Sr. to whom you are reporting.
Totally agree with Tarnnum, convincing developers is an (important) part of the job.
Must say that in the team I work in the 'relationship' between developers (both design and coding) is pretty good and nearly always reports are accepted in a good manner....
Probably has to do with the way in which reports have been presented in earlier projects... which has lead to a professional understanding of the testers role in the team... testers often have to tell others that they did 'a bad job', or 'made a mistake' (is how people see it at first).... after understanding that you're just all working together on creating a product with the highest possible quality (from both 'sides') you'll see that bug reports will be dealt with in a better way
On the behalf of my customers Mr G. Od and Mr S. Atan I am authorized to announce that an agreement has been reached between the parties and Heaven and Hell are to rest for an undetermined amount of time, starting today 13:00 GMT.
Back to topic.
- Read books and see what you can apply of the ideas in there
- Read blogs and see what you can apply of the ideas in there
- Read/listen/watch and see …
I'm now at the task of analyzing specs, which is completely new for me, but my testing experience helps, especially what I learned during the WT sessions aroun Cem Caners task (Sessions 20-22, I think).