English | EN 
Software automation takes time. It takes time to investigate the to-be-automated system, learn how it functions and how it can be programmatically operated. Maybe you have to install some new software to bridge communication between systems, maybe you have to write that yourself. Getting well-versed in the underlying systems and their data pipelines and their toolchain management can be extremely time-consuming, even if you don’t have to know everything about their inner workings.
But after that, automation is a breeze. When you have your library of automation keywords done, automation should be as simple as giving instructions. Of course, you will probably have to write some more keywords as the automation progresses and you encounter some edge cases. And giving instruction might not be as simple as it looks. So, when your library of automation keywords covers all the basic operations of the system, you can start eyeing the real goal – how to describe the process as a series of automation keyword steps.
Translating the process into a series of automation steps might sound like a simple task, but in practice, it can be complicated. Failed automation attempts happen when the developer misunderstands the process requirements. Maybe the automation process failed because the automation didn’t know what to do when an external service stopped responding to its queries? Because the developer didn’t think about that and so, didn’t program the automation steps required.
But what was the real reason for the failure? There never were any process requirements presented to the developer. Because there was no process definition document (PDD).
The process definition document describes the needed automation steps in detail. It is a communication tool for sharing the same vision of the automation process. The level of detail should be such that there is only one way the automation step can be understood. A bad example would be: “Moderator deletes a post”. A good example could be: “Moderator navigates to post detail page. The moderator clicks the ‘Delete post’ button. A popup opens asking ‘Are you sure you want to delete post?’ with buttons ‘Yes’ and ‘No’. The moderator clicks ‘Yes’. The post is deleted and is not visible in the index.” The less there is ambiguity the better.
Different program paths should also be documented. What happens when a user clicks ‘Next’ but the user detail form is only half filled? Should there be a popup saying, ‘Please fill this information’? Visualize the program paths with a flow chart. Try to think about the happy path and then diverge from it. What can go wrong? You can divide possible exceptions into two categories: logic exceptions and system exceptions. Logic exceptions are errors in program logic, for example, off-by-one errors. System exceptions happen when the system has failed or is out of reach, for example, in the case of a network connection failure. The automation must be prepared for system exceptions and have pathways around them, in order to continue the automation process. Logic exceptions must be fixed, system exceptions prepare for.
Having a process definition document makes work delegation easier among the team members. The business analyst could be responsible for translating business requirements into the process definition document that is then handed over to the automation developer. The automation developer gets to concentrate on the technical perspective and the business analyst gets to concentrate on the business perspective.
