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.

    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.


    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.