Development Testing
The iterative 'build and test' approach of the Blue Prism delivery methodology evidently connects the Build and Test phases, by recommending developers prove their work beyond the confines of Object Studio and Process Studio. Object Testing is the first level of testing that can be applied to a solution and could be considered as part of the Build phase. Process Integration Testing is where developers prove their objects still function correctly when added to the parent process.
The objective of Development Testing is for the developers to assure themselves that their work is theoretically complete and ready for more formal testing.
Object Testing
Usually the majority of object actions are 'mechanical' integration sequences that manipulate an application without causing changes to records and underlying data. These 'read only' pages can and should be first tested by the developer to prove that they work consistently and reliably.
Object Studio runs slower than Control Room and it is a common mistake to believe that because an object diagram appears to run well, the page is then complete. However the developer must remember that object pages will become part of a larger sequence (the process) that will run faster than Object Studio and expose any weakness in the synchronization logic, e.g. in Wait stages. By testing object pages in isolation at relatively low speeds, developers run the risk of design mistakes or application latency errors going undiscovered until later in the delivery phases or even worse, post-implementation.
- As application elements are modelled, the ‘highlight’ function should be used to ensure the element is identified correctly.
- As application elements are utilized, the ‘debug’ functionality should be used to step through and prove the integration logic.
- Running end-to-end in Object Studio at maximum speed will demonstrate the application is under control at a speed that is slightly less than Control Room.
- Using ‘step out’ will run the action almost (but not quite) at Control Room speed.
- Creating a ‘test rig’ in process to run a sequence of actions will help ensure they will work together as expected.
- Obviously actions that commit changes to application data should be handled with care, but test rigs are an effective means for the developer to prove that an object is ready to be used.
- Test rigs are also an efficient method of performing regression testing following changes to target applications.
- Run test rigs from Control Room to fully validate objects at production speed.
- Actions should be tested with a variety of input values to maximize test coverage.
- Where test environments are not available, use break points to control actions that commit changes to an application.
- 'Test mode’ decision stages can be used to redirect the flow to avoid committing changes, e.g. by pressing Cancel instead of Save.
Process Configuration Testing
Although the process build phase is the first opportunity to test actions in concert, it is recommended that an incremental approach is taken where objects are introduced gradually, rather than waiting for every object to be complete before starting to build the process. Great advantage can be had by using a template to prepare a functioning process skeleton, into which objects are added and tested in a systematic manner. More information on this iterative 'build and test' technique can be found in the Build Procedure guide.
- As multiple pages, sub-processes and wrapper objects are added to the main process, ‘step in’, ‘step out’ and ‘step over’ debug modes should be used to test them. This will ensure that the steps combine correctly and that the input and output parameters of each can be validated.
- If there is no test environment available for an application, ‘break points’ and a ‘test mode’ should be used to ensure that no updates are done in the live environment by committing data to the application.
- As each new scenario is added to the process, it should be tested. A method of keeping track of what scenarios have been tested should be used (either a separate record, or management information built into the process).
Approach
This section outlines the type of testing required to ensure a solution is thoroughly tested and performs correctly. The approach aims to ensure objects and processes interact as designed so that the automation can consistently perform at Control Room speed.
- Environment: Development
- Platform: Studio and Control Room
- Data type: Dummy
- Participants: Developer
This testing phase consists of Integration Testing and Non-functional testing
Integration Testing:
- Proving the process flow as well as tracing the data through the pages, underlying objects and sub-processes.
Non-functional Testing:
- Recoverability
- The ability to restart the target applications in the event of system failure or unexpected behavior.
- If required, the ability to resume a case previously in flight and recover processing at the point the failure occurred.
- Resilience
- Test ability to retry specific parts of the process where a system exception has been thrown by an underlying object.
- Performance
- Running at full speed across all paths to identify areas that require improvements to performance or application synchronisation.