Why should my team start automating?

Maybe you’re still gazing at this title, a bit suspicious and wondering to yourself, “Start automating? What does she mean, we’ve been doing it for ages!” If that’s the case, congratulations, you’re on the right path! Yet, you might find this article useful to remember the old, dark days and sigh.

But for those who haven’t yet found the right moment to start, or even don’t see the value, I hope this story empowers you to join the bright side of testing and transform the initial question, “Why should my team start automating?” to “Why haven't we started automating yet?”

Bumps in the road to automation

“It’s too expensive and brings no benefit.”

Correct, automation will imply a big initial investment. It’s necessary to dedicate time and people to find the tool that best fits the framework and programming language your team is using. Of course, your team will also need proper training as to how to use that tool and how to design simple, maintainable tests.

Moreover, it’s not possible to provide an exact ROI calculation, since automation brings test coverage that wouldn’t be possible to achieve and handle manually. Think of a test regression suite for a project with multiple interconnected features. During the first few iterations, it might be possible to manually run all acceptance and regression tests, but the more iterations, the bigger the regression suite would be. How long would it take for that suite to become unmanageable? Consequently, how long would it take for the team to give up on those tests?

“We don’t have a dedicated specialist on the team.”

Well, it’s not strictly necessary. Adopting Agile practices means not only there is no room anymore for a dedicated Quality & Productivity team working on demand at the end of different project releases, but also that quality becomes a whole-team effort. The entire team needs to adopt a quality mindset, as everyone is responsible for the quality of the product. Whether you are a developer who has no experience in automating tests or you are a manual tester without a programming background, never fear. It’s a team responsibility, and there will be colleagues on the team who will be able to help.

“But we don’t know how to automate!”

Take a look at the beginning of the previous section. Do you see that “It’s not strictly necessary” bit? That’s because although all the team might agree on learning automating skills, it still may be a good idea to bring a quality expert to coach and support the team, helping to adopt the new practices and making sure those first steps go in the right direction to a solid, maintainable and easy-to-understand automation test suite. A Quality & Productivity Engineer will know the team is ready when automation has become an assumed, natural process.

“We don’t have time…”

It’s harder to take on new habits when there are old ones to fall back on. If the team isn’t given sufficient time to get up to speed with automation and, later on, design and implement the automated tests during each sprint, they will go back to old practices. Automation will be skipped as a result of choosing the lesser of two evils, and some exploratory testing will be done, at most. Best case scenario, the automation tasks are resumed in the following sprint, with the delivered business value reduced. Worst case scenario, deliverables seem to remain standing without pertinent testing, so the team falls for the misbelief that they are not necessary.

Tests with benefits

At this point, there may still be some skeptical readers thinking that if their software is simple enough, they can still survive without automated tests.

Let’s imagine the following scenario: there’s a small application developed by a concrete team that always has enough time allotted to manually test all the progress made during each iteration. Some bugs are found during the testing phase, and few others make it to the production environment, yet the situation is not concerning. How could automation benefit the team?

• Better understand the requirements and build testable code.
• Bring confidence to the code. While in manual testing, the Quality and Productivity Engineer is the one providing this sense of security, with automated testing, this focus is moved to the tests themselves.
• Get early feedback, helping developers to troubleshoot quickly. As bugs are spotted sooner, there’s more time to find the root cause, come up with a solution and redesign the code if needed, contributing to more solid code.
• Eliminate the possibility of human mistakes during execution, since every test is run exactly the same way.
• Decrease the team's frustration. Automation reduces repetitive tasks; consider that the more code is added, the longer manual testing would take.
• Increases test coverage. Think about complex scenarios with a wide range of input data to cover. Most likely, only some of those scenarios will be tested if only manual testing is performed.
• Create living documentation with automated tests. It’s easy to forget to update static documentation every time a feature changes. With automated tests, however, updating docs to include these new functionalities is mandatory.
  

Have I brought you to the bright side of automation? Happy testing and, as always, bring on any questions or comments!