Hey! You Got Your QA In My Programming!
Scruffy-Looking Cat Herder has an article entitled, "Skill Set Development" that discusses not only the need for separate QA and Development departments within a company with an IT division, but also the different skill sets.

For the most part, I'm in agreement. QA is a very different mindset from development, and it IS very hard to test your own code anything close to exhaustively. Whether or not it is useful for you to submit your software to a separate QA department (either internal or outsourced) really depends upon the cost of failure. If you are pushing out a small, internal application where failure might mean a loss of a few minutes and an irritated Customer Service rep, then you could certainly argue that it's not worth the effort. If failure means your company finds itself short a hundred thousand dollars in taxes at the end of the year, a pass or two by a dedicated QA team is probably warranted. If failure means your entire customer database can be compromised and personal information hijacked by a malicious external party, then the cost of failure could very well be your entire business.

He also goes on to claim that "developers are better off cultivating a perspective of getting their software out the door and testers are better off cultivating a perspective of preventing software from getting out the door until they cannot break it."

There's where I'll take some exception. My stint as a QA guy was actually as a weird hybrid position. I was an "Automated Testing Engineer" or something like that at Symantec. Basically, I wrote software to test software. The experience was incredibly valuable to me, as not only did I discover Python there, but I also learned to get into the QA mindset a little bit. That really helped open my eyes a bit more about "defensive coding" and learning to predict where failures are likely to occur in my own code. I think programmers who have a little QA angel (or devil) sitting on their shoulder warning them to protect their code against likely vectors of failure are going to write better code.

And based on some comments I got from some QA people testing my code at a later job, I think it worked. Though that could be chalked up just to the fact that I was a more grizzled veteran than some of the other coders.

As far as testing time is concerned, one solution is concurrently testing alongside development. This is a huge pain in the butt for developers, and I wouldn't want to get dogmatic about it, but having testing begin at the earliest possible state can not only save time, but can also help the developers get a better grasp of code quality and problem areas.


(Vaguely) related public display of ignorance:
* My Favorite Job Interviews
* No Excuse for IT Ignorance
* Programming Tip: Comment First
* My Worst Bug Ever

Read or Post Comments on the Forums! (All the cool kids are doing it...)

Labels: programming

- posted by The Rampant Coyote @ 6:00 AM (Permalink)