Test automation is not a new practice. Most software teams are trying to automate testing in some way or another, especially as a replacement for long, manual regression testing cycles. If you’re a QA, you’ve probably wondered what this means for your job. In the world of ‘automate everything’ – where do you fit in? Is the role of the QA dead?
Let’s start by talking about the obvious benefits of test automation.
One of the first benefits people see from test automation is that it drastically reduces the time it takes to test a system. You write a test script once and it can be run over and over in less than a minute, even in parallel with other tests. Teams that automate their regression test suites soon find that they can do most of the regression testing, that previously took days, in just minutes. Teams can get feedback faster and more often, so bugs are found sooner and code can go to production faster.
Humans make mistakes. It’s part of our nature. A manual tester, when going through the same test case for the hundredth time, may very easily miss a step or forget a scenario. You might forget to document a particular scenario. Automated tests are a form of living documentation. They do what they say they do, and they can do it over and over again with almost no deviation.
These benefits are great and really help teams build quality into software faster, but they are not actually the most powerful things about test automation.
At the 2015 OnAgile conference, Elisabeth Hendrickson made a very useful distinction when she described what automated tests do: they check functionality, but checking alone does not add up to testing:
Automated tests are dumb. We write them to check scenarios that we already know about. They run and check whether the system still does what we expect it to do in those scenarios. Where do those scenarios come from? From an understanding of what could go wrong in a system. Who understands the system? You do.
There are two things that humans outperform computers at every time – creativity and learning. These two elements make up what we call exploratory testing. As we explore a system, we think of unusual ways in which we can interact with it. As we do this, we observe how the system behaves. Hendrickson points out that these observations we make help us learn about what we should test, which will inform the experiments we make the next time we test something.
Automated tests check your system for bugs that you already know could exist. It is manual exploratory testing that finds the bugs you don’t know about. Automated testing frees you up to do more of this kind of testing, instead of the rote checking that you used to do. Every time you find a new bug, you could automate a check for it. That way, you won’t have to check for it manually again and can rather focus on finding other vulnerabilities.
Your job title is QA, but you are often referred to as a tester. You do so much more than test, though. What does QA stand for? I’ve heard a few different answers to this question and they’re all correct. They each represent a different facet of this vital role.
The term quality assurance is a response to the old job title ‘Quality Control’. The term Quality Control comes from the manufacturing industry. A product goes through a whole production line before reaching a Quality Controller. They check the product for flaws. If it is flawed, it needs to be thrown out or fixed. If it’s good, it goes to the consumer.
Toyota decided to do things differently. They used what we call Lean practices to build quality into the process of manufacturing vehicles. The aim was to reduce the number of faulty products by increasing the quality in every step of the manufacturing process.
One facet of the QA role is to help build quality into the process of software development. You don’t want to be a Quality Controller. You don’t want to have to turn new features away because of poor quality, so you help make it easier to produce quality features. You can do this by helping to write automated tests for the scenarios that could trip up a development team. You create a safety net – a way for the developers working on a feature to know whether it passes all the tricky scenarios we know about. You can write these tests with a developer, even before development begins.
Writing software is not easy. Some of the complexity comes from the nature of computer programming, but most complexity arises from the world a system interacts with: your system needs to talk to other systems which are hard to understand, users do unexpected things, and networking and computer infrastructure fail in unpredictable ways.
Part of your role is to help the team building this software to understand how to cope in this world. It is your job to help figure out what the right things are to take into account. You can save your team time by asking the right questions early on. Automation frees you up to dedicate more of your time to helping the team prepare for work – helping you move quality even earlier in the process.
Tip: Couple this with your Quality Assurance role, and automate tests for each of the test cases you’ve discovered, so that the developers have an automated way of checking whether their code satisfies the test cases.
I like this one. Quality is not the sole responsibility of a QA. If the whole team doesn’t take quality seriously, the release of new features will always be delayed (or worse, buggy software gets released). Your job is to help the whole team own the quality of the work. The best QAs I’ve worked with have been able to inspire the whole team to care about quality. They work closely with others to share their knowledge and prod others to pick up habits that help improve the quality of their work.
Tip: Couple this with your Quality Analyst role and help everyone’s quality awareness stretch to include thinking about which work to do and how to approach it.
You’re not redundant. On the contrary – test automation means that you are more empowered in your role than ever. Automation can take care of the repetitive checking you’re often stuck with. This will free you up to use your creativity to explore new ways to test a system. You’ll be able to spend less time as a tester, and more time being the Quality Assurer, Quality Analyst and Quality Ambassador that your team needs.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.