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.
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.
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
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.
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:
There are some very important questions that need to be addressed prior to actually planning and implementing the concrete implementation tasks:
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!
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.
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.
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.
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.