Implementing and testing the robot ⌨️

After gaining a good understanding of the process flow, it is time to roll up your sleeves and start iterating the robot implementation! 🛠⚙️🤖

Baby steps and something about eating large mammals 🐘

The key to success is to start small, adding small steps at a time, running the incomplete robot often. Nothing has to be "perfect" from the beginning. It is good to build an acceptable version first and, for example, decide what parts need better error handling after the full flow is generally covered.

Eventually, if all goes well, your robot will be ready to take over humanity!

What about the "testing phase"?

Don't go chasing waterfalls. - TLC, 1994

When you approach the robot implementation as an iterative process (code, run, code, run), you will constantly do testing. The point is not to complete the full robot blindfolded without testing, and then take it for a test run, but instead proceed step by step.

When you add a tiny bit of new functionality and immediately test it, you will notice possible issues as soon as possible and can promptly address them. If you complete the full robot using this iterative approach, there are not many areas that you have not already tested!

Where do I start?

Implementing a robot might sound like a daunting task. Fret not! Our Beginners' course teaches you the ropes. During the course, you will build a real software robot from scratch! As it happens, it is about Maria's task that was described earlier in this course (what a coincidence! 😀).

Documenting the implementation

You may find that robots written using Tasks and Keywords are pretty readable as-is:

*** Tasks ***
Insert the sales data for the week and export it as a PDF
    Open The Intranet Website
    Log In
    Download The Excel File
    Fill The Form Using The Data From The Excel File
    Collect The Results
    Export The Table As A PDF
    [Teardown]    Log Out And Close The Browser

For the simpler robots, the robot itself might be good-enough documentation. Since it is directly linked to the implementation, it will always be up-to-date (if the robot itself is up-to-date, that is). You will not end up with external documents getting old and outdated because nobody remembers that they even exist. Documentation and code in the same place can be a powerful combination (self-documenting code)!

But what if your process is very complicated and involves multiple robots chained together, completing tens of tasks and hundreds of steps? Then you should consider documenting the implemented solution in a separate document and describe the flow in enough detail so that others understand the dynamics and dependencies between the various robots, their inputs, outputs, schedules, etc.

Getting approval and sign-off from the business side ✅🧑🏽‍💼

You started this whole project to solve a specific business need: before delivering the robot and having it running in production, you should now confirm that it works, and it satisfies that need.

Nobody knows the automated process better than the people that are involved with it every day. They are the best people to help you confirm that all works as it should.

Involve them in a phase of User Acceptance Testing, and ask them to try the robot out in conditions that are as close as possible to the real-world: does it work reliably? Does it do everything that it is supposed to do? Does it handle any potential exceptions and special cases?

Any automation project should definitely include this phase because it provides a final confirmation that all works as it should, the business need is solved, and all the stakeholders involved are happy to push the button and put your robots into production!