Blog > SAP API testing myth: Testing should be done by the Functional Users. I’m only a developer!

SAP API testing myth: Testing should be done by the Functional Users. I’m only a developer!

SAP_API_testing_myth_2
Michał Krawczyk SAP Mentor, SAP Press Author
icon__calendar 2021-01-07

In this article you will learn:

  • About the process of testing the SAP system
  • Who SAP functional consultants are
  • How SAP testing should be handled

Reading time: 4 minutes

The importance of quality assurance

Testing is a core factor in the process of keeping the fast deliveries and providing a secure environment for business operations. As digitization increases, we face new requirements for the development and support of our systems. Being able to maintain a stable SAP environment while introducing many changes to the transport and functional layer is a challenge that cannot be undertaken without a good QA team.

Apart from the qualified QA team, another important thing is the proper division of work and understanding of one’s responsibility. In the SAP society, there is a common myth about who should perform most part of the testing. Some developers say they don’t need to bother with it as it’s rather a job for functional consultants. In a minute you’ll find out why such an attitude is not conducive to your business.

 

SAP system testing

Testing of such a huge system like SAP is surely a challenge. The process is comparable to the testing of software applications. Each introduced change in SAP software needs to be followed by a test case. This is to check the new functionality and verify if it doesn’t interfere with any other request flows. To prepare the test case scenario the right way, one should have the knowledge of how the system was modified. Then on the basis of the nature of the modification, there are the following tests that can be performed:

  • Unit Testing
  • Integration Testing
  • Regression Testing
  • Performance Testing
  • Functional Testing
  • User Acceptance Testing (UAT)
  • Security Testing

As you can see, even a small change needs to be carefully tested before we can continue with our work. Judging by the number of possible testing procedures, splitting the process between developers and functional consultants seems to be a fair solution, right?

 

What’s wrong with this approach?

The problem is in the misinterpreted role of SAP functional consultants. Their main task is to customize the respective business area and make sure the system reacts accordingly to the constraints of the requested use case. Functional consultants take care that proper training is given to the users and that the system performs right while the business flow is complete.

They can sometimes prepare test scripts for testing the configured scenarios but it’s not their main duty as they’re not expected to have the knowledge of software development. Meaning, SAP functional consultants don’t equal functional testers.

If functional consultants don’t know how the development was done, they’re simply unable to run the complete number of variants of tests to double-check a given system modification. Not to mention, when there’s more than just one change introduced to the SAP landscape. As a result, they still need the developers to perform the rest of the procedure.

 

The role of developers

If you’re a developer, you’re responsible for the code and how it works with other components, integrated modules, etc. Developers have all the information about the introduced changes, the way they were implemented, and how they should affect other parts of the system. Knowing this, they have the knowledge needed to test the changes thoroughly.

Handling the responsibility to SAP functional consultants is not the right decision. Not only is it not efficient (as the work still needs to be completed by developers) but it can also lead to poorly performed testing procedures. As we know, the financial risk connected with a later repair of bugs increases along with the possible delay of the feature release.

 

How SAP testing should be performed

The most optimal way to test the SAP system efficiently is to use automation. According to a study done by ASUG, over 86% of clients are concerned about the risk related to a lack of comprehensive testing. Because of the size of the system, the testing process obviously consumes a fair amount of time and money. What’s more, when it’s performed manually, it’s highly prone to errors.

That’s why automated testing has become so popular these days. Turns out that by just automating the SAP API testing, you can save a significant amount of man-hours and increase your speed of business operations.

Automating SAP testing gives you benefits such as:

  • Improved test coverage
  • Better product quality thanks to the reduced number of errors
  • Fewer outages in SAP production environments
  • Faster development cycles
  • Decreased workload during release cycles

 

Know your role in the project 

Most of all, the testing process should be performed by the right people who have the knowledge and experience in this area. There’s no need for handling the work to someone who is not able to finish it properly. It’s mainly because doubling the efforts usually results in doubling the time and funds needed to accomplish the task.

That’s why it’s important to know who’s responsible for what tasks in the project and underline the role of developers in the SAP testing. When everyone is aware of their duties, there is nothing to worry about.

 

Read also:

1. SAP API testing myth: I don’t need to test my SAP Application Interfaces – I’m a very good developer!

2. Our new SAP Press book – Testing SAP APIs: Strategy and Execution

Michał Krawczyk SAP Mentor, SAP Press Author
SAP integration consultant since 2004. He has been recognized by SAP included becoming an SAP Mentor in 2007 and winning the top contributor/topic leader award from SDN (SAP Developer Network portal) in SAP PO/PI eight times. Michal is the author many SAP integration related books: Mastering idoc business scenarios with SAP XI , Mastering idoc business scenarios with SAP PI (second edition).