Regardless if you are reading this as a developer or a CIO this article will highlight an area of the development phase within RPA that can be adopted to give some real benefits to your automation journey.
This is a completely fictional dialogue between an automation stakeholder and... well, me! I am assuming Blue Prism as the product of choice as this is my area of expertise.
Statement: We should be doing Test Driven Development!!
What is test driven development?
TDD is an advanced technique in software development using automated mini-tests that promote good software design and forces decoupling of dependencies. The result is a comprehensive suite of tests that can be run at any time to show the software is still working.
Why is it different to normal testing? Our business people are very good at that.
TDD is performed at the code level by developers for developers. It does not rely on an end to end flow of data as per a normal process therefore simplifying the run conditions. If a developer makes a change to existing code, they know a test already exists for that area of code that they can rely on to validate their change.
Is this relevant for RPA?
The building blocks of an RPA process (business objects in Blue Prism) are independently testable. If software is independently testable then it is relevant to think of a TDD approach. Business objects can operate as integrations to desktop applications or as non-integrated isolated ‘classes’. Both types are testable as GUI system tests and classic ‘unit’ tests, respectively.
It all sounds like extra overhead, why should we adopt it in RPA?
A comprehensive test suite is particularly useful when ‘change’ is added to the equation. RPA experiences many forms of change: -
1. Process change requests
2. Desktop windows patching
3. Operating system upgrades
4. New third party product versions (Java / MS Office / Adobe, etc)
5. Legacy system upgrades
6. RPA provider upgrades
Having a test suite, with high % coverage of your objects, in your armoury will drastically reduce the time to find and fix problems introduced by change.
New or late requirements are often integrated much easier to a process when effort has been made to design it well. TDD produces good design as a side effect. Time-saved, money-saved, value added. Google the ‘cost of change curve’ for researched evidence.
TDD will undoubtedly improve the robustness of your objects. A well-designed test will put a subset of process steps through a rigorous work out at full speed therefore catching latency issues as well as logic errors.
In addition, there is a definite developer satisfaction that comes with a smooth development process that it less measurable and critical to success.
It can't be all good news, what's the downside?
A TDD approach will increase the development time estimates as the developer cannot simply build something, step through the logic to prove it works and move on. They must show discipline in ensuring all object level development is included in a test process that covers both positive and negative scenarios. This inevitably takes more time in the development phase.
This approach requires that the profile of your process builders start to sway more into the pure developer category and requires commitment from them to deliver it. It is often not a developer's favourite activity.
It is possible to write bad tests that give false positives. This is wasted effort and introduces the risk of finding errors later in the process therefore a degree of confidence loss in TDD.
TDD does not replace process end to end testing with the business. This always must be done in addition.
Ok, I'm sold! How do we try it in Blue Prism?
Excellent! Ensure your development phase asks the developers at the right time about have tests been written to the required standard. Ensure your test phase run the tests and validates any failures. Here is an overview of a suggested set up. For the ultra-keen, build a test coverage report to show how many of your object actions are covered by object tests. Aim for 100%!!