Assuring quality is everyone's job -- but programmers and testers alike forget that.
I have encountered all sorts of variations to where developer testing ends and Quality Assurance/Professional Tester testing begins. Some developers hack away carelessly at their code and throw it to QA letting them test it (often the first test the code encounters) and just wait for the bug reports to come, in other times QA personnel start filing bugs that aren't defined in the specification, and start treating programmers as "the cretins who introduce bugs". Entire wars erupt between these two sides of development.
As if to add fuel to the flame, an article claims that quality assurance is one of "10 technology skills that will no longer help you find a job":
5. Quality Assurance Specialist and Managers
Hiring professionals in the Dice survey placed Quality Assurance (QA) on the "low priority" side of the ledger. Do not expect this to change. These days, the tech industry seems to be following Google's lead and turning everyone into beta testers. Users are the ultimate quality assurance staff - and they don't get paid! [Brian Hall - 10 Technology Skills No Longer In Demand]
While the absence of testers dedicated to making developers cry seems like a good idea to software developers, the lack of staff dedicated to testing presents its own problems. There has to be a set of "fresh eyes" that will not see an application under the narrow focus developers tend to have. Implementing the "users as QA" principle also requires the very expensive overhead of analytics modules that are necessary to track user actions that caused a particular bug. Not to mention that the analytics stuff would probably have bugs on its own.
While I tend to dislike the traditional definition and role of Quality Assurance, I believe there are three areas QA professionals can focus on to keep themselves relevant in the industry: test automation, user experience, and domain expertise.
Test Automation - There is enough tedium in the QA process that is worth automating. Repetitive tasks should be relegated to a script, which frees up QA to focus on writing test cases and measuring the performance of applications instead of random bug hunting. Besides, even if you had access to thousands of cheap testers, repetitive tasks are best done by the very machines applications are tested for. There are countless tools dedicated to this effort, and many of them allow you to address Michael Hunter's You Are Not Done Yet Checklist [PDF] in an automated manner.
User Experience - If there's an area that could not be efficiently tested via automation, it would be the visual appeal and intuitiveness of an application. Quality assurance professionals that focus on usability, user experience and design, not just in terms of visuals but also in terms of workflow and ease-of-use will be very valuable in producing software that will have either a lower after-sales support overhead for enterprise software or mass appeal for commercial apps.
Domain Expertise - Many times the breaking point of software projects is the ability of a particular piece of software to follow specific business rules or accommodate new pieces of regulation that the app should comply with. Quality assurance professionals who could gain domain expertise and gain greater insight on an application's impact in the business side of the equation would be immensely valuable. Even in outside organizations working within that same domain.
Just as software development has already evolved far from being a solitary effort running punch cards and checking if the desired output is achieved, quality assurance has to evolve beyond merely using an application and reporting any bugs found. A QA professional possessing at least one of the above skills beyond normal tester job descriptions would be invaluable to any organization priding itself with shipping quality software.










