In pursuing the twin goals of increased speed and continuous innovation, delivery teams have been busily ramping up automation efforts in the last few years. Test automation has been instrumental in helping accelerate release cycles, improve software quality and increase efficiency across the whole software delivery lifecycle (SDLC). However, although test automation is a key step in helping enterprises attain cloud-based native continuous design and deployment, it’s also creating a conundrum for software teams.
Author: Sivakumar Anna, Infostretch, https://www.infostretch.com/
Anyone who has worked in a traditional SDLC environment will be familiar with the “definition of done”, the point at which a set of pre-agreed requirements are met and the project, or user story, may be considered complete and we move to the next phase. In Agile development, working within sprints, delivery teams need a clear checklist to ensure they remain on track with the intended design. The definition of done should be specific to that particular story or feature, but also conforms to the organization’s wider business goals or security and compliance requirements.
Typically, test automation has not featured as part of the definition of done.
Fast and Furious Sprints
The focus in sprints tends to be on creativity and speed. Because test automation has not been part of the brief, it often rolls over until next time or is tacked on towards the end.
However, as software ecosystems become increasingly complex, teams that automate testing late in the process actually store up issues for themselves in the form of technical debt. And, as is often the case when it comes to software bugs, problems that are discovered later usually take longer to unravel and fix. Anyone who has had to work late fixing a surprise system error will know that technical debt is something we really want to minimize.
Yet, while clearly no-one wishes to build up issues that will come back to bite them at some point in future, there are good reasons that technical debt mounts up. Technical debt occurs when teams take shortcuts to achieve an outcome within a desired timeframe. The “debt” refers to the time it takes to rework it at a later point. It’s an inevitable part of the Agile process because when we prioritize speed over perfection – think minimum viable product (MVP) – technical debt eventually builds up.
Automating-as-you-go is a sensible approach to prevent storing up issues in the long run, but one that software teams have struggled to turn into a reality. Not only is this automate-as-you-code strategy better at helping organizations stay lean, agile and efficient, if executed correctly, it helps teams deliver better quality code that matches (or exceeds) everyone’s original expectations.
Shifting Left With Test Automation
Agile brought testing to the fore. No longer an activity that was tacked on at the end of the development process, Agile practitioners are well-used to collaborating closely with manual testing experts. As the testing process increasingly benefits from automation, it would make sense to shift test automation left.
In reality, however, many software teams have something of a blind spot when it comes to automating within Scrum sprints. The hesitancy around in-sprint automation stems from the assumption that it is best done when a product’s finished or at least stable. However, redefining done to include test automation is not only possible, with a few adaptions it can help teams delivery more efficiently by avoiding repetitious processes and incorrect assumptions. And, contrary to popular belief, it is possible for automation to work in parallel with the development process.
In-Sprint Automation In Practice
One of the largest healthcare providers and insurers in the USA incorporated in-sprint automation as part of its digital transformation. It used this approach to build three of its major platforms: the pharmacy inventory management platform, the collaboration platform that enables information sharing between different healthcare divisions and the voice-activated patient-physician tool. The design, development and delivery of these digital solutions enabled the provider to realize rapid improvements in patient care and resource utilization, including 20 percent cost savings due to the elimination of manual processes.
Organizations do not need to embark on landmark digital initiatives to reap the benefits of Shift Left test automation, they can become significantly more agile in their everyday software design and delivery by focusing on steps that embed automation into process earlier. The beauty of this approach is that, with just a few adaptations, test teams can incorporate test automation into their practices as part of their definition of done.
1. Bring in the automation engineers
Start by inviting the automation engineers to sprints, talking to them and then, based on those discussions, formulating a definition of done that includes test automation as part of the checklist. If this sounds obvious, then that is because on one level, it is. However, when it comes to effecting change, team culture can make or break an initiative. When an organization includes automation experts in the project from the get-go, it ensures those engineers come away with a much more granular understanding of the vision, the goals and the challenges because they’ve had a chance to work closely with the relevant developers and product leads. And, by including test automation as a condition of success, your organization is sending a clear signal that it’s serious about delivering better software.
2. Collaborate, then separate
Inviting the automation pros into the development phase is the first step, but it doesn’t guarantee success. It’s then down to the automation engineers and the developers to find a way of working that’s mutually beneficial, which means talking, understanding each other’s expertise and priorities, setting expectations, boundaries and goals. Once they’ve mastered this form of close, collaborative working, the test automators should have enough information to get going even without having all the finished code at their fingertips. In other words, close collaboration initially enables parallel workstreams, because all parties are confident about what they’re working towards.
3. Select people with skills suited to sprints
Automation engineers automate, right? Wrong! At least, that is only part of the story. If you want to maximize their impact within a sprint setting, it’s important to select people who not only ace the automation part of their role, but can collaborate effectively, understand user stories, can listen and interpret product requirements and are sufficiently skilled at testing and code writing to be able to work with those testers and developers.
4. Select the right tool for the job
There’s no shortage of choice when it comes to automation frameworks. Be sure to select one that fits your needs. Consider, for example, that it should be easily accessible by all involved. It should enable automated tests to be written flexibly, for instance, without necessary involving the UI. Finally, its capabilities must support your organization’s wider delivery goals (like continuous testing, for example).
5. Balance automation priorities
Remember the speed / perfection trade-off when designing an MVP? In a sprint setting, participants need to be selective about what they build, test and automate. Strategic prioritization in this scenario is not only desirable, it’s necessary to ensure success.
With these adjustments to the Agile methodology that is typically deployed in most large enterprises, we have found that it is possible to bring automation into the mix at a much earlier point in the SDLC. This change can take a little getting used to, both by the automation engineers and the dev and test teams, but, once in place, it results in multiple benefits.
Test automation is a proven force for good in software development and delivery. Increasing automation helps improve testing coverage, results in better software and speeds up release cycles, as well as saving testing dollars and time. As software ecosystems expanded in complexity and continuous pipelines, the SDLC has become dependent on the automated testing.
Despite this, software teams have tended to rely on implementing automation after the initial stages of development. This runs contrary to the principles of Agile development and the Shift Left mindset. Shifting test automation left, into the scrum phase, results in much more efficient software development and, what’s more, is relatively easy to achieve, with a few adjustments in how teams are formed and how they collaborate.
About the Author
Sivakumar Anna is Senior Director of Enterprise QA at Infostretch, a digital engineering professional services firm. He has 25+ years of Technology Transformation experience in automation services across multiple verticals (BFSI, Healthcare, eCommerce, IoT Device Platform, and Business Process Automation).
Contact SoftwareTestingMagazine.com if you want to contribute quality software testing and software quality assurance content on this website.