May 13, 2008

QA Mindset in a Dev Mind

I'm trying to prepare some guest posts for Game QA Blog and it has been a bit of a challenge to mentally shift myself back into the QA mindset. I've been trying to figure out what the difference has been really between being a developer and being a tester, and while I think I've got it, it's difficult to put into words.

As a developer, I can afford to have the one thing that I could never afford to have in QA...faith. Not faith in a higher power or faith in other people...faith in myself.

In QA, you are always second guessing everything...you have to. Did they implement this feature right? Did they fix their bug? Did my test cases properly cover the feature? Did I get all of the related features? Did my fellow testers properly test their areas? Could a combination of our tests trigger an interaction or integration bug? What don't we know? It doesn't help that if you miss something, it all comes back on QA.

Even the best testers lose some skepticism of that when they become developers. I can unit test all day long, but the difference is that while in QA my job was to keep bad software from going out, my job as a developer is to ship software. Every once in awhile, I catch myself doing the "it builds, smoke it, ship it" cycle and I really have to stop and remind myself of the pain that mindset can cause, but it does get increasingly harder to shift back to that.

The good thing is that while I have faith in my abilities, the tester in me keeps nagging me because the tester in me knows my weaknesses. My inner tester constantly reminds me that I have issues with double-caching under load at times, threading deadlocks (of course, who doesn't have problems with that), and remembering to code for the one corner case that is brought up as an aside in the design meetings that ends up being the most important part of the application.

I tend to rush through the implementation of my features because I have faith that I'll get pretty much everything but the above right so I can spend the proper amount of time testing my code to try to ensure that I've properly accounted for my weak spots. I guess that's another major upside about being a developer. I can make up for not being able to afford faith as a tester by continually testing my faith in my skills as a developer.

Every bug I find in my own code is penance for a bug that I let slip through.

1 comment:

Drogo said...

Ahh - but as an Automation Engineer, I get the best/worst of both worlds - code that will never be tested, and paranoia about everything :)