The Waterfall development methodology has gradually been supplanted by and, to a degree, merged with Agile. The once sacrosanct division between development and testing has been diligently dissolved to accommodate the small development/testing/product management groups that Agile promotes and thrives upon.
A side effect of this has been the apparent disappearance of software QA as an organizational entity. Note that this includes both real QA, i.e. Quality Assurance that improves the production process itself, and Quality Control largely encompassing testing which is enveloped by the same QA label. Where there was once a strident effort to take testing from the code programmer and hand it to someone who was reading from a product specification, there is now the desire to merge testing back into development so as to promote even more rapid release scheduling.
Under the separation of development and testing, manual test work comprised the bulk of product verification. This front-end functional verification was viewed as the primary task of QA with such efforts as test automation, load/performance testing and back-end validation as being the province of a small group of development engineering specialists. An inquisitive user could be trained in how to fill out a bug report and put into productive manual test work very quickly with a more experienced test lead available to assess their results.
As the saying goes, that was then – this is now.
Quality Assurance Roles are Changing
Test automation has marched hand-in-hand with the growth of the Agile development methodology. The rapid turn-around of product releases absolutely demands that quality verification become as seamless, direct and, above all, as fast as possible. Testing as a stand-alone effort, structured into ranks of manual testers reporting bugs to test leads for assessment is being reduced into placing the test person in a chair next to the programmer with the pair working hand-in-glove.
The impact of this change on the ‘test person’ has been profound. Development managers, who are interviewing quality personnel, are looking for basic to moderately advanced coding skills combined with business process understanding. Skill specialization is being compressed back into every member of the technical staff becoming the proverbial jack of all trades.
Manual Testing has become User Acceptance Testing with the ‘testers’ being knowledgeable system users rather than people with basic computer use skills reading test plans. The code tester has become a test engineer who is familiar with command line operating systems (read Linux) and a working familiarity with Windows, OSX, iOS, and Android. This individual has to be prepared to talk directly to the development engineers in their own terms from an understanding of what they do and how they do it.
The skill sets described above are what is expected of development personnel and, indeed, the most highly desired QA engineer can absolutely do the developer’s job. The distinction is that the QA engineer needs an additional set of analytical, assessment and extrapolation skills over and above the development engineer’s.
All this has made the recruitment of QA personnel a genuine challenge.
The Future of Software Testing
The culture of software development is bound into a better/faster/cheaper trajectory that has an exponential curve. Moving as much of the testing process to automation as possible is becoming essential to maintaining Agile sprint velocities.
Software QA personnel will have to live and breathe the Agile philosophy including its principles, tools and measurement metrics. Testing against detailed specifications with any kind of separation from the development process is a matter of history. The test engineer will have to be able to learn the operation of the system ‘on the fly’ and document tests through defect reports, corporate wikis and comments blocks in automated test scripts.
The most visible harbinger of the future may well be the increased use of artificial intelligence in parsing code structures to create tests cases and automated scripts without human intervention. These ‘hands-off’ systems still have significant blind spots but the trend towards them is obvious and growing. The paradigm of machines testing machines has a sort of elegance that makes it very nearly inevitable. All that being said, software testing is here to stay. It may be more automated but when you are in the business of making software products for people, you need people testing those products.