Where I work there is increasing focus on test automation. Recent hiring around the quality assurance area has focused on those who can create and maintain automated tests.
Test automation is about source code. So at least some programming skill and experience is now basically a requirement to be hired into QA. Of course there is still a requirement to be able to do more classic manual testing. That is, going to the website, desktop, or mobile app, executing various flows in person, observing and verifying the result is correct and the user experience is smooth. The way forward seems to be dual-hat in QA. Comfortable both in manual testing and test automation.
This tends to blur a distinction between manual and automated testing. It's all testing. The trend in my observation seems toward eliminate the separate test automation teams, the 3 teams doctrine (dev team, manual test team, test automation team).
It also tends to blur a distinction between developer and tester. Going forward it may become that QA/test automation is generally the entry level position out of tech school. From there, the individual will have the opportunity to demonstrate an ability to write clean, maintainable code that works as part of test automation. That person could if interested be offered an opportunity to switch from QA to development.
So I'd see a scenario something like this where dual-hat QA is capable both in manual testing and test automation. While manually testing a screen on the website, a tester notices a problem. The tester files a bug report in the usual way, reporting steps to reproduce, expected result, actual result, screen shots, logs, etc. While the bug goes into the development team, the tester then creates an automated test to demonstrate the defect on the website. The automated test is reviewed and checked into the repo. A couple days later the development team marks the bug as fixed and ready to verify.
The tester goes back to the screen on the website with the latest build. The defect is observed to now be fixed. The automated test case runs automatically. The automated test switches from red to green, confirming that the issue is now fixed. The defect is closed. The automated test remains in the repo and runs in the overnight regression test run to help ensure the defect does not accidentally reappear in the website.
What of the classic manual tester?
I think the traditional non-coding manual testers will be around for some time. There's plenty of work in that area. They are not yet an endangered species. Not every company has fully embraced dual-hat QA. Anyone who has a job manual testing is probably pretty safe.
Perhaps it will start to be felt in mobility if you lose your job or seek to switch jobs. For example where I work it seems all new QA hiring now requires coding and test automation ability. So by that definition any manual testers here might have a harder time getting hired by today's standards, even though they are good at their jobs and make important contributions to successful product releases. So I suspect QA hiring across tech will increasingly require the ability to fire up Eclipse, Visual Studio, whatever IDE, understand code, and write code.
To the existing manual tester there are some paths forward. Be really good at manual testing. Consider reinvent as a business analyst, product manager, project manager, or into management. Also if possible fire up the tools and learn/relearn to code and embrace test automation.
What is the future of Development?
I think that will also evolve. It's worth its own post. I should think about it some more and may come up with something.
