Agenda:
1. Look at recommended design documentation, and have a candid discourse.
2. Talk about Testing, and how to design for Testability
3. Select a Process to Design an Automation for
4. Design the Process
5. Break that Design into testable units
6. Estimate the work.
1. Look at recommended design documentation, and have a candid discourse.
2. Talk about Testing, and how to design for Testability
3. Select a Process to Design an Automation for
4. Design the Process
5. Break that Design into testable units
6. Estimate the work.
A Brief Look at the What you are supposed to do:
These are some recommended documents pulled from UiPath's RPA Implementation Methodology Training course.
|
|
| ||||||
Your RPA Docs, after a week of following the instructions:
When I read these documents, it reminds me of the last 30 seconds of pharmaceutical drug commercial--"Here's a million things to worry about, don't say we didn't warn you."
I'll grant--at scale, at the right company, for the right process, with sufficient resources, making tons of documentation is somewhat reasonable. But all that documentation brings it's own costs and liabilities.
I'll grant--at scale, at the right company, for the right process, with sufficient resources, making tons of documentation is somewhat reasonable. But all that documentation brings it's own costs and liabilities.
In Fact, UiPath's Implementation Training alone
|
|
It's alot. We could talk about it, but let's just design a Bot and see where we end up.
But first...
But first...
Testing and Testability
If it takes hours to test the Bot, it takes longer to get from Dev to QA, longer to get from QA to Prod, and longer to go back through the whole thing whenever you find a problem. You'll have to stay at the office late, you'll have to spend time explaining why new processes are late, and you will slowly fall further behind without bringing in additional people.
Even though it feels like an inconvenience, developing with testing in mind makes you go faster in the long run.
Even though it feels like an inconvenience, developing with testing in mind makes you go faster in the long run.
Arrange, Act, Assert
Let's go back to our twitter login:
|
Arrange
|
Act
|
Assert
|
Arrange: Setup the test by opening Twitter.
Act: Execute the Testable Action by filling in the credentials
Assert: Determine, TRUE or FALSE, if the test passed, by checking for the 'Home' label.
Act: Execute the Testable Action by filling in the credentials
Assert: Determine, TRUE or FALSE, if the test passed, by checking for the 'Home' label.
This is a simple example, but in reality, you're activities shouldn't be much more complex than this.
But now, if I had to check keep thirty twitter credentials to make sure they were all good, I could just do this:
But now, if I had to check keep thirty twitter credentials to make sure they were all good, I could just do this:
So, as we move on to design--let's keep this in mind: All the parts of our design should be as easy to test as that.
3. Select A Process (Intermission)
(Talk about Massive Movie Box)
4. Design The Process (Whiteboarding)
At the highest possible level, what are we doing here?
|
Dispatcher
How does our Que work?
|
Performer
What is the result of a successful Transaction?
A failed one? |
Reporter
What do people need to know about the Transaction?
How will they find out? |
5. Break The Process into Testable Units
6. Estimate the Work
(Planning Poker, Cool Agile Tricks)