How do you feel or what do you do when developer finds a bug that you could not?
If you start your own investigation how do you proceed?
Great question!
I want to learn more about how they found it so I can add that skill to my testing. I don’t feel bad about it since it is every team member’s responsibility to improve quality of products they create. In that spirit, I would thank the developer for both the experience and effort!
Joe
5 Likes
I’d agree with Joe. There are different defects and how you find them, efficiently, are different. Some defects are found via code review. Some are found because they are standard mistakes (history repeats itself), some require an understanding of the programming languages and its limitations.
I remember interviewing testers who would put a list of programming languages on their resume. Almost all of them would do things like, “I tested a program written in C, so I can say I know how to test C programs.” But this isn’t correct. If the testing skill you use to test a program written in C is the same as testing a program written in Java, then it isn’t C language specific.
Some things can be found by say a code review. The Standard C Library contains a method called gets(). This method is open to a buffer overflow attack. It should NEVER be used. Investigating how a defect is fixed is also helpful. I found a defect relating to gets(). The developer fixed it and now he catches other developers using this method during code reviews. This developer consistently catches defects before testers do. I think this is great. The more people catching defects, the better the program is.
I have a list of programming languages on my CV; but I never claimed that it meant that I knew how to test apps written in that language. I merely put those things into my CV to say that I had some familiarity with those languages; I never claimed competence in them.
(Not that recruitment agencies take any notice of that, to judge by the number of approaches I’ve had from agencies trying to recruit developers in those languages.)
I really like the first part of the question, “How do you feel?”
We should ask more of those kinds of questions. I believe that our feelings about the product and how we test them are as significant as what we see. If we feel like something is wrong, it usually is. If we feel confused by an aspect of a product, even if it passes all tests, then a typical user will likely also feel confused about the same aspect.
Anyhow, that isn’t an answer to the question.
At first, I feel like I haven’t done enough to test a product if a developer finds a defect after I have tested it. (Consequently, I also feel that way if a customer finds a defect, or even more so) But that is only a fleeting feeling until I follow it up with the joy of realizing that I am about to learn something new.
After discussion the problem and its discovery with the developer, we can make a plan to avoid similar testing voids in the future. Looking at the context of the problem can tell us if it is a one time thing, or a systematic problem in the testing. The follow-up is then determined by the team.
1 Like
It’s really easy to beat yourself up over a missed defect. Trust me, I’m an expert at it! However, you have to remember that QA/testing is a whole team approach. There was a discussion of guilt elsewhere on here, and I said there that it’s a feeling that does not help you. The defect was found. It will be dealt with. Sit down with the dev and discuss how it was missed and how you can avoid it in the future. Also, discuss how it came into existence in the first place! It sounds like you feel you are the sole quality gateway, and that, to me, is a path to madness.
1 Like
Relieved, mostly, unless it was a really obvious one that I missed. Then I feel relieved after I’m done with the head -> desk routine.
I’m the only tester in the organization, and I have a lot of non-testing duties as well. I’m more concerned that as many bugs as possible get caught than I am with who catches them. There are too many possible paths for me to test them all, so anything found elsewhere and fixed is something I don’t need to fear will get to a customer.
My usual process is to first find out if the bug in question is one I can reproduce and test. If it is reproducible, I’ll reproduce and work out how to test the fix. If not, I trust the developer to fix it and test it.