Sometimes, (test) automation professionals are approached with a completely new task for automation. In this article, I try to give you a guideline and some questions to ask when this happens.

Understand the problem

The very first step to approach such a task is to thoroughly understand the problem to be solved.

This typically means getting feedback from the stakeholders and users who have a pain point that can potentially be solved through automation. It also involves talking to teams who might have had this issue before since there might be some inspiration or even a complete solution that fits the problem scope.

Thoughts on reinventing the wheel

Even if there is already an existing solution, it is necessary to assess if it really fits the problem at hand. It might be beneficial to come up with another custom way that is better suited.

This decision has more factors such as

• How much time do we have to develop something from scratch?
• What is the cost of maintenance of our solution?
• Is it a problem that will not exist anymore in the future (so the solution does not have to be permanent)?
• How well documented is the existing solution?
• How many maintainers does the existing solution have?

If the solution under investigation is open source (or "inner source" in case of company internal development), another approach would be contributing to that existing codebase instead.

Compatibility

If you decide to come up with an individual solution, it is necessary to start exploring ways to approach the task at hand because it has to fit into the puzzle of what's already there:

• It has to be compatible to the existing infrastructure.
• It needs to be usable within the established processes (or it has to be so good that the process adjustments are worth it).
• It needs to be adaptable to the current technologies that are already in use (or again, technology changes might be an option if the solution is outstanding).

Questions to be asked before implementation

There are some very important questions that need to be addressed prior to actually planning and implementing the concrete implementation tasks:

• Is the task even worth automating or is it a one-off activity or a very complex process?
• What technologies are in use such as
  • Cloud providers
  • CI/CD systems
  • operating systems (plus needed extensions and capabilities)
  • Containers
• What kind of solution should it be, e.g.
  • CLI tool
  • REST API
  • Web based application
  • CI server plugin
  • Custom Github runner
• Who is the main user of the tool or service?
• Where and how should it be integrated?

To BDD or not BDD?

Developing a solution with behavior-driven development (BDD) can be a great tool to ensure that all involved parties have the same understanding of a solution upfront. This is done by discussing each requirement together with members of all stages of the software development life cycle and documenting it in a ubiquitous language that everybody understands in the same way.

This approach can be way out of scope, though, depending on the extent of the task. Also, if the solution is for a specialized role and does not need to interface with other teams, this process is not necessary.

In any case, it should be documented well!

Proof of concept

If a new technology is required that the respective team has not used before, a good way is to create a proof of concept that can be presented and reviewed by fellow developers, QA and the eventual users of the solution. This is great for finding out if a technology is feasible and if the solution is on track. Here, it can also be beneficial (and even more fun) - depending on the scope of the project - to have individual team members do more than one POC with different technologies at the same time and present their findings. This allows comparing the pros and cons much better.

Architecture and testability

It is also very important to think about the architecture and testability of a software problem early on. Generally, the better testable a solution is, the cleaner the code. Techniques like test-driven development (TDD) can help a lot here.

Unit tests are absolutely crucial even if no TDD is done. They act as a safety net and ensure that the project can be maintained and extended later without fear of breaking other functionality.

Also, integration tests should be in place in case the automation solution has or is a dependency of other tools, services and APIs.

In terms of testability, it is also helpful to have an easy way to test the solution frequently in a lifelike environment that is as close to the production environment as possible.

Collaboration

Code reviews are an important asset to get feedback on code quality, used design patterns and coding guidelines. By the way, a proven practice in code reviews is to not only point out problems but also comment on things that were done well. This is highly motivating and results in a better work atmosphere.

This thought also be extended by doing pair or even ensemble programming session, depending on how complex the problem is. This enables developers (or other roles that pair with developers) to be directly involved in the development process. These practices need to be communicated and understood well so that everyone is on the same page and nobody feels caught off guard.

Documentation

Before, during and after development, it is good practice to take notes, draw diagrams and comment parts of the code that might not be easy to understand directly. These are then typically converted to a readme file, changelog and/or wiki page which should be updated whenever there are changes. Here, the semantic versioning convention (SemVer) is a proven technique to communicate if code updates are backward compatible or introduce breaking changes.