Enthused About: Quality Assurance

This post comes from the "why haven't I written this post yet" category. Indeed, I've been researching software testing for over 3 years, and haven't bothered to write about it even once on this blog. It's sad, really.

I'm curious why the bright minds of our generation (and the one behind it, now that I'm 6 years out of college) are so quick to thumb their noses at QA roles in the software industry. There are certainly plenty of boring QA jobs out there, but there are also many companies (especially "good", popular ones) now hiring "QA Developers" to focus on activities like automation, continuous integration, analysis, tool development, and in general, tasks related to keeping software "testable". I find this kind of work fascinating.

Here are five reasons why I prefer (yes, prefer) quality assurance work over feature development as a fairly well-qualified software engineer.

1. QA activities have broad scope and high impact. As a QA team member on a project, you're much more likely to cover several features of the product, if not several products for your organization. You're also much more likely to deal with production-quality data and "real" usage of the product than a feature developer. 
2. QA problems are hard. Measuring the quality of non-trivial applications is difficult. The input space of programs, in terms of scenarios that need to be considered to investigate correct functionality, increases exponentially with every decision point that's added. Setting out to cover all possible choices is a fool's errand. Developing generalizations that help make this problem approachable for a specific application, though, can be pretty challenging (and eventually rewarding) work.
3. Quality assurance as a discipline is evolving. Granted, I have not been in the industry long enough to make too many observations about how QA works everywhere; but I agree with some others that testing as a phase in the software development lifecycle is perhaps dying. Agile software development is all about velocity and a team being responsible for quality. This view seems to collide with the "gatekeeper" school of QA that tries to isolate at least some QA decisions to QA-specific personnel. What does it look like going forward? No one knows, I guess, but I think continuous QA activities, and the ability to give a snapshot of an application's quality at any time, will play an increasingly large role in agile organizations. Many of these activities require knowing how to code (unit testing, automation, measuring -ilities). These activities may work their way into the job descriptions of "ordinary" developers at some companies, or stay isolated to "QA developers" or even manual testers to whatever extent at others. I think it's awesome to work in a field that's being morphed right now - and to play whatever small role I can in defining the state-of-the-art.
4. I can stay connected to the open-source world. As a QA developer, I do a good deal of work with open-source software tools. Constantly trying to develop, improve, and leverage tools to make QA activities easier is at the core of my daily tasks. There are exciting open-source tools for browser automation (e.g., Selenium) and performance testing (e.g., Apache JMeter) for example. I've developed extensions for both of these tools as part of my job. This makes my skills transferable to any job (i.e., not just to companies with HP licenses) and keeps my feature development skills sharp. I think we're going to see more companies start to "give back" to the open-source community as well, as a high-velocity open-source project can out-feature a hacked-up in-house solution any day.
5. Automation rocks. This is a small thing, and maybe it's just me ... but  I don't think seeing a program automatically open and emulate a user at my scripted command will ever get old. There are also the challenges of emulating users in parallel, in isolation, and in an infrastructure that's actually maintainable with a growing codebase. I love it.

These are my personal experiences. On another note, I think it's possible that we can do a better job in CS education to show the challenges and excitement (too far?) that come with QA work. Programming itself is all about features, for sure, but QA is challenging because features don't act in isolation. What can we do about it?