Yes, I doubt. I doubt a lot, especially on projects that tell me that things
are working good and we're on target, I sit back and think - am I missing
something? I think its partly endemic to people who work in Test, because let's
face it we are in the position of being the person next in line from when
something is done and there needs to be a step to make sure that the something
is done right. If you've been in this position this may be familiar to you:
Developer: Hey, the code is ready I'm going to hand it over to you later, I'm done with it and it looks good!
Tester: Thanks for letting me know, I'll get back to you once I check it out.
Then you do, and your getting back to the Developer involves defect reports. Was it good? Probably, it met what the Developer was trying to do with it, there were Unit Tests which ran and passed, or what was the minimun to pass did, so it was handed to Test. Now, Test has its own tests to run, its plan and its criteria to be able to say that things are stable enough to put it into Production and let Customers use it. Testers usually have Tests that Developers never run, or want to get into, so they are looking at things from a higher level, sort of like the Ranger in the Watchtower, we have our scope up and we are looking all around. Meanwhile, the Developer was just doing something over in one place and getting that to look nice, while nearby another Developer was doing the same thing but somehow they will collide. Testers are there to raise the warning, hey there is some cross-purposes here or to see that there may be, if its been communicated that Developers are working together on something and maybe no one involved realizes there is some dependency.
So where does the doubting come in? Remember those Customers? Well, if a Customer sees something wrong and calls up with a problem, or is angry that there is a problem, many companies will look to find out why that problem got out there. Someone has to take responsibility for it, and because we have that person in Test between the Developer and Production its that person's fault that anything got past, not that the Developer put it there - by mistake or accident - but that the Customer saw it. To avoid that I became a doubter.
Now, being a doubter can be a strength, it makes you question everything and you look for issues that may need resolution, but to be KNOWN as a doubter is pretty bad. Then you get a reputation, and sometimes people won't want to work with you because they know you'll come back with issues, complaints or will be negative right away. What is needed is something I like to call Constructive Doubt.
Constructive Doubt is what I do when I get code and need to look at it, I won't immediately snipe back and say "heh, more bugs for me to find?" when a Developer comes and says something is ready. Diplomacy is part of Constructive Doubt, because you want to build with it, anyone can tear down something, but it takes real skill to build something. Use that doubt to figure out some new way to test, use a new tool, a framework or something that will allow you to doubt in an automated fashion. Sounds like I am talking about Testing, but in reality part of a Test is a doubt, you doubt something is going to follow the requirement, sure you could call it a Verification or a Validation but in the middle of it all is a seed of doubt; you want to KNOW that something is doing the right thing in the right way. Sometimes when I have tested something enough I know it inside and out I sit back and think, how else could this fail? How else could I figure out that something failed? Where else could I doubt the process is working? Then you look, you learn and sometimes you find something new.
I'm in QA, I doubt and I build up on that.
Developer: Hey, the code is ready I'm going to hand it over to you later, I'm done with it and it looks good!
Tester: Thanks for letting me know, I'll get back to you once I check it out.
Then you do, and your getting back to the Developer involves defect reports. Was it good? Probably, it met what the Developer was trying to do with it, there were Unit Tests which ran and passed, or what was the minimun to pass did, so it was handed to Test. Now, Test has its own tests to run, its plan and its criteria to be able to say that things are stable enough to put it into Production and let Customers use it. Testers usually have Tests that Developers never run, or want to get into, so they are looking at things from a higher level, sort of like the Ranger in the Watchtower, we have our scope up and we are looking all around. Meanwhile, the Developer was just doing something over in one place and getting that to look nice, while nearby another Developer was doing the same thing but somehow they will collide. Testers are there to raise the warning, hey there is some cross-purposes here or to see that there may be, if its been communicated that Developers are working together on something and maybe no one involved realizes there is some dependency.
So where does the doubting come in? Remember those Customers? Well, if a Customer sees something wrong and calls up with a problem, or is angry that there is a problem, many companies will look to find out why that problem got out there. Someone has to take responsibility for it, and because we have that person in Test between the Developer and Production its that person's fault that anything got past, not that the Developer put it there - by mistake or accident - but that the Customer saw it. To avoid that I became a doubter.
Now, being a doubter can be a strength, it makes you question everything and you look for issues that may need resolution, but to be KNOWN as a doubter is pretty bad. Then you get a reputation, and sometimes people won't want to work with you because they know you'll come back with issues, complaints or will be negative right away. What is needed is something I like to call Constructive Doubt.
Constructive Doubt is what I do when I get code and need to look at it, I won't immediately snipe back and say "heh, more bugs for me to find?" when a Developer comes and says something is ready. Diplomacy is part of Constructive Doubt, because you want to build with it, anyone can tear down something, but it takes real skill to build something. Use that doubt to figure out some new way to test, use a new tool, a framework or something that will allow you to doubt in an automated fashion. Sounds like I am talking about Testing, but in reality part of a Test is a doubt, you doubt something is going to follow the requirement, sure you could call it a Verification or a Validation but in the middle of it all is a seed of doubt; you want to KNOW that something is doing the right thing in the right way. Sometimes when I have tested something enough I know it inside and out I sit back and think, how else could this fail? How else could I figure out that something failed? Where else could I doubt the process is working? Then you look, you learn and sometimes you find something new.
I'm in QA, I doubt and I build up on that.
No comments:
Post a Comment