Can Automated Testing Promote Agility?

Let’s say you’re a telco operator pushing out a change to your billing platform. For many in the business world, the hope for a project like this is that the team behind it has a certain level of agility, meaning that they’re a cross-functional group that’s empowered to solve problems in a flexible manner within the company’s larger mission.

Unfortunately, agility usually isn’t what we find in cases like these. Instead, we find “waterfall” projects where teams are constantly waiting for approval, wading through red tape, and carrying out pre-agreed plans even as potential challenges and hurdles come to light.

The operative question is: how do you make that happen? From our perspective, one potentially advantageous starting point is by automating your tests. How will that help increase agility? Read on to find out!

Regression Testing Powers Early Bug Detection

Right now, increasing device fragmentation and the introduction of new technologies and protocols into the telecom domain are combining to make service verification more complex—and thus more time consuming—than ever before.

Test engineers operating manually are able to run through fewer and fewer test cases per day on average, meaning that testers are likely to be racing against time in order to meet minimum standards of test coverage.

As a result, the balance of probability suggests that most the bugs that testers uncover won’t be caught early on (because earlier they will, no doubt, have been focusing testing resources on other things, or will have been too busy performing the typical duties of an engineer working on a service update).

Thus, by the time service issues are uncovered, it will costly and complex to fix them—leaving decision-makers with an incredibly onerous choice to make: push out the update with the flaws still in tact, or push back your release in order to address the issues more comprehensively.

It’s easy to see how this might turn into a vicious circle of rushed testing and delayed releases. Logically, the only escape from this cycle is to increase the number of test cases you can perform each day from half a dozen per engineer to hundreds or thousands.

Automation provides businesses with the ability to do just that, thereby making it possible to test not just far in advance of the go-no-go decision, but continuously over the course of a given project. Rather than testing only in the immediate lead up to a release, you can actually perform continuous regression tests on your network, devices, BSS, etc.

In this way, you’re much more likely to uncover issues in your provided services well in advance of upcoming releases, meaning that you’ll be able to address them on an ongoing basis, likely before they become critical. Your organization will find bugs earlier and earlier in the process, and the resultant fixes will likely be cheaper and more effective as a result.

Instead of panicking under impossible time pressure, you can think strategically and creatively about each new iteration of your release.

Reporting for Operational Cohesion

Of course, agility isn’t just about moving quickly and making collaborative decisions. After all, the typical “agile” model only works if each of the divergent agile teams within a particular organization are all on the same page and working towards the same goals.

With larger organizations, this can be a more difficult task than you might imagine. As such, it’s far from uncommon to find instances of teams working at cross purposes—one working towards one goal, and another working towards another goal that’s in direct conflict with the first one.

Two separate teams might, for instance, be taking customer account set up and invoicing in two completely different directions that will eventually come into problematic contact.

Sure, this is partially an issue of oversight and communication across teams, but it’s also a matter of building a common narrative for teams to latch onto. That narrative needs to communicate not just where the company is going, but how it intends to get there and why.

Service verification might not seem like it should factor terribly strongly into these narratives, but at a company that has robust reporting and documentation for its tests (something that tends to go hand in hand with automation), it can actually play a significant role.

How? By providing a visible, easy-to-understand, and easily shareable vision of what’s working and what isn’t across your entire network. With manual testing, this information is always at risk of being locked in a silo, but in an environment that boasts end-to-end test automation that contingency is far less likely.

Empowering Engineers Through Saved Time

Okay, we touched on this idea a little bit above, but it bares an explicit mention: automation saves countless engineer hours, which those engineers can then spend doing more agile and productive work.

Rather than being tied to their desks trudging through a seemingly never-ending stream of use cases requiring verification, your most valuable assets (i.e. your people) can finally be given the time and flexibility to be truly agile.

After all, it stands to reason that in order for a particular cross-functional team to be truly agile and adaptable, the individual members of your team must be able to do likewise.

So, let’s turn back to our opening example for a second. You’re a telco operator trying to change your billing platform—but this time you’ve got test automation in place. Because your engineers aren’t bogged down with service verification tasks each day (and are instead able to simply direct the testing solution towards the relevant use cases and wait for results), their time and mental energy can suddenly be freely devoted to creating the best possible product.

Perhaps they think of a change that could radically improve your user interface, reducing customer service calls and saving money in the process. Or maybe they’re able to optimize their code to improve load times, helping to reduce unnecessary network load.

Either of these improvements—to say nothing of many others that could easily come about in an agile environment—would add real value for your company. And they would have been much more difficult to come by without automated testing.