QA Automation or Die

Last week (5/14/15), TCQAA hosted a presentation in Minneapolis, titled “The Death of Software Quality Assurance: and how are we killing it”, by Ron McClintic. Unfortunately I was not able to attend and am waiting for a ppt download to be available. I am interested because my own sense of trends is that the role of QA is slowly giving way to Business Analysts that do manual testing and Developers that do automated testing. For my own longevity I am trying to move to the role of Software Test Engineer, meaning a test automation specialist. I believe there is a need for this role until enough developers learn the skill.

I just came across an old blog post (3/14/2011) which seems extremely timely, called “I think it is time for QTP to die” by Paul Hammant (https://paulhammant.com/blog/die-qtp-die.html). The basic premise is that tools like HP’s Quick Test Pro (it has a new name now) are based on user actions. I used QTP back in 2004 for a while. It was extremely expensive but was popular because people thought that they wouldn’t need any programming skills to use it. The blog post points out that the way that it works is based on recording mouse clicks and captured typing. This emphasis means that the code must already be developed before the test is created so that the actions can be recorded. The QA tester is generating these tests on their own since the developers and business analysts are done and moved on. So there is little transparency and the QA feedback is very late in the game.

By contrast smaller test frameworks (often open source) like Selenium, focus on the expected behavior of the system under various scenarios. The automated tests can be written as soon as the requirements (Stories) are written and before coding begins. The developer can use them for unit testing so that test feedback is very early. They can be reused after each build for regression testing to identify any new code that breaks previously passed tests, saving much time and reducing risk. Most significant is that the whole team will be interested and involved in the tests while they are being written because it is timely and valuable to them. This is essential for Agile project.

The post makes a plea for QA to gain these more agile skills because they will greatly improve their value to the team, which will also enhance (possibly save) their career. Even though this post is old, I think it is extremely valuable advice for anyone in this profession. I am currently learning to use Selenium with Ruby (RSpec framework) and am excited by it's promise.