Advertise here

Key quality assurance considerations for packaged application implementations

Key quality assurance considerations for packaged application implementations

Key quality assurance considerations for packaged application implementations

Enterprises now accept the reality that integrated digital technology signals constantly changing customer experiences, operation models, and business models.

These organisations cannot afford disruptions to the business that consume resources and budgets from new planned activities. However, this is the exact situation many organisations find themselves in when undertaking large enterprise packaged application implementations such as SAP S/4HANA.

The adoption of modern-day ERP, CRM, and HR solutions represents a major technological change as well as a significant cultural change that requires companies to evolve and mature communication, collaboration and change management practices.

The days of undergoing one large application implementation every three years are gone. Change management for enterprise applications must evolve to handle environments where multiple changes are occurring independently of one another, and change cycles are no longer coordinated across applications.

Fig 1. Modern day enterprise change management.

Fig 1. Modern day enterprise change management.

Automation is the only way to keep up with the pace of constant change. Organisations need to automate and run tests continuously across the application landscape to ensure intermittent changes do not affect end-to-end business processes. (Fig.1)

The adoption of Agile and DevOps is another way organisations are dealing with the new state of change. Given that Agile and DevOps both began in the custom-built application space, the processes associated with implementing and maintaining large enterprise applications like S/4HANA are significantly different from those used for custom applications.

Determining how to adopt Agile and DevOps practices to enterprise applications can prove challenging for enterprise application teams. In addition, organisations must also deal with varying UI technologies. Simply because the UI is now web-based doesn’t mean it is going to be like testing any other web application. In fact, many of the new UIs we see such as SAP Fiori are even more complex than their fat client predecessors.

This article will focus on the three most important factors for evaluating business process assurance and automation solutions for enterprise packaged applications.

Automation as accessible to the business as to the application

The reality of today’s enterprise applications is that implementations are complex, time and resource intensive and demand frequent upgrades. Automation that is accessible to both business and IT users is critical to unlocking the benefits of these applications.

Consider the custom application world. Features and stories are created, loaded into Agile management systems and then distributed to scrum teams. Enterprise application projects typically do not work the same. Business process documentation consists of multiple stories joined together to create a feature. This documentation is typically produced by business analysts, who then release the documentation over to IT to use as the basis for test plans. Because of the amount of manual work typically involved in creating the documentation, process teams struggle to keep pace with Agile and DevOps testing cycles.

Further adding to the bottleneck is the fact that test automation for enterprise projects is generally done at the feature level vs. the story level. The finished feature is what the business cares about and is the primary focus for end-to-end testing. At the end of a Wave, documentation for the feature is reviewed by the business user and end-to-end tests are built.

Agile collaboration requires business users and testers to work together in parallel. Solutions like Worksoft’s Visual Capture, which requires no knowledge of testing solutions, enable this type of collaboration.

Business users run Capture to document the stories and create automation while walking through the steps of a business process. Once the feature is complete, test automation professionals then take the associated captures, finish the automation and schedule into continuous testing cycles. (Fig.2)

Fig 2. Scaled Agile adoption for enterprise packaged apps.

Fig 2. Scaled Agile adoption for enterprise packaged apps.

Look beyond automation creation

When organisations begin to consider increasing their levels of automation, the initial focus often involves considering the easiest and cheapest automation options available. However, to be successful with automation – especially for complex end- to-end business process tests – teams need to look beyond merely ‘easy to create’.

They also need to consider how easy the automation will be to maintain, scale, and integrate with other systems and processes.

Tests that don’t easily scale cost more in both time and money and many times leads to the abandonment of the automation effort. Additionally, there is the consideration of whether the automation solution can be used for RPA or production monitoring. All these factors play into the long-term value of the solution.

Maintainability: End-to-end business process tests are multi-step, spanning multiple systems and modules. Critical to the test automation of these extensive processes is the need to minimise the number of and maintenance of tests. The ability to make universal changes to shared objects and sub-processes dramatically simplifies the maintenance efforts.

Comparing new and existing tests to better understand the differences helps in the consolidation of tests. Automation solutions that use scripting as a basis for testing do not provide a graceful method for maintaining tests. Instead, these previous generation solutions require users to create all new tests, abandoning all previous work.

Data-driven tests reduce overall maintenance due to their dynamic nature, reading and applying data to the UI. This dynamic quality decreases the total number of required changes associated with field updates or UI navigation; keeping the report output the same.

Scalability: Testing enterprise applications requires running parallel, unattended, automated end-to-end tests driven from a UI. This creates unique challenges for testing teams. The device running the test needs to be on, and a specific user needs to be logged into the device. In addition, the screen can’t be locked, and tests need to be orchestrated across multiple devices in multiple labs both on-premise or in the cloud.

Choosing a solution that addresses these types of challenges and gives centralised control for running remote tests in parallel, on-demand is critical to scaling to continuous testing.

Integration Support: Implementing Agile-plus-DevOps requires not only for the individual teams to work together, but also the tools as well. No application or automation solution is an island. Solutions need to enable clients to leverage existing investments and integrate with a variety of best-of-breed tools such as continuous integration servers like Jenkins, ALM systems like Micro Focus (HP) ALM, defect management systems like Jira and more.

Brace for Increased UI Complexity

Similar to their client-based predecessors, modern-day packaged applications also come with their own unique UIs. Just because the new UIs are web-based, testing teams should not assume they will be able to test them like any other web- based UI.

UIs like SAP Fiori and Salesforce. com Lightning come with nuances unique unto themselves.

For example, SAP Fiori apps leverage UI5 and use a dynamic UI to deliver customised content based on user roles. In addition to on-going updates to the usability of the application and to expanded business processes, Fiori also presents automation teams with a wealth of challenges including:

  • dynamically generated objects
  • lazy-loading of lists, lightboxes and other controls
  • massive HTML structures– up to 20k tags on a single page
  • customisations made by the user, allowing real-time layout changes.

When looking at the high functionality of Fiori, including the use of tables, drag-and- drop and field-by-field validation, the actual code running the browser is potentially a system fraught with bugs. Updates to the browser can break the complex java script libraries that provide the rich user experience. Purpose built automation platforms like Worksoft Certify are built to follow the applications they support. They leverage machine learning to identify how an application generates UIs and tailors object recognition based on those patterns.

As new versions of the UI are rolled out, the supporting automation is automatically updated. In addition, the automation solution should include things like:

  • predefined optimisations to interact with 300+ different controls
  • automation engine with built-in logic to handle lazy-loading of lists
  • optimisations to handle massive, complex, customisable web pages.

This type of functionality makes it easier to create automation, increase automation playback speed and minimise maintenance by ensuring tests do not have to be recreated each time a new version of the UI is released. (Fig.3)

Fig 3. The value of automated business process testing.

Fig 3. The value of automated business process testing.

 

Updating an organisation’s core systems like SAP has the potential to transform the way they operate and lead in the new digital world. But, with any great change comes great risks.

Ongoing business process assurance enables companies to accelerate change while improving quality. Choosing an automation solution designed to handle the unique nuances of enterprise applications significantly reduces the time to tests, accelerates project completion and generates additional revenue.

Dean Robertson, manager of solution architects, Worksoft

Related Posts

No results found

Advertise here
Menu