QA Ghetto

I am constantly amazed of the default assumption that QA people are just a step above helpdesk staff on the IT skills ladder. In my experience QA people range from test monkeys who just bang on the links and report the occasional bugs to scripting gurus who can seemingly invent 20 new ways to break an application in 10 minutes. This spectrum closely follows developers who range from code monkeys who learned just enough VB to be dangerous 10 years ago and can’t code their way out of a paper bag to gurus who can rip out an application under seemingly insane deadlines.

So why do so many IT folks assume that the testers are just an after thought and they couldn’t possibly code something, not even a simple Perl, Python, or Ruby script to push test data through an application. Not only that we couldn’t possibly allow them to install a scripting tool to let them try out some automation. No, they might blow up their machine and then the help desk staff might get a call to help clean up the mess. Never mind that that would be the help desk’s job or that fact that they are a lower level support staff versus QA staff who directly impact the company’s software products.

I think I find the low opinion of QA’s abilities most annoying because it mirrors the same sort of elitist thinking I see on a lot of software teams. You know the situation. Say the team has 10 developers on it, but everything is stratified between 8 front end developers who just code some JSP pages and two ‘real’ developers who build the ‘backend’ code that really makes the application go. Many of these front end developers have been stuck in a ghetto of just doing the GUI because you couldn’t dare expect an average developer to be able to say write a DAO. I find expecting all your developers to be able to code all the layers of an application is amazingly more productive. Sure some developers are never going to be as good as some of your stars, but knowing they can handle any part of an application even if it takes longer is a lot better than explaining to your customers that you can only handle one project at a time. (Better yet one of your uber developers leave and no one knows how to maintain the application.)