Implementing and testing the robot
After understanding the process flow, it is time to roll up your sleeves and start iterating the robot implementation! 🛠⚙️🤖
Depending on how many hats you wear in addition to the analyst one, you might take part in implementation or not. In any case, being familiar with what it typically takes to implement a robot will help you with steps like the technical and business feasibility assessments.
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!
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!
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! 😀). Completing the course will earn you the Robocorp Level I certificate!
After mastering the basics, challenge your robot-building skills in the Level II certificate course, Build a robot. Earn the Robocorp Level II certificate!
Our Software robot project workflow course introduces best practices such as version control and collaborative development workflow, keeping credentials in a safe place, setting up Control Room for development and production purposes, etc.!
Our best practices section provides even more valuable knowledge on industry best practices that will make you more successful as a software robot developer!
You may find that robots written using
Keywords are pretty readable as-is:
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.
You started this whole project to solve a specific business need: before delivering the robot and running it in production, you should confirm that it works and 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 the people who know about the process under automation and ask them to try the robot out in conditions 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?
You can choose to demonstrate the unfinished robot periodically to get early feedback and insights. Those insights might provide valuable learnings that guide you on your way to the perfect solution!