Skip to Content
Author's profile photo Sourabh Deo

SAP BW: Regression testing an Idea

Regression testing is a kind of testing done for self-satisfaction. I mean to say that Regression testing is done to be sure that the changes implemented in  previous phases or post system testing and system integration testing, are tested thoroughly. Regression testing is not just rerunning the old test cases utilized by just filtering out some of those, but its rerunning the same tests (not test cases) with different approach than system testing and reducing the scope.  

Regression testing is type of testing carried out to ensure that changes made in the defect resolution or any CR related changes are not impacting the previously working SAP BW System end results i.e. data loads, BEx query outputs etc. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. This type of testing typically carried out by BW Domain experts. The automated testing methods are
the best and safe option to carry out the Regression testing. This automation can be applied with the help of QTP scripts, SOLMAN, SAP QC (with BPT module) installed and many other ways.

CRs are small changes in the requirements and accordingly they need to be reflected in the system. The general practice which is followed in a SAP environment is to have a sequence as below: 

  1. Smoke testing
  2. System testing
  3. System integration Testing
  4. CR implementation (if required)
  5. CR testing (System Testing of only the change done)
  6. Regression testing    

Regression testing is done to check the ripple effect of the changes done to the system once the defects rose in ST, SIT or CR-ST, are resolved. The defect resolution is done for a specific area for which the defect is rose for. This resolution may cause little adverse effect in some other area. This adverse effect is not directly visible while performing System testing. Same goes with the testing done post CR implementation if any. 


Let’s take example of Project XXXX as I have mentioned in my previous document ( ):


We had found an issue while testing of say RKF ZXXX_CCCC which was restricted to 0COMP_CODE, 0PLANT. We had found that the requirement said that the company code xxxx needed to be fetched for period 12.2013 and only this value is to be shown in this RKF. We raised a defect for this issue
and the developer team changed the restriction with new addition of 0FISCPERIOD restriction with a variable.


We tested the query by providing period selection as 12.2013, which fetched correct result too. Our testing was done successfully.


Later on there was some specific change happened to the query requirement. The query was globally restricted to 0FISCYEAR=2012. This was also tested successfully as the query used to only fetching data for 2012. 

The actual twist came in when we performed regression testing for the same query. The query was fetching incorrect result. The simple miss in CR testing would have made us pay a large toll. This issue was caught in Regression testing. The global filter was making the local filter not to work. This was because of the when query fetches data, it fetches according to the global filters and then the local filters are applied on the fetched data and then data is shown accordingly in the BEx analyzer.

Such issues or glitch in the testing performed also can be caught in Regression testing.

Regression testing.jpg

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.