{{announcement.body}}
{{announcement.title}}

Houses vs. Cities: Understanding Agile Testing for Packaged Apps

DZone 's Guide to

Houses vs. Cities: Understanding Agile Testing for Packaged Apps

Using Agile to expedite the release of new development inevitably impacts the existing systems and processes on which your organization depends.

· Agile Zone ·
Free Resource

Using Agile to expedite the release of new development inevitably impacts the existing systems and processes on which your organization depends.

When it comes to SAP, Agile is different and far more complex than the simple apps for which the development philosophy was created. Building a simple app is like building a house. There’s a blueprint for the structure and all the water, gas, cable, and other utilities already exist and are connected with relative ease before someone even moves in.

Upgrading SAP is more like rebuilding a city. You can’t shut off power to the city to reclaim it. The roads have to work. The power has to work. You have to keep the city running while you upgrade continuously.

And that’s what organizations have to do with these major ERP packages like SAP S/4HANA, SuccessFactors, and others. Keeping the business running while you upgrade makes these projects even more complex.  For more details see Agile. Maybe. Sometimes. 

The Overlooked Middle

Let’s break down the terminology associated with Agile. At the highest level, we have Themes, then Epics and Stories. If you use JIRA, IBM Rational, or Panaya, you’ll see that most teams follow this approach. With the plug-in for Solution Manager, you also get something similar. A theme is something management sets upon, an overarching goal. Epics are major pieces of functionality. And Stories are how we break them down into actionable chunks of development.

When you get into Agile, you realize there’s also something in the middle of Stories and Epics: Features. But when everyone is simply looking at their Story cards, Features can often get lost.

Here’s why: Agile development teams go to Story training. A Story might be “I need to process overtime for holiday workers,” or “I need to process overtime for hourly workers,” or “I need to process overtime for regular workers.” In this example, each individual function is a Story, but the fact that those things need to work together can be overlooked.

Those individual functions together form a Feature called “overtime.” That all rolls into a larger Epic, such as “migrate program from PeopleSoft to Success Factors” to support a particular migration or change. Features are where Stories that comprise the interdependent or interrelated components of your business process come together. When working in Agile, we can get so myopic that we forget about or accidentally overlook that middle layer that’s so important.

Understanding Complexity

In the real world, systems like SAP are increasingly complex and interdependent. You don’t want to pave the roads before you build the waterline. But when you’re building a city, the roads don’t exist, the water structures don’t exist. Agile development processes need to include both Stories and Features.

Keeping the business running while we upgrade is where the ability for multiple teams who need to work together but in parallel comes into play. The release train, or Scaled Agile Framework, overlays on top of Agile concepts and adds project and portfolio management. The concept of a release train allows for coordination of multiple features and stories that have to work together in order to release a high-level business process order cache and that there are multiple moving parts.

There could be new web applications to make orders visible to a user, maybe on SAP, or a new schedule of the work process. There must be coordination against multiple Stories to create a Feature. That’s what we roll out in a group.

The Real Impact

Enterprises that depend on complex applications like SAP have thousands of business processes moving in and out of their ERP system, many with the potential for a significant impact on their operations and end-user experiences. 

Sure, some organizations like Facebook and Amazon release thousands of updates a day. But what’s the real impact? If your vacation selfie doesn’t get posted, no big deal. But if you push a change that creates an error in your sales-to-order process or your employee payroll system, someone is going to notice.

Since change is constant and frequent with the potential to impact mission-critical business processes, QA must monitor continuously. A Scaled Agile Framework (SAFe) allows us to acknowledge that there are lots of moving parts and have some governance and coordination across them that includes software testing. The project and portfolio management components of SAFe allow for systematic governance but also align to budgeting and funding for larger projects.

Connective Automation and End-to-End Testing

How does Connective Automation fit in the Agile picture? The first thing we do is determine how we will discover the process. Collaboration with business users and QA helps us discover and document our actual processes.

We want that comprehensive documentation, along with a handshake to a test automation expert. Why? Because they’re the ones who think about the process from a holistic, end-to-end perspective. The automation expert considers potentially negative outcomes vs. just isolated checking of boxes for a single story or goal.

With process documentation in place, the automation team can jumpstart and extract the data to set up end-to-end test creation for regression testing, reporting, and validation.

Remember, change can be fast and frequent in Agile environments. With compressed delivery schedules, there’s rarely time to achieve the desired depth and breadth of regression testing with manual testing. Intelligent automation accelerates regression testing without sacrificing quality, while also supporting continuous testing, which enables the ongoing checks and balances necessary to ensure critical business processes in these rapid release environments.

To combat the fragmented control associated with Agile, Agile testing practices should also incorporate a COE. In addition to creating and running tests, COEs drive tool standardization, create best practices, train users, maintain documentation for critical business processes, and maintain end-to-end tests that cover multiple applications and project teams.

Topics:
agile testing challenges, agile testing. software testing, automated test scripts, devops testing, devtestops, test design, test design automation

Published at DZone with permission of Chris Kraus , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}