SAP AUTOMATION WITHOUT THE COMPLEXITY

Transcription

1 SAP AUTOMATION WITHOUT THE COMPLEXITY WHITE PAPER OCTOBER 2012

2 CONTENTS CONTENTS Introduction 3 The Fundamental Problem 4 Things Are Getting Better But 5 The Brave New World 6 The Process To Achieve Utopia 7 Conclusion 9 CONTACT ODIN TECHNOLOGY Tel: +44 (0) info@odintech.com Fax: +44 (0) Odin Headquaters: Odin Technology Ltd. Atlantic House, Imperial Way, Reading, Berkshire, RG2 0TD, UK

3 INTRODUCTION SAP is arguably the most sophisticated enterprise software package to manage business operations and customer relations on the market today, covering resource planning, analytics, data and business warehouse solutions, offering complete business applications integration and management functionality with the ability to tailor and scale its products to specific business requirements of all sizes. These powerful features are like Manna from Heaven for the business users, but their complexity and scale present additional problems, causing basic release testing and rollout of new features to become just the opposite! Due to the level of integrated functionality and the need for continuous change, SAP testing can be a nightmare hence the real need for automation to play a major part. Additionally as SAP has frequent releases, the need for regression testing is paramount, as once again, this needs to be automated for any business to take advantage as quickly as possible of new functionality. Statistics from Worksoft1 show that for large organisations with thousands of users, the effort and time for an SAP upgrade have been estimated at 3,350 days over 31 weeks, at a cost of around $1.4m. As a result 42% of companies fail to realise half the business benefits they expected, with 40% experiencing major operational disruption after going live. As quoted in Panorama ERP paper2 reports, the cost of testing activities is between 30-45% of a global SAP deployment project and around 80% of a migration project. Also, around 93% of the ERP projects are extended and only 35% are within budget. This is compounded further by the fact, according to IDT3 that a staggering 85% of automation efforts fail. With SAP powering the worlds businesses across all industries and locations, the need for cost-effective, quick, simple automation solutions without the immense rate of failure is of prime importance. This white paper discusses the evolution of the way in which this problem can be solved. So an automation solution to the problem that is proven, repeatable, cost-effective and actually delivers is required. 1 - Source Worksoft The Seven Deadly Sins of SAP Maintenances 2 - Source 2008 Panorama Consulting ERP report

4 THE FUNDAMENTAL PROBLEM So what really is the underlying problem relating to existing approaches to automation? Well in a nutshell it relates to complexity of the approach to automation. In effect given the complexity of the SAP application and square that by the difficulty of getting successful automation means a pretty mean equation for failure. Existing automation approaches are effectively System Development or engineering project based on Software engineering values. They tend to have the following attributes: i) They rely on a technical approach based around scripting. Scripting is the same as programming thus technical resources are required to fulfil the requirement. ii) As with all technical approaches, standards are required and an infrastructure needs to be put in place in order for it to have any chance of success these include: Coding/scripting standards Identification of common function Version control/check out and check in processes Release management and control Change management iii) Testers and business users who know the process need to specify to the technical team what needs to be scripted to meet the business requirement. This immediately means change of ownership with the resultant deliverable frequently not accurately reflecting the requirement iv) As the process is a one-way street to a deliverable, the business and test team cannot be sure of the accuracy that the business requirement has really been scripted or delivered correctly. This causes a detachment from the actual reality of what is being tested which can only be further compounded by subsequent maintenance and change requirements v) Maintenance is now not at the business requirement level and the subsequent (and frequent) changes required are accommodated by maintaining scripts with all the inherent problems this causes especially at the level of understanding somebody else s code So if we accept that the traditional approach is too complex to work with a complex application, then there has to be a better way!

5 THINGS ARE GETTING BETTER BUT There has been a move over recent years for a number of automation related suppliers to start to solve the problem but has the problem really been bottomed out? Because of the ingrained approach to automation, a number of solutions to the problem do go some way to alleviating the pain associated with SAP automation, but rather than solve the complex equation referred to in the introduction, they have merely provided an alternative solution which still relies on proprietary technical solutions, usually based around GUI scripting. As such, although this initially provides an easier to implement solution, the fundamental technical issues of scripting still remain. In practice, the initial scripting problem has been shifted to another scripting problem, and whilst this may seem closer to the solution, the fundamental approach is not improved and is therefore no different through the eyes of a layman and does not contribute to providing a true business impact. The new proprietary automation approach is generally based around simplification of test creation through its own GUI. This is then used to create a proprietary script to be driven by the automation tool against the application under test e.g. SAP. The problem is that underlying components need to be scripted to make the tests execute correct and so the need for a predominantly technical workforce still remains. The good point about these tools is that it has a subset of generation techniques in place but relies on a technical infrastructure to be in place before tests can actually be written. So in reality it means that although moving in the right direction, the real requirement to remove the technicalities and allow end business users to run their own scripts has not been completely achieved.

6 THE BRAVE NEW WORLD A number of factors in this complex problem need to be resolved before the complexity squared equation can be completed. Understanding that some key factors that need to be resolved, there are some basic questions to answer: How do we minimise the technical input required to create scripts immediately executable against our SAP application? How do we transition from a development centric automation approach to one where testers and business users are self-sufficient? How do we provide the business user with evidence that our tests and coverage actually meet the business requirements, in a form they can readily understand? How do we achieve scalability of tests against what is the mountain of all applications, easily and in an auditable way? How may we provide a test process, which works with not only SAP, but also with its many integrated applications to give a full endto-end process test capability? There may well be many more issues to solve but the above provide the nub of the problem, which we hope to resolve in this section. More importantly how do we become the survivors of the high rates of potential failure that have been proven to affect all automation projects and more importantly to get over the second hurdle the high level of SAP related failures? Test automation seems a natural fit for SAP, with a standard UI and a logical, modular structure. However although a number of test automation tools already exist on the market there is still a high failure rate overall and this applies to SAP automation as well. In trying to answer the questions posed above, then let s start with the answer that a paradigm shift is required from technical to non-technical. In addition, let s ensure that the approach is business-centric in that given the business usually pays for it that it should also be able to understand it. What if we also decided to move away from programming and programmatic constructs and system engineering based approaches to one where non-technical testers can define and maintain tests in a simple, natural language based Microsoft Excel table? Given the features and functionality of Microsoft Excel, if we could exploit them, use them in our tests and use the rich replication facilities then we would go a long way towards being able to produce much better coverage for the all too familiar multiple routes through SAP scenarios. The next step would be then to use code generation techniques to produce SAP GUI scripts and documentation. This means that the testers are now empowered to leverage the testing capabilities within SAP without the need to be technical or write code.

7 THE PROCESS TO ACHIEVE UTOPIA So how do we shift from technical to non-technical testing, where end users and business managers control their own tests using simple tried and tested tools? At Odin we employ a six stage logical process to achieve this goal: Have a full overview and understanding of how the automation process works with SAP Define the requirement and its link to the related test(s) in the ALM environment (if present) Define the test detail against the simple natural language based in Microsoft s Excel Generate SAP GUI scripts and documentation Commit the assets to the ALM tool (if present) Execute and analyse the results 1. UNDERSTAND AS AN OVERVIEW Axe (Odin s automation platform) works alongside the SAP GUI and Excel, accessed through a tester s workstation. At the start of every automation project, the technician has a critical role in setting up the Axe project and defining the way the SAP GUI looks for the scope of the automation in hand. The technician then generates the templates required for the tester to subsequently populate with the required test scenarios. 2. DEFINE THE REQUIREMENT. As the client may use different ALM tools from the industry leaders (such as HP, IBM or Microsoft) these may be used as a repository to test documentation and project assets beyond their normal functions of providing requirements traceability and reporting. Using a high-level test description, we leave the test management tool input to the generation step to produce the detailed steps. 3. DEFINE THE DETAIL.. By employing simple Excel structures, a non-technical tester can define a range of tests, from very elementary test scenarios to complex integrated end-to-end processes. As an additional benefit, Excel features and functions may be used to rapidly and cost effectively enhance the test definition and design process. 4. GENERATE THE SAP GUI SCRIPTS. Axe uses sophisticated code generation techniques to interpret the Excel spread-sheets, and generates fully functioning SAP GUI test scripts. At the same time detailed design steps (in up to fifty languages) in natural language are generated to document the tests, providing management and users alike full audit trail without the need for technical resource. 5. COMMIT THE ASSETS. All assets may be managed and checked into version control systems provided by the ALM toolsets. The generated documentation may be uploaded into the test management areas of the ALM tools allowing the test detail and its constituent steps to be loaded up with the minimum of effort. 6. EXECUTE AND ANALYSE The final stage is for the test to be executed automatically against SAP, as often as required, as if an expert SAP scripting technician created each script. The execution results may then be imported into the supported ALM tool automatically, or used in subsequent reporting. Axe truly leverages the strengths of SAP testing features without the complexity, costs and resource demands of other approaches.

8 CONCLUSION There is no doubt that the use of code and document generation simplifies the whole overall approach to automation, where it reduces the level of technical input required whilst providing true business impact in ensuring the highest level of quality and integration with ALM tools. The simplification completes the ability to make the paradigm shift from the current technical system engineering approach to one owned and delivered by the testing and business community. The result overall of this is the fact automation can now be undertaken without the massive risk of failure which current approaches unfortunately provide. By utilising the facilities that are provided by SAP through their GUI interface means that the use of proprietary additional tool sets is bypassed, and by the use of Axe, that a standard process for test automation across a business or organisation is now a reality rather than a tale of two cities because SAP has always been different. It is time to consider stepping into the Brave New World!

9 A NEW BREED OF TEST AUTOMATION TOOLS ABOUT AXE AXE TESTING SOLUTION Axe is a cost-effective, simple, disruptive technology with an impressive list of very large UK-based organisations successfully using it across all industry sectors. Axe is quickly becoming a global brand with clients in the US, Africa, Australia and Europe. Axe retains the use of Excel spreadsheets for test design, as 96% of testers use it daily. The spreadsheets are saved and the Axe generator invoked to create and run an executable test with supporting documentation. Reporting generates HTML files for easy access by all team members. Tests are stored in the ordinary file system. There is no database repository. The various maps that are required to support the actions are also Excel based spreadsheets. The advantage is that it is extremely easy to implement, open for modification for nonstandard applications and environments, and easy to integrate with any existing testmanagement and source-control systems already in place. Non-technical users will have no trouble working with its optimised action word methodology, assisted by out-of-the-box spreadsheet templates for test design that largely overcome any problem dealing with complex scenarios. For more information, Please see CONTACT ODIN TECHNOLOGY Web: info@odintech.com Tel: +44 (0)