Choosing the SAP automation strategy

SAP automation strategy, Automation test strategy in SAP, ERP automation strategy, Automation test strategy in ERP, test automation in SAP, SAP automation testing strategy, SAP automation test plan, planning SAP automation testing, automation test plan in SAP, How to write automation test plan for SAP, SAP automation test plan

Choosing the SAP automation strategy.

HP Quality Center (QC) is an example of a tool that connects the modular business process method and the keyword-driven approach. With the help of the QC module BPT (Business Process Testing), business processes can be joined up like building blocks to form a chain. The test data can then be attached to the individual links in the chain (the business components).

Each chain forms a business transaction, with the relevant user department providing the input for each individual business component. The business experts are responsible for verbally describing the links in the chain, while the engineers translate the descriptions into test scripts.

This gives the testers who assemble the new chains – or test cases – the advantage of being able to build on links that already exist. Test cases do not necessarily have to be fundamentally different from one another. If, for example, a chain for a business process comprises 100 test links, it is highly probable that many individual links can be used from other chains.

An example of this is the process of logging on to SAP systems, which does not have to be described and defined a new once SAP logon has been specified for the first time. This link in the chain would also weather an upgrade. And, with such a description and automated testing, there’s a pleasant side effect for the company doing the testing: It receives an overview of the brainware in its user departments, displayed and clearly structured in test scripts.

SAP or non-SAP tools?

Non-SAP test tools pass muster particularly in test automation that entails testing integrated business processes with systems from third-party providers as well as from SAP, such as for customer relationship management (CRM) or content management (CM). 

eCATT from SAP immediately registers if a certain test script no longer runs on a certain software transaction due to changes – and in such cases provides the relevant analyses and evaluations. It is, however, quite possible that a function that has been changed in the SAP application has no impact whatsoever on the test case for a business process that works by using integrated systems from several providers. 

In such instances, an external tool such as HP QuickTest Professional has the advantage of only examining those parts of the system that are actually involved in the business process to be tested. The test case can therefore still be executed – despite a change in the SAP application.

SAP or non-SAP tools?

Non-SAP test tools pass muster particularly in test automation that entails testing integrated business processes with systems from third-party providers as well as from SAP, such as for customer relationship management (CRM) or content management (CM). 

eCATT from SAP immediately registers if a certain test script no longer runs on a certain software transaction due to changes – and in such cases provides the relevant analyses and evaluations. It is, however, quite possible that a function that has been changed in the SAP application has no impact whatsoever on the test case for a business process that works by using integrated systems from several providers. 

In such instances, an external tool such as HP QuickTest Professional has the advantage of only examining those parts of the system that are actually involved in the business process to be tested. The test case can therefore still be executed – despite a change in the SAP application.

Be methodical

But tools alone are no guarantee of success. Regardless of the tools, a methodical procedure model should form the basis of every test automation. This involves:

Automated Software Tests in the SAP Environment

SAP Automation Test, Automated test in SAP, ERP automation test, Testing SAP with automation tools, SAP automation tools, tools for automating SAP, software automation test in SAP, ERP automations tools, automation test tools for SAP, SAP test tools, SAP software testing tools.

Automated Software Tests in the SAP Environment

Highly integrated enterprise software such as SAP is subject to continuous changes in its life cycle – due to company mergers, changed legal requirements, new technologies, or simply upgrades and service packages. Of course, adjustments to the system have to be tested. Ideally, at the touch of a button. But is this type of automation possible and desirable?

 Due to regular release cycles, regression tests are one of the most important types of testing in the SAP environment. They can help establish whether a function that worked perfectly in a previous version continues to work in the new release. In addition, automation can speed up the testing and evaluation processes overall, because regression test cycles are not linked to the availability of user departments, who can then be relieved of recurring – and time-consuming – routine testing.

Before automation

Many people are mistaken in thinking that automated testing makes the impossible possible. However, experience has shown that most difficulties arise before the automated testing itself gets underway – when the correct test cases and test data have to be defined. These test cases must be manually executable and have a defined goal.

To find out which parts of a software solution must be tested repeatedly, the test management team can adopt various approaches:

• Risk analyses detect mission-critical scenarios that must be checked at all costs, if an update, patch, or SAP transport is pending.
• Upgrade/change impact analyses, on the other hand, support testers in localizing and quantifying the expected technical impact of changes.

A fundamental challenge at the actual automation stage involves identifying software objects using certain internal attributes, so that they can be found again during the automation process. In SAP systems, automating tests is relatively straightforward, because SAP objects can usually be identified by their type and certain attributes, such as internal names.

Alternative test tools

Remember… test automation

•Requires the test processes to have a certain level of maturity
•Is a long-term investment and does not generate a rapid return on investment
•Is software development and must be treated as such
•Should be structured in an evolutionary way
•Is primarily based on suitable methods, and then on the tools used

With non-SAP tools such as HP QuickTest Professional or Compuware TestPartner, the automation team can easily access these internal object attributes, even though they are not visible from the graphical user interface (GUI). Aside from these, eCATT (Extended Computer-Aided Test Tool) from SAP can, of course, be deployed. What’s more, various tools can read blueprints from SAP solutions to locate the dynpro or transaction in which changes have been made.

Regardless of the type of software test, test data and executable test scripts must always be strictly separated. The testers create the test scripts. In addition, the test cases should be driven by business cases and be modularized accordingly. 

To ease cooperation between the professional test engineers and the business experts, a keyword-driven automation strategy is also recommended. Using this strategy, the automation activities on the GUI are reduced to just a few key words that are intelligible to all.

SAP Test plan and SAP test strategy download

SAP Test plan and SAP test strategy download

SAP Test plan download, SAP test strategy download, Sample SAP test plan, Sample SAP test strategy document,
SAP test plan pdf, SAP test plan Doc.SAP test plan template, SAP test plan sample template download, SAP test management
document, SAP test integration test plan download, SAP system test plan document download, SAP test plan example, SAP test plan documentation, SAP test upgrade test plan download, SAP performance test plan, SAP test strategy document down load.


Click Here to Download.

Keep visiting for more documents on SAP Testing.

www.nuve.info

Sample SAP test case

Sample test case: Verify Infotype IT0798 created  for an employee

SAP Test Design Techniques

Ø We need to design test cases using different techniques, all the techniques which are used for software testing can be used here

Ø Different test case design techniques used in SAP Testing are

• Equivalence Class Partitioning

• Boundary Value Analysis

• Cause Effect Graph

• State Transition Diagram

• Orthogonal Arrays 

SAP Test Case Characteristics

ØSAP test cases must exhibit the following characteristics and attributes:

§

•Trace back to testable requirements or other existing documentation

       (BPPs, flow process diagrams, technical or functional specifications)

•

• Include preconditions

•

• Have been peer reviewed and signed off

•

• Include SAP role(s) to be used for verifying the test conditions

•

•Include a narrative or description of the test conditions to be verified

•

Contain valid test data (i.e., master data)

Testing and QA Activities for SAP Implementation

SAP Test Types - 4

Ø User Acceptance Testing:

•User acceptance testing allows the system’s end users to independently execute test cases from the perspective of how the end users plan to perform tasks in the production environment.

•The owners of the user acceptance testing are the end users, and the configuration and test team members resolve defects identified during the user acceptance test.

Ø Regression Testing:

•Regression testing ensures that previously working system functionality is not adversely affected by the introduction of new system changes.

•Regression testing is needed to ensure that “nothing is broken” as a result of a new system change. Regression testing is primarily an automated testing effort.

•The test team owns the execution of the regression test.

ØOther types:

•Other types of SAP tests include usability, archiving, data migration testing, and technical tests.

•Technical tests such as backup and recovery, printing, faxing, electronic data interchange (EDI), availability, and so on are also needed in particular for initial SAP implementations and/or global SAP rollouts.

SAP Test Types - 3

Ø Integration Testing:

•Integration testing is the testing of chains of SAP transactions that make up an end-to-end process that cuts across multiple modules, for instance, order-to-cash, purchase-to-pay, and hire-to-retire with external data and converted data.

•Integration testing includes testing through the external systems and SAP bolt-ons with security roles and workflow.

•Integration testing requires participation from members of the configuration and development teams for defect resolution.

•The dedicated test team is the owner of the integration test.

Ø Performance Testing:

•Performance testing encompasses load, volume, and stress testing to determine system bottlenecks and degradation points.

•A performance test helps to determine the optimal system settings to meet and fulfill the established SLAs.

•The dedicated test team is the owner of the performance test. Performance tests are conducted primarily with automated test tools.

SAP Test Types - 2

 Ø Development Testing:

•This is the testing for reports, interfaces, conversions, enhancements, work flows, and forms (RICEWF) development objects developed primarily with ABAP code.

•The development or ABAP team is responsible for planning and executing the development tests, but the configuration team is responsible for approving the results for the development tests

•The development test cases need to reflect the testable conditions from the technical specifications.

Ø Scenario Testing:

•Scenario testing is the testing of chains of SAP transactions that make up a process within a single area or module.

•Scenario testing includes testing of a process with data from external systems and applicable SAP roles/profiles.

•The scenario testing is owned by the configuration teams but includes participation from SMEs and members of the test team and development team.

SAP Test Types -1

ØSAP testing is complex, difficult, and esoteric  

ØTesting at any SAP project is an integrated effort that requires the expertise and skills of several resources such as SMEs, functional configuration resources, ABAP developers, and business analysts

ØUnit Testing

•This is the lowest level of testing at the SAP transaction level

•Unit testing includes boundary testing for positive and negative testing.

•Negative testing should be performed for custom fields and transactions to ensure that the system only allows valid input and can adequately perform exception handling. An example of a negative test for a process would be attempting to process an order with the wrong status

•The configuration team owns the unit-testing effort and is responsible for planning and execution of unit testing

•The main focuses for unit testing are:

■ Master data

■ Negative-positive testing

■ Transaction functionality

■ Security roles and profiles

SAP Testing Material/Tutorials - Agenda

SAP Testing Material/Tutorials - Agenda

• SAP Testing

• SAP Test Types

• Testing and QA Activities for SAP Implementation

• SAP Test Case Characteristics 

• SAP Test Design Techniques

• Sample SAP Test Case

• Screens of a sample SAP test case

What is SAP Testing?

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. 

If you have knowledge in the module (like HR, CRM, SD, SRM), which you are going to test would be helpful to you. 

UAT means USER ACCEPTING TESTING. Suppose end user raised an issues that we solved and send to end used it is working fine. then we get confirmation from him that it is fine. that is call UAT. 

UNIT TESTING - This is done by developer and anyone who did any customizing or any code to ensure what they did is working properly 

INTEGRATION Testing - Done by tester by developing some scenarios which are most unlikely and get the result to ensure the integration is correct 

Apart from that, regression testing, functional testing and other cross functional testing are there done by testers 

In realization phase, unit testing are done by developers 
After unit testing, Integration testing and other testing are done by testers/functional depending upon the object to test. 

Testing usually follows two paths. Firstly, System Integration Testing (SIT) which is performed by the SAP team in the development client, and secondly User Acceptance Testing (UAT) which is performed in the QA client after transport from the development client. UAT is performed by end users or the testing team. 

Unit Tests are defined and performed by developers. A process consists usually of several functions. Each of this function usually consists of "sub-functions" corresponding to a single method or a group of methods (if you are developing OO-based). 

Unit Tests could be described as white-box tests whereas a normal tester (which should be not identical to the developer) will test entire functions (black-box tests). 

--- During the entire life cycle of a SAP solution, it is necessary to test the functions and performance of your solution. With the SAP Test Workbench, SAP provides you with an environment for all test phases, which you can use for testing in the following cases: 

• Implementation of SAP solutions 
• Integration of new components and business scenarios 
• Customer developments 
• Function tests 
• Integration tests with other components 
• Upgrades, regression tests 
• Importing support packages 

Integration 
Features 
Test Preparation 
• Creation of manual and automated test cases 
• Management of manual and automated test cases 
• Creation of test plans 
• Definition and management of test series 
Test Execution 
• Execution of mass tests using Extended Computer-Aided Test Tool and Computer Aided Test Tool 
• Integration of test cases and test scripts of non-SAP providers 
• Assignment of work lists (test packages) to individual testers 

Test Evaluation 
• Permanent overview of test progress and test results 
• Complete documentation of test processes in the test plans (test cases, test case descriptions, test results, test case notes, error messages) 
• Detailed tabular and graphical evaluation of all test plans 
• Export of test results to Office applications 
• Message processing 

Testing usually follows two paths. Firstly, System Integration Testing (SIT) which is performed by the SAP team in the development client, and secondly User Acceptance Testing (UAT) which is performed in the QA client after transport from the development client. UAT is performed by end users or the testing team