Today we had an internal presentation of one of our trainees who implemented a idea of mine into a prototype: Automated testing in SAP BW. The original idea is the following: The system used for developer tests shall provide additional functionality to flip a swith and let the system perform tests automatically. The green light shall indicate that a specific solution is still working, so the application development could go ahead.
The current suite includes
- Data handling,
- Process scheduling,
- Comparing and Logging.
Data handling
The initial solution is working on DSO objects. So somewho we need additional objects to store the initial content of a relevant DSO (Backup), and tostore the well defined set of test data (Import). Typical actions are backing up and restoring data, load testdata and compare computed results with expectations. Further development include the handling of PSAm write optimized DSO and of cource Cubes.
Process scheduling
The listed actions plus executing process chains need to be scheduled. But all in an very easy way without setting up test process chains. A small table was implemented only containing a list of actions to perform.
Comparing & Logging
Each and every step is logged, duration and status written to an extra DSO. Now we could set up exception reporting and see the result of latest test execution. The essential step in testing is the test. I defined it as the comparision of computed results with expectations. If it fits we have a green test, if one bit differs we have a red test.
In the presentation we saw a little demonstration. At least we saw nothing, because of its background type of acting. But what happend is the following:
- Data from one relevant DSO source is backuped into another DSO
- The relevant DSO was emptied
- Test data is loaded into the relevant DSO
- A process chain was executed
- The content of the DSO was compared with the content of another DSO
- The relevant DSO was again emptied and filled with the backuped content.
- All this was stored in a log DSO.
What we need to do now is to force the business department to describe very detailled what input data shall result into which output data, and additional provide examples to prove the implementation right. With this done prior to the implementation we as developers are able to develop much faster and focussed to the real demands.
I’m looking forward to have both feedback from yours and use the tool by myself.
