QA testing is black magic for developers
Submitted by Ainars Galvans on Tue, 09/12/2008 - 09:29.
test management
Just red a blog about developers having no idea of what QA team is doing. As I can’t seem to be able to add a comment to Michael Furmaniuk’s blog (which is by the way in the list of blogs I read) I decided to write a short reflection here in my blog.
Well, developers may or may not know read our test cases and learn what tools we are using. But developers know for sure what the requirements we have and what the code testers get. They know the bugs testers report. What they are most curious about (in my experience) are two things:
1) How do we manage to find all those bugs they missed.
2) Why do we sometimes find them so late.
I don’t know is that’s Michaels’ problem, but he reminded me about mine.
The black box testing: developer’s vision
Developers see testing process as the black box that they feed with code in and get out of it a flow of bugs for them to fix. And no matter how they manage to fix the bugs the black box continues to split out more and more bugs, just as perpetuum mobile. Indeed I’ve read others and experienced it myself as developer comes to me and say: “Do you QA testing and tell me what the bugs I’ve missed. I know there should a some of them left but there are so many possible tests that it would take weeks for me to test them all and I know you will be done in a few hours with quite complete list of bugs”.
They also don’t understand why we don’t find all the bugs on the first run. Although they keep rejecting “non-repeatable” bugs – the bugs that takes a lot of time and sometimes even luck to track down. The bugs that I sometimes give up tracking down and decide to if I will see it again I will try to track it down again.
The problem: they want to be in charge
I’ve always said that testing is a service. You serve either development team or customer (depending on who hired you/whom you report). I’ve been developer’s service most of my life. Developers and especially project managers are willing to influence testing. They want to understand what are we testing now and let us know it this is what they need us to do now. And they have all the rights to want – otherwise we become gatekeepers and I’m in the school of testing that believes testers should be the gate keepers.
Well there are some methods for developers to help us set priorities (risk analysis). But it is really hard to let them provide ongoing feedback on our testing as it progress. How to let them feel in charge of testing even without understanding how do we test? I’m writing about it right now, so this topic is to be continued…
Well, developers may or may not know read our test cases and learn what tools we are using. But developers know for sure what the requirements we have and what the code testers get. They know the bugs testers report. What they are most curious about (in my experience) are two things:
1) How do we manage to find all those bugs they missed.
2) Why do we sometimes find them so late.
I don’t know is that’s Michaels’ problem, but he reminded me about mine.
The black box testing: developer’s vision
Developers see testing process as the black box that they feed with code in and get out of it a flow of bugs for them to fix. And no matter how they manage to fix the bugs the black box continues to split out more and more bugs, just as perpetuum mobile. Indeed I’ve read others and experienced it myself as developer comes to me and say: “Do you QA testing and tell me what the bugs I’ve missed. I know there should a some of them left but there are so many possible tests that it would take weeks for me to test them all and I know you will be done in a few hours with quite complete list of bugs”.
They also don’t understand why we don’t find all the bugs on the first run. Although they keep rejecting “non-repeatable” bugs – the bugs that takes a lot of time and sometimes even luck to track down. The bugs that I sometimes give up tracking down and decide to if I will see it again I will try to track it down again.
The problem: they want to be in charge
I’ve always said that testing is a service. You serve either development team or customer (depending on who hired you/whom you report). I’ve been developer’s service most of my life. Developers and especially project managers are willing to influence testing. They want to understand what are we testing now and let us know it this is what they need us to do now. And they have all the rights to want – otherwise we become gatekeepers and I’m in the school of testing that believes testers should be the gate keepers.
Well there are some methods for developers to help us set priorities (risk analysis). But it is really hard to let them provide ongoing feedback on our testing as it progress. How to let them feel in charge of testing even without understanding how do we test? I’m writing about it right now, so this topic is to be continued…