Evidently, the aim of testing is to deliver solutions that meet business requirements and contain the minimum possible number of faults, and naturally this is a vital part of the Blue Prism delivery methodology.
Test Early and Test Often
Testing as early as possible in the creation of a solution is a key principle. Simply put, this helps flush out misunderstandings, mistakes, scenarios and system behavior that may otherwise have been missed during the preceding delivery phases, and which could lead to expensive problems later on. An RPA solution comprises of more than Blue Prism - the data, the business rules, the applications and the environment are all part of the overall solution and all must be considered during testing. A common mistake is to perceive an automated solution as the sum of the Blue Prism parts - the processes, objects, queues etc - when in fact there are many more external elements that make up the overall RPA solution.
Honour the Contract
Another essential point is to align test scripts with the detail set out in the process definition, requirements analysis and solution design. These documents should clearly define how the solution ought to perform, what it is required to do (and what it is not required to do), and can be thought of as a contract between the client and delivery team. Conceptually the test scripts should set out to prove that that contract has been honoured and the agreed success criteria have been met.
Use Live Data
The aim of RPA is to have digital workers automate live applications, and this inescapable fact must be acknowledged and incorporated into testing strategy that governs when and how the digital workforce will first use live data. As yet a digital worker cannot think or adapt and can only operate under familiar rules and conditions. It will need supervision (and probably correction) when it runs in an environment it was not trained for.
If the live environment cannot be replicated with test applications, then Blue prism recommends either creating a 'pre-production' environment where live applications are used in secure test conditions, or factoring an extended period of 'live-proving' or 'hypercare' into the delivery plan. Using live data in anywhere but a production environment is often anathema to those new to RPA but Blue Prism has a proven approach that is explained further here.
Like the Build phase, the Test phase can be broken down further, where in fact the two overlap. As mentioned above, developers also have a testing responsibility and should develop a habit of testing everything they create in order to make subsequent test phases as easy as possible. Testing activity can be divided into the following categories.
- Development Testing
- Validation and Verification
- User Acceptance Testing
- Environment Testing
- Implementation Testing
What are the key input and output documents for the Test phase?
- Testing Approach
- Test Acceptance Criteria
- Test Scripts
- Verification Test Plan
- Validation Test Plan
- Testing Approach - Updated
- Test Scripts - Updated
- Verification Test Results
- Validation Test Results
- User Acceptance Test Plan - Updated
Visit Blue Prism Help online to find more information on the latest product features, troubleshooting advice and 'how to' guides.