The Ecosystem of Test Automation: Gardener

How to become a role model of quality

Anaïs van Asselt
deTesters
Published in
6 min readJul 14, 2020

--

The ecosystem of test automation; a world with lots of aspects that impact test automation. Aspects that must be taken into account to ensure sustainable test automation. The gardens with automated tests are central and need to be kept green. This is ensured by the gardener of test automation. A good gardener observes the climate and environment, digs in technology, plants quality, weeds out flaky tests and anticipates on the ecosystem.

This article examines the role of the gardener and how it is influenced by the ecosystem. How other areas of expertise can help to maintain test automation and ensure quality in a fast-changing world. And the required skills to continue achieving these goals.

A gardener of test automation often starts out as a tester with a great interest in technology. Like me. During my first assignment I really enjoyed digging deep for bugs using SQL. It wasn’t long before I was automating tests using Cucumber, Java and Selenium WebDriver. A new world unfolded, and soon I realized that test automation is so much more than learning a language or tool, it is about ensuring quality.

Impact of an ever-faster ecosystem
I have worked in a variety of agile teams, usually with a number of frontend and backend developers, a business analyst, scrum master and product owner. People with specific roles and responsibilities, the boundaries of which I see blurring over time. And I think that’s a good thing. We need to be increasingly flexible, so that we are no longer indispensable and can continue to add value in short iterations.

This phenomenon has quite some impact, especially on the role of test (automation) engineers (later on: testers). Would this role become redundant in an agile team? There is not always something to test, and everyone can test, right? Two companies I know thought so and removed the testers from all teams. After a while, they came back to this decision, because the quality of the software fell noticeably. Perhaps the role of tester was no longer necessary, but the quality expertise was clearly lacking.

From role to role model
I believe we move from role to role models. Everyone brings their own expertise, is a role model of that expertise, and extends this knowledge by learning from the other areas of expertise within the team. I am a role model of quality. I ensure that everyone in the team feels responsible for quality, rather than being the only one responsible for quality.

My goal as a role model of quality is to integrate quality in the software development process. In order to achieve this, we need to communicate, learn, challenge and collaborate with all areas of expertise involved in this process. I roughly divide them into business, development and operations*.

Learn from other expertise to optimize test automation and to integrate quality in the development process

Get educated in order to educate
Time is very valuable in an agile team. We need valuable and fast feedback on the software and its changes. This means we have to make choices what to test and where. Within agile teams I learned a lot from other areas of expertise, which proved to be very valuable while making these choices. Three simple questions gets you started:

  • Business: what is important?
    Learn what user flows are most crucial and important from the first hand: the business! There might be multiple types of users accessing an application with different perspectives and purpose. Discover both functional and non-functional expectations. All of this is valuable input to determine the priority of the design and implementation of test automation.
  • Development: where is the complexity?
    The expertise of developers lies in the implementation of the software solution. They understand the architecture, the complexity of different applicants and the connection between them. Useful information since the most complex parts of applications have the biggest chance to break. Pair programming is a great method to learn more about the technical implementation. It can also inspire to better implement your automated tests. At the same time, you might inspire developers to improve the quality of their tests and/or code. A win-win-win situation!
  • Operations: what services/calls are used most?
    Only the business can speculate what is important and development can predict where the greatest chance of failure is. Operations tells us the real story. The real numbers of users, what their behavior is and where actual bugs occur. Very valuable to learn from, but for me still a lot of ground to explore.

Using the combination of importance, complexity and actual usage to define what and when to test is definitely not new. It’s based on the old but gold method of product risk analysis. Once I split up a huge and slow automated test set based on risk. The smaller high/medium/low risk test sets gave much quicker and more valuable feedback. This method is also very suitable when integrating small test sets in different pipeline builds. The result? More effective and efficient test automation!

The quality expertise
Ensuring sustainable test automation and integrating quality in the process is quite an assignment and requires skills. I experienced the skills below as necessary:

  • Be context driven
    The organization, people and application landscape have impact on test automation. Observe this ecosystem and learn from other areas of expertise to find the best suitable test automation approach. Be open and dare to look beyond the language and tooling you have experience with, there might be better options for your context.
  • Be critical
    Use your knowledge about the context to challenge the business, developers and operators. Ask critical questions during refinements to clarify the scope of work, both functional and non functional. When this is unclear, the impact is often underestimated. Once I experienced that a frontend solution had to be completely changed, because accessibility was not taken into account.
  • Be technical
    It’s not simply about having experience with language X or tool Y. It’s about the big picture, understanding abstract concepts like object oriented programming and design principles. Knowledge of version control and pipelines, which is very important to integrate tests in the automated development process. This enables the ability to quickly learn new languages and tooling to allow quick adaptation to the context.
  • Don’t be indispensable
    Many times I have experienced that test automation frameworks are replaced for a new solution. And with me, unfortunately, many other colleagues. Often the replaced solution is not even a bad one. The knowledge is simply not transferred, and unknown means unloved. Make sure other people understand the approach and implementation, so that test automation can be maintained. It also stimulates one way of working since one tool can result in ten different implementations.
Do you dare to test in production, like Chuck Norris?
  • Be fit for future
    The shift left movement is about getting fast feedback on software to avoid bugs in production. However, there seems to be a tipping point with accelerating development processes and new disruptive technologies. There are high performing companies with such short throughput times, that fast feedback becomes less important. After all, a bug can be reversed very quickly. The focus shifts right from automated testing during the development process to ‘testing in production’. This means a greater need for collaboration with the operations expertise to explore test automation and integrating quality in this area.

The gardener of test automation strives for sustainable test automation and integration of quality in the software development process. The gardener is a role model of quality and ensures that everyone feels responsible for quality. Being a gardener requires skills. Learn from other areas of expertise to optimize the added value of test automation. Be context driven, critical and technical. Avoid being indispensable by sharing knowledge with your team and other testers.

Can you dig it? Yes you can!

  • In certain contexts, other expertise like security might be just as important.

🌱 Want to read more about the Ecosystem of Test Automation?
Check out my next blog; focus on the test automation garden. Concepts and guidelines, but more importantly how to apply those in practice to ensure a sustainable test automation garden!

--

--