Sunday, July 30, 2006

Quality Assurance

The current state of Quality Assurance is disappointing.

QA has become (or always was) a ritual that is performed, but the actual value of the act has been lost. Someone needs to (re?)define what QA means, based on the value it should provide. Then, from the definition of QA, we can determine what skills are needed to perform QA work.

Classic quality assurance, in my experience, includes a team ranging widely in skill levels. Some testers have vision, can write tests, find root causes for problems, etc. On the other end of the spectrum, I've seen testers who provide zero value. Their daily tasks include running the functional/acceptance tests written by someone else and that's it. The problem isn't the broad range of skills among testers, it's that there seems to be no minimum level of skills required. I have actually been told "I wasn't good enough to be a developer, so I decided to do QA." And, I've seen entire QA teams composed of people who simply didn't fit anywhere else. I completely disagree with this approach. Quality assurance is a job equally as challenging as development, analysis, etc and the people performing the testing need to be just as talented.

We should base our definition of QA on the value it can provide. Companies believe that the QA ritual must be completed before going to production; however, they rarely define QA tasks beyond stating that the application "must be tested." Therefore, I believe QA doesn't need to conform to the classic approach to satisfy those requirements. I would like to see the definition of QA activities include unit and functional test analysis to ensure proper coverage (including adding new tests where necessary), writing new acceptance tests with the business, and automating roll-outs to new environments. I'm sure there are more tasks that fit, but those are the ones that come to mind first.

In the past, development was revolutionized by adopting testing practices, it's possible that testing could achieve the same results by adopting some "development" practices. Because these tasks highly align with development tasks the teams could work very closely, learning and helping each other. This collaboration could produce higher quality standards in the future of software development.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.