The development with automated component tests (also known as automated unit tests - AUTs) enables an accelerated project approach. This is largely due to the following three properties of component tests:
- for the test execution no transport into the test system is required
- on the granularity of components, test design methods can be applied that enables complete test coverage
- it works with minimal simulation data and not with mass data of the system
What does a project flow look like in detail?
Requirement and test case creation
Any development must meet a requirement. In the SAP BW environment, these usually come from the business department. At the same time, a requirement must be matched by at least one automated test case. The associated test cases can be defined together with the business during or after the requirements have been given. The good thing is, the requirement already contains all information for the test case required - which behavior is expected for which initial situation, or expressed in abstract terms, which X of input values results in which Y of output values for the test object.
In cooperation with the department, a simple visualization (e.g. as a PowerPoint or Excel) is sufficient to summarize which values for a particular situation are given (the X ) and which result is expected in this case (the Y ), the expected value .
“The test case definition together with the business immediately reveals gaps in the requirements or ambiguities.”xGile Testing
A defined Y must be stored for each X . That means a clear behaviour must be defined for any data constellation. If not, the business can't define the requirement properly and consequently will never be able to test or to approve it. Therefore, the business must be able to define and assess the expected behavior, because only the business can finally approve the requirements are meet by the implementation.
“The business department must be able to define expected values and test cases, otherwise it could not approve the developments.”xGile Testing
Experience has shown that this procedure is not a problem for the business department and the test case definition is progressing rapidly. In the end you will get full coverage of all requirements that can already be carried out on the development system.
“Requirements are test cases.”xGile Testing
Therefore, one can clearly say that using component test, requirements are test cases. Test cases, in turn, are bind to your test object (SUT - System Under Test). The automatic test cases and thus "executable" requirements directly describe the test object (BEx query, BW transformation, HANA object, etc.). This creates an "executable" Documentation - the best and most up-to-date you will ever get for a SAP object.
“Component tests are like executable documentation.”xGile Testing
In the event of later code changes, the component tests not only fully secure the adaptation, but also fully describe the SAP object and the logic it contains. Handovers between developers or a change in the business department are also secured. No technical understanding is required for this form of documentation.
Full test coverage
There are techniques available to define the minimum number of test cases required and to generate non-redundant test cases from the test design, such as decision tables, equivalence classes or border tests. In addition to efficiency, the completeness of the Test coverage will be guaranteed. If the variance in the input values is too big, these methods become too complex and no longer applicable. This makes clear that only at this level of detail of component tests, having a clear focus on a single SAP object, these techniques can be applied to receive a complete and optimal test coverage.
“Optimal and complete test coverage can only be achieved at component level.”xGile Testing
With the approach described, all test cases can already be created and executed on the development system and a 100% test coverage can be achieved. There is no transport into the Q-system required yet, because all test cases contain the required test data. As a rule, 70 - 80% of the test effort takes place on the development system.
After validating the correctness of the components in the development system, the first transport to the Q-system takes place for testing on real data. Outliers and the runtime can be analyzed here. In the event of unexpected behavior, which is driven by data in the BW system, these scenarios will be simulated as component tests in the development system, fixed and the correctness of all requirements for the component fully validated again. The test design can also be revised.
This is the only way to ensure that once an error is found, it does not occur again and that no existing requirements are corrupted by the adaptation. A perfect safety net by automatic component tests. The following video demonstrated the test of a SAP HANA calculation view using xGile component tests:
In detail, an adjustment looks like this. First, all existing tests for an SAP object are executed. All tests should go through successfully. This is how the state before the change is recorded. Then the adjustment can be made. Afterwards all tests for this object will be executed again. If all have been successfully passed, you can be sure that the change did not produce any new defects. Now the transport into the Q-system can take place again and the integration test can be continued. This procedure is also used if issues in the P system are observed. Its obvious that the quality of the developments increases from iteration to iteration and finally a high level of quality is reached that can only be achieved with component testing.
It is clear that requirements have to be approved by the business. Therefore the business describes the behavior in this form - if this constellation of data happens (calculation values), then this is the expected result value. These lists consisting of X (calculation values) and Y (expected values) are already the component test cases. Therefore, all fully automatic component tests can be created with xGile via a simple graphical web UI, without any technical knowledge.
A 100% test coverage for a SAP object can already be achieved in the development system. The integration test End 2 End takes place in the Q-system. Anomalies found in the Q or in the P-system are simulated as test cases in the development system. After the fix and successful passing of all automatic component tests, the correction transport takes place to the Q / P system. This approach ensures that no new errors can arise and that the quality of the calculations remains constant and even increases. In addition, you get a full automatic test coverage, which is the basis for Scrum or DevOps.