Many organizations today use ERP systems to support their customers, vendors, and employees in doing their tasks, such as ordering goods, filing their expenses or changing their personal details in the system. Because these self-service systems (such as parts of SAP-solutions) support the core business without any manual interference of back-off ice employees, the business process must fulfil high quality standards. The people involved in acceptance of these systems (including acceptance testing) often are not professional IT personnel, but key-users, maintenance people or operations engineers. Because of these reasons, acceptance testing requires a specific approach which we describe in this article.
Confidence As The North Star
Self-Service Solutions Require More
EFFORT FOR ACCEPTANCE TESTING. The main goal of testing is gathering information about the quality of an IT solution and the related risks, to establish Two trends in IT today support the implementation of the confi dence the stakeholders have that they will get their large solutions based on ERP systems. One is the limited pursued business value. So, confi dence is the ultimate goal availability of IT people, so that home-grown solutions are of acceptance testing. no longer an option. The other is the limited availability of Confi dence is built using information about the quality back-offi ce people, so that there is a need for self-service level of the IT solution. Step one in acceptance testing is to perform a quality risk analysis to establish what Self-service platforms are a growing trend, allowing users the quality level should be. Risk classes are used while more control over their own activities to create, manage or organizing the tests to mitigate the identifi ed risks, and execute specifi c tasks. It doesn’t require intermediaries to thus determine the quality level. interact with the required service as it is performed using The time available for testing is limited, not everything self-explaining processes or via dashboards. can be tested with equal thoroughness and intensity. The Well-known ERP-vendors such as SAP facilitate rapid number of possible tests in a self-service system is simply implementation of these large solutions. However, there is too large. Teams should focus their testing efforts on the one new risk: if the system fails, there are no people in the high-risk areas fi rst, which are usually the new additions, loop to prevent a failure to cause trouble for the user. So, confi gurations, integrations, and changes. there is less tolerance for failures. Which means that more effort must be put in making sure the system meets the required quality level, involving well-organized and wellperformed acceptance testing.
© by Funtap via Canva.com
& testing we distinguish two general approaches of test
Quality Is A Necessity, Not A Luxury, Risk Is
design: coverage-based testing using structured test
An Important Starting Point
design techniques and experience-based testing using the exploratory testing approach. To effi ciently evaluate the quality of self-service solutions You may wonder: “Why would knowing multiple test like SAP, it is important to know what to test and where the design techniques be useful?”. There are two main reasons: focus of testing should be. An SAP Quality Risk Analysis different test design techniques are suited to different areas (SQRA) is a standardized risk-based approach to determine of interest, and a high-risk area requires another approach the focus for testing. The fi rst step of the SQRA is to than a low-risk area. determine the scope of the platform. Do we need to test the We have developed a certifi cation training course for the complete scope? audience of SAP acceptance tests, that includes four test For a well-founded Quality Risk Analysis, two main points design techniques and exploratory testing (and various of view are relevant: the view of the Business and the view other relevant subjects). of IT.
- The Business input consists of the “Frequency of Use”
Examples Of Risk-Based Selection Of Test
and the “Business Impact”. DESIGN TECHNIQUES AND APPROACHES.
- The IT input consists of the “Process Complexity” and
Awell-known technique for test design is path testing, the “Technical impact”. which determines test cases based on the fl ow of a business process. Path testing has several test depth levels. With a The formula used in the SQRA is shown in the picture high risk class goes a high test depth level. When there is a moderate risk, a lower test depth level is selected. In a low risk situation, the exploratory testing approach can be selected. Exploratory testing means that test cases are not designed up-front, but during the test execution, based on the test ideas from the charter. When the organization does not have a dedicated test team, businesspeople (e.g. key users) and operations & All attributes (“Frequency of Use”, “Business Impact”, maintenance personnel will be involved to prepare and “Process Complexity” and “Technical impact”) are rated perform the acceptance tests. Usually, these people are with a number between 0 and 5, resulting in an SAP quality not professional testers. To ensure that they have enough risk score between 0 and 100. confi dence whether the self-service solution meets the Business & IT stakeholders will rate and classify each user’s needs, the people involved need relevant skills process in scope during a workshop. The outcome of which they can acquire with focused and proper training. the SQRA is input for the Test Strategy and Test Plan. For this reason, the TMAP certifi cation scheme contains Risk class Critical (A) and High (B) classifi ed business the training course “TMAP: Quality engineering for SAP”. processes need extensive and broad testing. Medium (C) This new module is specifi cally designed for professionals and Low (D) classifi ed business processes can be covered with a crucial role in testing, accepting and implementing
by a smaller number of tests.
SAP systems. It is a solid pathway to expertise in quality The outcome of the SQRA can also be used throughout the engineering for SAP projects, and it’s backed by the whole development life cycle. Starting with deciding the practical expertise of a great number of professionals. order for delivering various parts of the solution, going to when to specify tests and when to execute tests, and the risk class is even used to decide which anomaly to solve More information about the fi rst. TMAP training courses:
Test Design With Both Coverage-Based
And Experience-Based Approaches
The key-users, maintenance people and operations engineers that are involved in acceptance testing often More information about don’t start of as trained test professionals. So, they need to TMAP certifi cation: acquire some relevant skills. One major and important skill set is test design. In the TMAP body of knowledge for quality engineering
Rik Marselis Principal Quality Consultant Sogeti Principal Quality Consultant Sogeti Rik Marselis is principal quality consultant at Sogeti in the Netherlands. He is a highly regarded presenter, trainer, author, consultant and coach who supported many organizations and people in improving their quality engineering & testing practice by providing useful tools & checklists, practical support and having in-depth discussions. Rik is co-author of the latest TMAP book “Quality for DevOps teams” and he is the chairman of the TMAP Special Interest Group. Pepijn Paap Pepijn Paap Test Manager ERP/SAP Pepijn Paap is a Test Manager and Subject Matter Pepijn Paap is a Test Manager and Subject Matter Expert for ERP/SAP Quality Engineering. He is experienced in coaching, advising, training, planning, managing, leading and coordinating large and complex global SAP/ERP test projects (implementation, upgrades, migrations, test automation) which brought him all around the globe, participating in business transformations for a wide range of appealing companies. He is the co-founder of the “TMAP: Quality Engineering for SAP” certifi cation.