This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
At least once a year, I see a presentation at a software conference proclaiming “Testing is Dead”. The speaker talks about modern software development techniques such as test automation, micro-services, continuous integration, delivery systems, production monitoring systems, and build rollback capabilities. The presentation will suggest that in the future, modern software development techniques will make testers obsolete. Shortly after, the testing world has a collective existential crisis. Testers wonder if they will still have a job in 5 years’ time, or if their skill set still valuable. Contrary to the skepticism, six months later there has been no major change.
Testing is not dead, but the role is changing. What does the future look like?
Testing on The Coasts
A friend of mine works at a company in Silicon Valley. This company’s culture is built on radical collaboration; it is rare for a code change to be worked on by one person alone. The programmers here work in pairs. They begin the development cycle by looking in the tracking system, where the work is prioritized. The most important piece of work is placed at the top of the queue. They usually start new code changes with a test. This is usually a small piece of code that helps to design and refactor with less worry. When it comes to making the code changes, one person is at the keyboard typing while the other has a different role. The second acts like an empathetic back seat driver. They ask questions, guide, and might occasionally ask to take the wheel when acceptable.
By the time their code change can be run locally, automated tests have been developed. As the change is merged into the source code repository, the full test suite has already run and come back green. As soon as the automated tests pass, the finished product is ready to ship to production. This cycle may be completed several times every day.
This methodology stands apart from more traditional ways of working, for example:
- There is no tester.
- There are no hand-offs between roles, no back-and-forth when a bug is found.
- There are no last-minute checks run before a push to production every two weeks.
- Code goes to production daily, or even several times a day, per pair.
Programmers on the team are expected to build layers of tooling to reduce risk, and perhaps more importantly, to be effective at testing software. When these companies do have testers, they tend to float between development groups. The tester will act as a coach and trainer, helping developers build their testing skills. Getting to this point requires architecture, micro-services, build and deploy systems, roll back tooling, monitoring, and plenty of automation. It also requires a culture built around testing, collaborative work and improvement.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Testing in the Middle
My daily life as a software tester is different to my friend on the Coast. I am working on a UI automation project full time. My client has a legacy product built with SQL stored procedures, JavaScript and CSS. Our release schedule is close to quarterly. The development team spends about 10 weeks of each release cycle building a combination of new features, and working on lingering bugs from the last release that need to be fixed.
I am the lone wolf testing department for this company. The combination of our product architecture and technical stack means there are a lot of defects. The defects can be unpredictable and unrelated to the place of the most recent change. My task is to help the programmers discover these defects as fast as possible. That is where the UI automation suite comes into play. Each night, my test suite is scheduled to run against three different test environments. Two of these are used for merging code into the release branch, and one is at the tip of the development branch. Each morning I get a report listing the tests that failed. At this point, my job quickly changes from “automation engineer” to “exploratory tester”.
I start by running the failed test to observe what happened, and then perform typical follow-up testing techniques. I will change data, change my behavior, change environment/browser, or change software version. This is all to help me to better understand, and more effectively report on bugs found. At this point I’ll talk with the programmer that might know about this problem. They might fix the bug now, or not. Once that hand-off has been made, I’ll either move onto the next bug investigation, work on refactoring some tests, or build new tests. My mission varies day-to-day depending on where in the release cycle we are, and what sort of changes are being made.
Most companies seem to work in a similar way. They have skilled software testers and developers; the main challenge is improving efficiency and releasing more often. They aren’t working with the hottest technology, or debating which JavaScript library they want to jump to next. They are making software products that many customers depend on to get work done.
The Future of Testing
We have companies to the left and right (often startups) experimenting, and trying new development strategies that don’t always involve a professional software tester. In the middle, we have large companies that build the software that the country runs on, all of them working to increase their delivery cadence from quarters to weeks. They are using older development methods, and making the software that many people use, for industries such as health insurance, financial services, and automotive business.
Software development changes very slowly. The agile manifesto was signed in 2001. There are still companies undergoing agile “transformations”. There are also companies that think they have transformed, but have completely missed the point. A future without testers is a complicated extension of the original agile vision. This future involves currently uncommon skill sets, tooling, and cultures built on agile principles. The struggle is real, even after 16 years.
When contemplating the future of the testing role it is important to consider the future of the testers themselves, as well as the future of the software testing industry.
The most popular question I hear, is whether testers should learn to write code. For me, the answer is “Yes, obviously”. Non-technical testers do not always work dynamically in the sprint. They can participate in planning and design meetings at the beginning, and retrospectives at the end. They can’t start the important task of investigating the software until a developer has written some code, checked it into the source code repository, started a build, and then installed that build on a test server. The flow of work is different for software testers with technical skills.
One project I worked on took about two hours to build, including a full suite of unit tests. After a successful build, a tarball had to be FTP’d to a test server, and then installed. This took more time, and meant more waiting for the software test team. I wrote a script in Bash that would check that the latest build was green, and download the build files to our test server. The script would then perform the install and run a smoke test. No one on the test team lost time if there was a horrible bug that broke the install, or caused the smoke test to fail. If everything completed successfully, we could test a new version seamlessly. I was not a programmer, and still don’t claim to be, but stringing together small bits of code like that has saved me many times.
Technology and development styles change over time. Testers must adjust their approaches, tools, and skill sets to keep pace. I think the future is bright for software testers. According to the Bureau of Labor Statistics Software development jobs are projected to increase by 17% over the next eight years, and it makes sense that software testing jobs will also increase. If I am wrong and the testing role is going extinct, it will be a very gradual death. For the people out there worried, I’d suggest working on your technical skills. If you’re still testing in 5 years, you’ll find yourself more skilled and more valued.
