The bot is an executable which resides on a windows machine (normally a virtual machine). During playback the bot logs on as the recorded user and executes that user’s transactions. The requirements for bot setup can be found here.
This is the SAP system into which Testimony is installed and from whcih it is operated. Testimony users log on to this system to set up Testimony, start recordings and playbacks and analyse results.
These are run manually before a recording or playback and the operator needs to check the results of these to see if they should continue with the recording or playback.
These are used to link scripts which use the same data, for example a purchase order number. If the creation of a purchase order fails during the playback then Testimony recognises that there is no point running a subsequent script that approves this purchase order. Testimony will therefore cancel the execution of the order approval script.
To record and playback Testimony has enhancements on the source or target system to enable the recording or playback to operate correctly. These are switched on before recording or playback and are automatically deactivated at the end of the recording or playback in the “Post-Processing Steps”.
The execution queue is built from the repository and contains the scripts to be played back.
A filtered recording is used when you want to record a small subset of users or transactions on the source system. It is typically used for testing purposes to ensure that the setup from central to source system has been completed correctly.
Filter sets have two main uses: to exclude certain objects (transactions, batch jobs, etc.) from a recording; and to provide special handling of error cases during a playback. For example, if you want Testimony to ignore all occurrences of transaction SM21 from the recording, then adding this transaction to the recording filter set will achieve this. If you want to ignore occurrences of message E123 from a particular screen, you can set this message as an exclusion in the comparison filter set. Filter sets are also available for the transfer to repository and transfer to execution queue processes, although these are less frequently used. This topic should be further studied via the Filter Sets section here. THIS MUST BE LINKED
Testimony records deeper than just the UI so that objects such as change documents and number ranges are also recorded. These can then be checked at playback to ensure that these match providing a deeper level of testing.
The playback is the playing back of the scripts in the execution queue, via the bots, on the target system.
These are run automatically after a recording or playback is completed. Any errors in post-processing cause a hard stop preventing the status moving to complete. If errors are found then the operator should check the errors and see if they need to manually resolve these.
These are run automatically before a recording or playback starts. Any errors cause a hard stop preventing the recording or playback starting. Errors should be resolved before restarting the recording or playback
A recording (either Filtered or Standard) is the process by which actions on the source system are captured by Testimony for later playback.
The repository is a staging post for recorded transactions. Once all recorded transactions have been stored in the Central System, they are transferred to the repository (potentially with some filtering) before being transferred to the execution queue for playback.
This is the system that is recorded and therefore acts as the source for the recording. In BAU operation of Testimony, this is usually the production system.
A standard recording records everything except a small number of users or objects as defined in the “Filter Sets”
This is the regression test system into which recorded scripts are played back via the Bots.