Top 50 SAP Testing Interview Questions
1. What is SAP Testing?
SAP Testing is same as manual testing but here the applications are SAP R/3 and Enterprise portal. Whenever there is change in R/3 and Portal and You need to design test cases according the change request and test the application.
2. What are the Testing Tools we use to test the SAP data?
Testing in SAP is usually done by use of test scripts. These are sequences of instructions which follow business processes. They can be used by configuration, support and end users.
New configuration in SAP is usually done in a Development client. After the configuration is completed it will be tested in that client by the configuration and/or support team. When they are satisfied the config is working correctly they will transport the new settings to a Quality Assurance client. There, any client-specific configuration is added and then the tests are run again.
When the config/support team are satisfied they will have the tests run by end users. The end users are more likely to spot any procedures that don’t meet the usual business requirements but these might be deliberate, either as improvements or to meet the requirements of operating with SAP.
3. SAP Unit Testing
This tests isolated pieces of functionality, for example, creation and save of a sales order. The test is done in the development by a configuration specialist and confirms that the sales order can be saved using the SAP organization elements (sales organization, company code, credit control area, etc.) along with the customer master data set up, partner functions, material master data, etc. It establishes a baseline of SAP functionality.
For ABAP development, for example, unit testing shows that a report can be created from developer generated data. Assistance in data generation may come from a functional consultant.
4. SAP System Testing
This is testing where elements of related SAP functionality are linked together in the development environment to ensure the pieces work together. For example, a quote-to-cash flow would show that a quote can be used to create a sales order, a delivery can be created and processed from the order, the delivery can be billed, the billing released to accounting, and a customer payment applied against the accounting invoice.
Each of the component parts is unit tested ahead of time and the data used in testing is usually fabricated based on the knowledge of the project team.
5. SAP Scenario / String Testing
this tests specific business cases. For example, there may be configuration and business process design that is unique to a certain customer set or a given product line or a set of services. Tangible products and services are processed very differently from each other, so you might have different scenarios you need to test.
Again this testing is usually done in the development environment to prove out a requirement – an argument can be made to say this is a test case you would cover in system testing. Scenario testing can also happen in the QA environment, but I prefer to call that string testing.
This testing also includes execution of interfaces and other development objects, e.g. reports, with fabricated data.
6. SAP Integration Testing
This testing is similar to scenario testing except it is typically done in the QA environment and uses more realistic data. Ideally the data has come from a near real data extraction, conversion and load exercise (not necessarily a full conversion) so the data has a certain familiarity to it for a business end user, e.g. recognizable customers, materials, pricing, vendors, contracts, etc.
The testing shows that the business process as designed and configured in SAP runs using representative real world data. In addition the testing shows interface triggers, reports, workflow are working.
7. SAP Interface Testing
Testing of interfaces typically occurs at different points in a project so it is important to know what you are testing when. During the project development phase isolated interface testing usually refers to unit testing activities where you confirm that your code can consume a file of your own making. You might have two development systems – one SAP, one non-SAP – where you run a test to show that the sender can generate a file and the receiver can consume it.
In the QA environment interface testing might involve execution of business transactions on the sending system followed by looking for automatic generation of the interface output; this is then followed by the receiving system consuming that file and proving that a business process continues on the receiver. Your interface testing might prove that the whole process runs automatically with business events triggering the outbound interface correctly, automatic transfer and consumption by the receiver.
This testing and its definition can become even trickier if you use a message bus where the idea of point-to-point interfaces doesn’t apply and you need to consider publish-and-subscribe models.
Whatever you are doing under the guise of interface testing, you need to be clear about the scope of the tests and the success criteria.
Typically interface testing becomes part of larger testing activities as a project progresses. In my experiences interface testing shows that the triggering works, the data selection (and exclusion) is accurate and complete, data transfer is successful, and the receiver is able to consume the sent data. Wrapped around this is showing that all the steps run automatically and that error handling and restart capability (e.g. data problems, connectivity failures) is in place.
8. SAP End-to-End Testing
This is similar to scenario testing in that a specific business case is tested from start to finish and includes running of interfaces, reports, manual inputs, workflow, etc. In short it is attempting to simulate a real world business process and, in order to make it as real as possible, it is done using the most realistic data.
Ideally the data used was the result of a data extract, conversion and load process. I would expect this kind of testing to occur in a QA environment: at some level it can be seen as a way of validating that the individual unit tests, scenario tests, integration tests and interface tests produced results that work together.
9. SAP End User Testing & User Acceptance Testing
I grouped these two together because they are closely related, if not identical. The goal here is to ensure that end users are able to perform their designated job functions with the new system(s). A crucial part of this testing is referring back to the business requirements (you have some of those, right?) and blueprint to ensure that the expected features, functions and capabilities are available.
As part of the project user involvement along the way should have been providing feedback to ensure the design met the requirements, so there should not be any big surprises.
Again this is activity that usually occurs in a QA environment with realistic data and the inclusion of end user security and authorizations.
10. SAP Stress / Load / Performance Testing
This kind of testing examines things like whether the system response time is acceptable, whether periodic processes run quickly enough, whether the expected concurrent user load can be supported. It also identifies processing bottlenecks and ABAP coding inefficiencies. It is rare for a project to have worked out all the system performance tuning perfectly ahead and to have every program running optimized code. Consequently the first stress test on a system can be painful as lots of little things pop up that weren’t necessarily an issue in isolated testing.
The testing is geared towards simulating peak loads of activity, either online users or periodic batch processing, and identifies the steps needed to improve performance. Given that the initial test reveals lots of areas for improvement you should expect to run through this a couple of times to ensure the results are good.
11. SAP Usability Testing
This testing is usually concerned with how many key strokes and mouse clicks it takes to perform a function; how easy and intuitive it is to navigate around the system and find whatever it is that you are looking for. In an SAP implementation using the standard GUI there isn’t much scope for this kind of testing: end user training shows how to navigate, how to create short cuts and favorites, modify screen layouts, etc.
On the other hand a project that involves building portals may well need to perform this kind of testing, not just for reasons mentioned earlier, but also for consistency of look and feel.
12. SAP Security and Authorizations Testing
Ensuring that users are only able to execute transactions and access appropriate data is critical to any project, especially with today’s needs for SOX compliance. This testing is typically done in a QA environment against near-final configuration and data from a full extract, conversion and load exercise. Test IDs for job roles are created and used to both confirm what a user can do and what a user cannot do. More often than not this kind of testing is combined with end user or user acceptance testing.
13. SAP Cut Over / Dry Run Testing
This kind of testing is simulating and practicing certain major one-time events in the project lifecycle. Typically the terms “dry run” and “conversion” together to mean a full scale execution of the all tasks involved to extract data from legacy systems, perform any kind of data conversion, load the results into SAP (and any other systems) and fully validate the results, including a user sign-off. Most projects have several dry run conversions which progress from an exercise in capturing all the steps, checkpoints and sign-offs in data conversion to a timed exercise to ensure everything can be accomplished in the time window for go-live.
Once it becomes a timed event a dry run data conversion readily rolls into a cut over test, where it is one component of an overall cut over activity sequence: a cut over test usually ensures that all the necessary tasks, e.g. importing transports; manual configuration; extracting, converting and loading data; unlocking user IDs; starting up periodic processing for interfaces, etc. are all identified and can be executed in the go-live time window.
14. SAP Day-In-The-Life (DITL) Testing
This is one of my favorite kinds of testing – it really is what is says it is. Run the system the way you expect it to be run during a regular business day. Real users, real data, real volumes, real authorizations, real interface and periodic job execution – the closest you can get to a production environment before you go-live with the system.
Not every day in business is the same so you might want to run a few DITL tests. However these can be difficult to organize because of the need to have end users trained and available for extended periods of time as well as having all partner systems able to participate in the activities with real and synchronized data across the systems, real users, real data volumes, etc.
15. SAP Regression Testing
Each time you put a new release of code and configuration into your production system you want to be sure you don’t cause any changes in any processing beyond what you expect to change. Hence the role of regression testing: test your existing functionality to be confident it still works as expected with the newly updated configuration and code base.
Clearly you don’t want to find you have issues in production after you make the changes, consequently regression testing in a QA environment that has similar data to production is a good test bed. In some cases automated testing can be effectively deployed as a fast and regular method to ensure core business processes are not adversely affected by new releases of code and configuration.
16. What are SAP Testing Services
To mitigate business risk and to ensure expected results in the complex SAP environment during the entire SAP solution lifecycle it is imperative to conduct sufficient quality testing. TSAP testing services uses eCATT as the functional test tool in SAP applications.
Some of the testing services offered are:
► Application testing
► Performance testing
► Regression testing
► Testing strategy and management
17. What are the types of tests are used to test the SAP R/3?
The important types of SAP test are
► Unit testing
► Development testing
► Integration testing
► Performance testing
► User acceptance testing
► Regression testing
18. What is unit testing in SAP?
Unit testing is done at the transaction level that related to configuration. For example customer master data, vendor data, purchase orders creation and so on. It focus on master record, transactions, roles and profiles.
19. For what purpose development testing is used?
It is use to test various Reports, workflows, forms and so on. Development team is responsible for executing the development test.
20. What is Performance testing?
It is used to test for determining the time taken to perform the actions. It helps to determine the system to meet and fulfill the service level agreement.
21. What is Integration testing?
After all sap modules are implemented, Integration testing is used to test whether all the posting are working properly that cuts across SAP modules, for e.g order to cash, procure to pay (p2p) and so on.
22. Tell me about user acceptance testing?
User acceptance testing is done at end user level those who are executing applications. They run and test the scenarios if any defects are found, the configuration team members resolve these defects during this test.
23. What is regression testing and give one example?
This is used to test previous working system is not affected by the introduction of new system changes. For example organization bought new company and we have to create one or more company code, after configuration we have tested and it working perfectly. So old configuration does not effect any errors due to new configuration.
24. What is manual testing?
Manual testing is done manually to identify the bugs and errors. It is used to test for data issues, for e.g if the master data has errors, with manual testing tester can rectify the master data errors.
25. What is Automated testing?
Automated testing is used to perform tests based on regular interval of times, with the help of scripts you can specify what needs to tested.
26. Explain difference b/w control and control object?
Control is a object for which we want to do testing, where the control object is purpose of control and assigned at sub process level.
27. What is test case?
Test case is a template that every organization maintains and used to test implemented data during project execution according to the scenarios that test cases are created.
28. What are the testing tools can be used to test web shop performance?
We can use testing tools like load runner and mercury.
29. What is SAP?
SAP is a ERP business software package that designed to integrate all areas of business and it provide solutions for all operations. Read more for about SAP
30. Specify types of testing?
There are different types of testing such as black box testing, white box testing, security testing, recover test and so on.
31. What is Defect prevention?
It is technique used to find and rectify errors before they effect the development phase.
32. What is GUI Testing of SAP Applications
Test the functionality of your SAP R/3 applications.
In minutes you’ll understand the power behind Rational Robot’s Object Testing as you quickly record tests that verify:
Properties of SAP screen controls.
Values in application fields.
Integrity of your business process flow.
Robot lets you record functional tests against your SAP R/3 application, regardless of R/3 hardware platform or database server
33. What is Load Testing SAP Applications?
In executing your business transactions on the Web interface, through integration with the powerful SAP engine, the SAP WAS system creates a highly complex dialog between the client machine and the server.
This complexity is not visible to the user or those in charge of deployment, but it is an important factor when it comes to middleware.
Your load testing tool’s ability to take into account the specific nature of this rich and complex dialog is an essential pre-requisite for performance testing SAP applications. The tool must be capable of automatically and natively handling SAP Web Application Server (WAS) in order to efficiently build scripts that cover all your test cases.
Without fully compliant SAP WAS support, you cannot carry out the full range of tests and run the risk of deploying an application whose behavior under load has not been validated properly – with possibly damaging consequences. These could include slow-downs for users, or even blocked access for some users in high load periods, putting in jeopardy not only the success of the project, but also the company’s entire economic foundations, due to the critical importance of its business services.
34. What is Testing Orienting Applications?
Software Testing is more Oriented to Detecting the defects or often equated to finding bugs. Testing is a process of executing a software system to determine whether it matches its specification and executes in its intended environment under controlled conditions. The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should.
35. What is SAP QA ?
Sap QA: – SAP Application QA involves the entire software development PROCESS – monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to ‘prevention’.
36. What is SAP implementation lifecycle?
SAP implementation lifecycle
In the lifecycle of a SAP solution, it is necessary to test the functions and performance of the solution developed by programmers. Work environment with SAP testing, SAP provides an environment for all phases of testing, you can use to test in the following cases:
The implementation of SAP solutions:
1) Integration of new components and business scenarios.
2) Client Development.
3) The function tests for all the functions.
4) Integration testing with other components in the integrated environment.
5) Updates/changes regression testing.
6) Import support programs.
Integration Features and Test Preparation:
1) Creation of manual test cases and automated.
2) Management manual and automated test cases .
3) Creation of test plans.
4) Define and manage a series of tests.
Test execution Phase:
1) Test communication with the test tool extended desktop and Computer Aided Test Tool.
2) Integration test cases and test scripts from non-SAP providers.
3) Assign work lists (probes) for individual testers.
Test Evaluation Phase:
1) continuous improvement vision test and test results.
2) Complete documentation of the testing process into test plans (test cases,descriptions of test cases, test results, notes of test cases, error messages).
3) A detailed evaluation of all test plans in tables and graphs.
4) Export test results of the Office applications.
5) message processing.
Generally testing has two ways, one being, system integration testing, this will be performed by the SAP development team of the product owner, and the second being, the user acceptance testing (UAT) is performed on client’s team in the client’s location. UAT usually performed by the end user to test the solution is working fine.
37. What is AWB?. What is its purpose?
AWB stands for Administrator WorkBench. AWB is a tool for controlling, monitoring and maintaining all the processes connected with data staging and processing in the business information whearhousing.
38. What is the significance of ODS in BIW?
An ODS Object serves to store consolidated and debugged transaction data on a document level (atomic level). It describes a consolidated dataset from one or more InfoSources. This dataset can be analyzed with a BEx Query or InfoSet Query. The data of an ODS Object can be updated with a delta update into InfoCubes and/or other ODS Objects in the same system or across systems. In contrast to multi-dimensional data storage with InfoCubes, the data in ODS Objects is stored in transparent, flat database tables.
39. What are the different types of source system?
SAP R/3 Source Systems, SAP BW, Flat Files and External Systems.