Busting Test Automation Myths In Agile Projects: Part 2

Raluca Vartic | May 11, 2021 | 5 Min Read

In part two of this series, Myth Buster Raluca Vartic, continues to tackle the value of test automation in agile teams working in the healthcare space.

In part one of this series, I looked at a couple of test-automation myths agile teams have floating around. I also explained why these myths needed to be busted.

Truth is, agile methodology, coupled with automated tests, enable frequent releases, which can be used by healthcare companies to remain attuned to user and patient needs. And without compromising quality in products—especially important in the regulated domain that is healthcare.

As we see a greater push for healthcare products that entail human-centered design, having repeatable tests that ensure the stability is maintained for each release becomes even more important.

Test automation makes it possible to continue ensuring a high standard of quality in the digital healthcare space.

But that can’t be done unless we bust test-automation myths plaguing agile teams. Here are a couple of myths that continue to make the rounds among some teams.

Myth 1: Test Automation Is Not My Responsibility

Among agile teams, this myth can take many forms. Perhaps you have heard statements like:

  • “I am a developer. It is not my responsibility to write tests.”
  • “I am the test automation engineer. Stay away from my code!”
  • “Regression testing is the responsibility of another team (the regression team).”

Agile teams are accountable for creating releasable iterations of a product. Creating and maintaining testable code should also be a team responsibility.

In order to illustrate how damaging the above statements can be to a team’s performance, let’s compare two scenarios. In the first scenario, the core team has no accountability for test failures, while in the second scenario, the entire team collaborates in defining and refining the test plan.

Scenario 1: Outsourcing Accountability

In this scenario, the agile team has no accountability for test failures. When tests are failing, the regression team investigates the root cause. The members of the regression team have to familiarize themselves with the new features developed by all teams, and then determine whether the failure is caused by a defect.

Often, the regression team has to make changes to existing tests so that the tests continue to be appropriate for the latest version of the product. When this happens, the agile team never becomes aware of the impact its changes had on automation. There is no immediate opportunity to learn how to prevent such test failures in the future, make maintenance easier, or improve the overall process.

This is not a pretty picture.

Test failures are no longer exceptional situations and accountability is unclear. Tests cannot be fixed as the product evolves, the investigation of failures is time consuming and there is a negative impact on quality.

There will also be a negative impact on the cost and on the schedule. Defects found later in the development cycle are more costly to fix.

But there is a better way.

Scenario 2: Team Accountability

Life on a project when the entire team collaborates in defining and refining the test plan is downright peachy compared to the first scenario.

In this scenario, agile team members reflect on the best approach for testing a new user story, including what can be tested at a granular level by unit tests, and what will need to be covered by higher level tests.

Test failures that are due to changing features are caught and fixed early, within the agile team. This means maintenance cost is minimized.

I’ll repeat that for those in the back: costs remain low when test automation remains within the team.

Plus, the team is aware of testing efforts, and can contribute to improving the process. It is easier to maintain test suites with 0 failures, allowing for a quick reaction when failures do occur.

Myth 2: I’m Going To Lose My Job To Robots

The fear is real among some testers. But is it substantiated? Short answer: no.

Test automation is becoming a widely adopted practice and exciting advancements have been made in the field. New tools are becoming available, some employing machine learning or artificial intelligence to assist with testing.

Not everything, however, can or should be automated. Teams can use tools like the Agile Testing Quadrants to plan testing activities.

There will always be a need for exploratory testing, usability testing, and problem solving. We can let automation take care of the boring, repeatable part of our work.

Automation is complementing, not replacing manual testing and human judgment. Exhaustive testing is not possible. Automation allows testing to be more efficient, and it gains teams more time for testing activities that still require human creativity, like exploratory testing.

Final Thoughts

Test automation as an agile team responsibility enables defining and refining testing strategies that prevent regressions, keep execution times reasonable without sacrificing coverage, and reduce maintenance.

Outsourcing test automation to a separate team has a negative impact on quality and the team’s long-term velocity.

On the other hand, teams owning the automation results are motivated to collaborate and continuously improve the testing process.

This collaboration leads to optimized test plans, which in turn lead to automation test suites that stay up to date, stay clean, and execute fast.

If you’re on an agile team, do yourself a favor and take up test automation. You’ll be glad you did.

Get Email Updates

Get updates and be the first to know when we publish new blog posts, whitepapers, guides, webinars and more!

Suggested Stories

Guide to Mobile Application Testing Strategy

Application development for mobile devices has increased immensely in the last decade and is expected to continue growing at a profound pace. This white paper will serve as your guide to creating your own test plan, covering a variety of testing strategies and considerations for when they should be used.

Read More

Guide to Creating Engaging Digital Health Software

This guide shares our knowledge and insights from years of designing and developing software for the healthcare space. Focusing on your user, choosing the right technology, and the regulatory environment you face will play a critical role in the success of your application.

Read More

Accelerate Time To Market Using Rapid Prototyping

In this webinar, you will learn how to leverage rapid prototyping to accelerate your products time to market in one week, agile sprints.

Read More
Macadamian has been acquired by Emids 🎉
This is default text for notification bar