# Infosys Whitepaper 
Title: Test Factory Setup for SAP Applications 
Author: Infosys Limited 
Format: PDF 1.7 

---

  Page: 1 / 8  

---

 PERSPECTIVE TEST FACTORY SETUP FOR SAP  APPLICATIONS - Barry Cooper-Brown, Diageo Chandur Ludhani and Sailesh Chandrasekaran,  Infosys Abstract Emergence of IT enabled business growth is compelling  organizations to give testing and testing related strategies the much  needed importance. By now, it has been reaffirmed that the cost of a  single development defect can snowball to many times the original  cost, if not discovered until the QA phase of testing and eventually  showing up in the Production Environment.<|endoftext|>However, when it comes to SAP there are unique testing challenges  to deal with. The challenges of SAP testing will present you with  both tradeoffs that need to be considered and the choices that need  to be made about the kind of testing that is needed for your QA  organization. The following point-of-view has been written based on  the engagement between a major drinks manufacturer and Infosys,  describing a successful approach of setting up a Test Factory to  manage testing of SAP applications.<|endoftext|>

---

  Page: 2 / 8  

---

 Challenges in managing changes in SAP application which indirectly gets mapped  to reaping benefits for all its stakeholders  namely the customers, employees,  shareholders, etc. Often these investments  do not bear fruits and are in turn viewed  as a cost. For example, a delay in readying  the application for regulatory changes,  could lead to serious consequences for the  organisation in the region within which  the changes were mandated. Another  such example could be with encountering  incidents in the live environment or facing  downtime with particular applications  leading to severe business disruption.   Organisations are constantly on the  lookout for innovative ways to help adapt  quickly to these changes in the SAP  business processes. Their ability to do so  also facilitates: • Improvement of  delivery confidence  with every change deployed • Reduction in cost of every change  implemented  • Ability to contract the overall lead time  required for such activities thereby  allowing more frequent releases An organisation’s inability to do so, leads  to a host of challenges to the employees  who interface with SAP for their day-to-day  activities: • Long time for deploying the SAP  changes, means more business  application downtime • Leakage of defects to production–  hampering their day to day operations   • High number of defects detected  during User Acceptance Testing (UAT)  resulting in a delay of final application  go-live.  The question therefore is whether  there is a single and efficient solution  available to organisations in managing  their SAP related QA/Testing operations,  inexpensively and efficiently? The concept of Test Factory and the  offering under the business tag of NEM  (New Engagement Models) is gaining  traction across the globe. The Test Factory,   also an alias for Managed Test Service or  Testing Centre of Excellence, acts as an  independent function in the SDLC; whilst  supplanting the existing set of processes  with benefits of a more agile, efficient and  repeatable set of processes.<|endoftext|>In our next section, we explore the  business needs of SAP enabled  organisations to deploy a Test Factory  model setup for their QA organisation.<|endoftext|>Today’s unrelenting economic and financial  pressures, coupled with far too many  internal and external factors (beyond  the control of any organisation’s circle of  influence), are compelling organisations to  change and tailor their business processes  accordingly. These changes, most often  than not, necessitate a change in the very  supporting business applications itself  (example, SAP, Oracle, etc.)   Acquisition of new business, opening  of new facilities, introduction of new  business line, consolidation of service  lines, Regulatory Changes like changes  in tax laws, changes in reporting needs,  etc., incorporating these changes to SAP is  fairly complex. Any update, even if major,  moderate or minor, needs to be completely  analysed from several dimensions  keeping in mind that these are all large  business applications. The result is that  organisations end up managing projects  involving a high number of interrelated  or moving parts. Further, SAP applications  span geographies and often need heavy  customisations to suit local requirements  (like government, language, etc.) and have  multiple vendors running the applications.  Every investment that an organisation  makes in its IT systems is channelled  towards ensuring a smooth running  External Document © 2018 Infosys Limited 

---

  Page: 3 / 8  

---

 Understanding the Business Need • Inconsistent in application test quality  across teams and  • Lack of usage of appropriate testing  tools 2. Governance Challenges Organisations running SAP are  continuously engaged in taking up  large change programmes or rolling out  applications to newer regions. A large  change programme or rollout requires the  QA function to constantly generate status  reports and deal with various risks and  issues.<|endoftext|>Absence of defined processes, metrics  to track progress, risk management and  inability to consolidate reports frequently,  leads to a governance challenge with  respect to managing decentralised  QA teams. Another common problem  encountered with decentralised QA teams  is with the large amount of time consumed  in assimilating and consolidating  information for status reporting from  various regional teams and resolution  of risks and issues. Further, under the  decentralised structure, teams lack  adoption of uniform processes and hence  there are bound to be differences in the  content and structure of status reporting  and the way risks are identified and   dealt with.  3. High Cost of Testing /  Maintenance Sound testing processes and deep  business knowledge are pre-requisites  to testing of SAP applications. We have  also learnt earlier that a large amount of  effort is spent in running the QA function  for a SAP enabled organisation. Majority  of organisations dedicate a large number  of resources for testing of SAP releases.  In addition to this, SAP testing involves  testing some portions of business  functionalities repeatedly and often  decentralised teams lack the benefits  associated with the reusability aspect.  This can be cited as an additional reason  for the inflated costs of SAP testing in a  decentralised model.<|endoftext|>Project based QA teams primarily look at  testing from a very narrow project point of  view and often miss the holistic implication  of the changes from a complete business  landscape perspective. This leads to high  efforts from the business users during  UAT and large number of defects getting  identified in the later stages of testing. In  addition to this, the non-functional testing  aspects such as Performance, Security etc.,  are also overlooked in the initial phases of  testing leading to high amount of re-work  and maintenance costs downstream.<|endoftext|>4. Lower Delivery Confidence and  Higher Time-to-Market  There is very low confidence on delivery  of release considering the testing in the  earlier phases is not really focussed on  business knowledge. This results in a  high percentage of defect identification  in later stages of SDLC. In the absence of  benchmark metrics, there is no opportunity  to measure the test execution productivity,  often leading to increased durations of  testing cycles.<|endoftext|>While these may sound like age old  problems and issues, these are indeed the  common issues across organisations. These  pitfalls are the reasons why organisations  find themselves grappling with an  expensive and a non-yielding QA function.<|endoftext|>Listed below are some of the common  pitfalls encountered by SAP enabled  organisations in running their QA functions - 1. Decentralised Testing This model of testing is usually prevalent  in organisations which have undergone  mergers or made acquisitions. Testing in  such organisations is carried out using a  decentralised model where no common  testing processes and methodologies  exist. Each Line of business (LOB) has its  own processes and differences exist even  within units of the same LOB. In most cases,  testing is managed by the development  team itself, being aligned directly to each  project.<|endoftext|>This model does not provide clear  delineation between the build and test  functions. If there are any inefficiencies  or delays in build, then the same is  compensated for in the testing phase by  either compressing the testing timelines  or by moving forward with inadequate  coverage of business scenarios. Individual  teams often adopt the approach of testing  with a self defined set of testing processes  and scope limited to their project. The  result is the lack of co-ordination when it  comes to delivering together with other  ongoing projects. This not only results in  severe delays in the programme go-live,  but also leads to a severe compromise of  the quality and quantity of testing that  is necessary.<|endoftext|>Most common limitations of this approach: • Lack of defined uniform testing  processes and global governance  based on metrics • Duplication of test effort  • Non – conformance of testing timelines External Document © 2018 Infosys Limited 

---

  Page: 4 / 8  

---

 So, What is a Test Factory? Having