Software Testing in 2020 and Beyond

With over 35 years of experience in software quality and testing, I’ve seen firsthand how the testing industry has evolved and continues to evolve as technology becomes more and more advanced.

Recently, I had the opportunity to chat with Tom Cagley, host of the Software Process and Measurement Cast, about the future of the testing profession. Our conversation covered the gamut from automation and AI to how leadership’s perspective is a key indicator of an organization’s testing strategy. Below, I’ve summarized the major points that we covered.

Testing as a profession isn’t going away, but it is shifting.

Job security is top of mind for a number of testing professionals. In the short term—the next five years or so—testing as a profession will not be going away. But, if you’re looking at the next 15-20 years, you may want to consider a different career path. Because one thing is for certain, we will continue to see the shift away from people performing manual tests toward coded test automation, and from coded automation to scriptless test automation.

For example,  Jason Huggins, who developed Selenium and was the keynote speaker at Quest Conference 2019, is using robots to perform automated mobile testing. We can also expect to see a shift toward self-generated automated scripts that use Artificial Intelligence (AI) tools.

When it comes to testing, focus less on “who” and more on “what” and “why.”

There’s been an age-old debate of “who does the testing.” If you look back far enough, you’ll see that programmers were the initial “testers” and there was no such thing as a professional tester. Programmers wrote and tested code, and then turned it over to the business for further testing—usually user acceptance testing (UAT). As the process evolved, and business people were more or less hard to get a hold of, a middleman position was created, aka the manual tester.

The “who,” therefore, was less important than what and why something was being tested. And it’s my philosophy that we should adopt this same mindset today. After all, when it comes down to it, anyone perform manual testing—a project manager, product owner, business analyst, or developer—with a proper testing process and tool in place. Not everyone can write code but everyone can test—and agile philosophy of team members being interchangeable.

It is much more important to ensure that we’re testing the right product, and have adequate coverage without redundant testing. Of course, there is no need to have the business test what QA just tested, and QA test what the developers just tested, and so on. That is complete inefficiency.

Continuous testing in a two-week sprint is possible.

I have had conversations with some who say Continuous Testing (CT) every two weeks is impossible; however, we are doing it at SPR. It just requires that certain prerequisites are in place. The first prerequisite is that a user story’s “definition of done” must include testing. It does not matter whether it is manual testing, automated, or a combo, so long as the user story has been tested and agreed to, the work can be considered complete.

The second major prerequisite is that you must have a strong Continuous Integration and Continuous Deployment (CI/CD) process in place to frequently run builds. This way, once code has been built and unit tested it can be deployed and move on to other levels of testing. In conjunction with that, user stories should be broken down into more granular definitions so that they can be completed more quickly. For instance, if a user story has a back-end component and a front-end component, don’t put them together. Start with the back-end component so that it can be coded and a level of API testing performed, and then get to the UI aspect. The key here is to complete testing as close to the point of code being deployed as possible so that if issues arise, the code will be top of mind for the developer.

The third major prerequisite is to get testers involved in every single aspect of an agile sprint, not just daily standups to report status. Testers should be involved early in sprint planning to ensure that a user story is broken into small enough components, is indeed testable, and that there is a common definition of done.

Leadership’s view of testing is key.

Testing should be viewed as a necessary component of the software development process that helps to mitigate risks and customer experience issues. It is disheartening and demotivating to see testing cut out of or crunched at the end of a project because it causes quality to suffer. We often see that the emphasis placed on testing by the CIO/CTO trickles down to different levels of managers, scrum masters, and so on. Unless leadership adopts a pro-testing mindset, the entire organization will fail to see its value.

Automation is amazing, but it is not a silver bullet.

I would guesstimate that the industry currently operates at about 30% automation versus 70% manual testing. Everybody wants automation because they think it is a silver bullet, but they fail to recognize that it is an investment—you invest in it, you build it, and you have to maintain it. Interestingly, it’s that last point on maintenance that most leaders and managers do not realize. For automation to be effective, it requires careful, ongoing oversight and support. It is not an easy cure-all.

Stay in the know. And network, network, network.

It’s important for testing professionals to be engaged in continuous learning and keep up with best practices and future trends, both for the sake of bringing these new ways of thinking to your own organization and to support your own career path. Things are constantly changing and evolving, and it’s vital to remain current. Tune into podcasts, articles, blogs—anything that will help you to invest in yourself.

It’s also beneficial for testing pros to get involved with local professional groups as a way to connect with one another. In Chicago, for instance, there is the Chicago Quality Assurance Association (CQAA). I recommend that you get involved with a local group one in your city, and if you do not have one in your city, start one! Schedule a meetup with your peers. It’s a great way to grow and learn about best practices beyond what you know and use in your own company.