The QA Engineer Role Is Changing To Keep Pace With Automation.

Use of open-source software in your code may not seem revolutionary today. After all, millions of people contribute to developing software on platforms such as Github.

But it wasn’t always this way.

A majority of software used to be proprietary. There were some open-source projects such as Linux and Apache, but a lot of code was written internally. This led to an organic specialization among engineers. One engineer knew more about the front end, another about the backend, and so on and so forth.

Today, the rise of open-source software is changing this dynamic.

Companies now have access to a lot of open-source code — if the software license of the code allows it. So an end-to-end system can be completed in a few months, instead of an entire year.

Shorter timelines, improved access to code, and increased system complexity are also altering the nature of how engineers work, especially the Quality Assurance (QA) team.

Here’s why the change happened and what to expect in the future:

Before test automation, QA engineers had to do tedious testing.

The process for creating and testing an end-to-end system was incredibly manual.

Let’s use an app as an example. The engineers would begin developing features and components. QA would then test the features in the app with the backend. They would comb through it piece-by-piece to make sure everything was in good working order.

But they didn’t only check individual components. QA also had to do integration testing, checking each piece in combination with the others and making sure all aspects worked together.

So components A, B, C, and D were tested individually and then put through integration testing. All components would then be tested together, which is known as end-to-end system testing. And automating the integration test and system test wasn’t always possible.

That work required a very large QA team and was quite stressful.

While much of this process remains in place, open-source software has changed how QA operates.

I’ve always believed that you have to be somewhat of a pessimist to work in QA. You have to assume the system isn’t perfect and there is a fault somewhere.

Not only should you expect there will be problems, you have to anticipate where those problems will be — and then actively search for them. That mentality hasn’t changed. But the work required to discover those issues has.

Testing

Today, engineers write open-source code and create automated processes for testing that code. So, many of the traditional tests performed by a QA engineer are now done by the developers.

Small mistakes are caught early and corrected before QA gets involved.

If something slips through, there are many open-source tools the QA team use for integration and system test. Ultimately, the improvement in process and automation leaves QA with more time to look at the system on a holistic level — and attempt to break it in different ways.

Systems Thinking

New systems are extremely complex, so QA has shifted its focus from checking individual components to understanding the entire system. Which is good, because it’s not feasible for QA to test every piece of software anymore.

Instead, QA is responsible for testing different parts of the system to understand how they work together. They’re examining how two products integrate and where the problems with integration lie.

It’s a higher-level, systems-based approach to the QA role.

API Testing

Many SaaS companies now offer an API for their application or service, and QA is charged with testing it. These tests are easily automated, which enables the team to catch issues with every update to the software.

Release Management

In the past, a company like Microsoft would release a new version of their product every two or three years. But every few months, they would have a major internal release where all of the code would be packaged into an image. That image would be given to the QA team for testing. They’d find any bugs in the image, and the software engineers would fix them. The whole cycle could take a few months.

Now, companies are increasingly using a continuous integration and continuous deployment (CI/CD) pipeline.

This means every time a software engineer makes a change, it goes into the system and automatically creates a new image. Automated test cases run immediately on that image in a sandbox environment, flagging any issues for the software engineers to fix. QA doesn’t really have to be involved. Software can be released or updated multiple times a day, rather than once every few months.

For example, Facebook is constantly trying new features, so they push releases multiple times a day. The robustness of this system depends on how good the automated tests are and if they cover most of the code before the release.

The reason CI/CD works is because QA no longer has to test every single component, every single time.

The role will continue evolving, giving QA engineers more power within a company.

The coming years will see an increase in automation, meaning QA will be spending even less time on manual testing. Instead, we’ll continue to see more integration testing and a larger focus on how products work together.

QA engineers will take on increasingly challenging and important issues such as handling system outage, disaster recovery, and security.

Some companies are already seeing this shift.

For example, Netflix uses ‘Chaos Monkey’ software that randomly goes in and shuts down part of their production system. Essentially, the QA team breaks the system randomly to see how it behaves and how they can make it better. Tests like this are very complex, but it’s what QA will be focusing on as automation improves.

Integrated, advanced testing is going to bring QA one step closer to the software engineers. The lines may even begin to blur when a QA engineer is able to write parts of the software — eventually freeing up the engineers to focus on other issues.

Overall, this shift in roles will also give QA engineers more power within the company, as they move from working on tedious testing to spending their time resolving high-level issues.

Thanks for reading!

Want to learn more? Get in touch with the Chronicled team here.