Validation and Verification
Validation and Verification are similar test phases that involve the Developer and Tester preparing for User Acceptance Testing. Validation involves them collaborating to ready the solution for an SME to check. Verification is where an SME assists them to confirm the solution is working as expected, preferably using live data in controlled and measured tests.
Validation
Validation is where the Tester and Developer work together to prove that the solution conforms to the definition captured in the PDD and the requirements of the FRQ. Essentially they are proving the solution is ready to show the client SME.
Scenarios are created by the Tester using dummy data and tested in the development environment, first in Process Studio with breakpoints on exception stages to allow issues to be identified as they occur. Often these problems be fixed while the process is paused, before allowing processing to re-continue. Finally testing is executed in Control Room until all scenarios have been successfully confirmed.
- As many different cases as possible are used in order to identify and test each scenario
- A test plan or a scenario list can be used to track progress
- Any scenarios not tested (because a relevant case is not found) should be noted.
- Any fixes or changes identified should be applied and retested
- The process should not be forced along paths in order to reach untested scenarios
Validation Approach
In this phase, the Tester and the Developer work together to prove that the solution is correct.
- Environment: Development
- Platform: Studio and Control Room
- Data: Dummy
- Resources: Developer and Tester
Verification
Verification is a vital delivery phase that helps ensure requirements are met and all known scenarios have been recognized and tested. It is also an opportunity for the client to identify any errors or gaps in the process documentation. This can be done in a 'pre-verification' walk-through, where the developer explains the solution to the SME or Test Analyst, showing them Process Studio and where necessary, referring to the definition, requirements and design documentation. This provides the SME with a very basic understanding of how Blue Prism works and how the solution has been built.
And hopefully if the designer and developer have followed Blue Prism methodology, the SME should be able to relate the solution diagrams to the original business process flow diagrams, at least enough for them to assist in verification testing.
- As many different cases as possible are used in order to identify and test each scenario
- A test plan or a scenario list can be used to track progress
- Any scenarios not tested (because a relevant case is not found) should be noted.
- The Business will need to decide whether to remove the scenario from scope until suitable data is found.
- Any fixes or changes identified should be applied and the process re-verified accordingly
- The process should not be forced along paths in order to reach untested scenarios
- Ideally a variety of SMEs should be used to maximise the expertise used during verification
- If only live applications are available, verification will be the first opportunity to test the solution confirming or committing data.
- The SME must confirm that the solution is performing correctly before allowing changes to be committed
- Any messages or pop-ups not previously seen will require new logic to be added to the solution to handle them.
Verification Approach
The process is exposed to live data for the first time to expose and accommodate previously unseen scenarios.
- Environment: Development
- Platform: Studio and Control Room
- Data Type: Live
- Resources: Developer, Tester and SME
The Tester executes the processes in the presence of an SME who reviews and provides confirmation. As in the previous phase, testing begins in Process Studio before graduating to Control Room. This phase may evolve into a cycle of testing and fixing as the tester, SME and developer find and apply corrections to the solution.