In quality assurance (QA) testing for new applications, it is often the case that there are more buttons that need pushing, or tests that need running, than there are testers to push the buttons in the timeframe by which those buttons need to be pushed. When teams encounter this, there are three common reactions: 

• Don’t push all of the buttons
• Take all the time
• Hire more button pushers

Since there are plenty of projects that have tried one or more of these options, the question really is “do any of these approaches work?”

Don’t Push All of the Buttons

The first approach is to only focus on pushing the important buttons, or doing the important testing. Testing might not get completed, but you’re probably going to ship on time. 

If we don’t push all of the buttons, or do all the testing, what could possibly go wrong? We end up with incomplete testing, which results in delivering poor-quality software, which results in unhappy users. Overall, this approach does not work. 

Take All the Time

The second approach is to use as much time as needed to test until you can’t think of any more tests to perform. You keep testing until the entire team is sure there are no more buttons to push.  

If we take all the time to do all the testing, we may deliver a wonderful application, but it will probably be too late to market. This approach also doesn’t work. 

Hire More Button Pushers

The third approach is to hire all of the button pushers you need to ensure that you push all the buttons and deliver on time. 

If we use this method, our project will be expensive and the testing may still not be very effective. Once again, this approach simply doesn’t work well.

Obviously, we need to push all the buttons, deliver on time, keep our budget within reason, and keep our testing focused. So what else can we do?

Leverage and Cloning

To ensure thorough QA where testing is completed on time, is accurate and effective, and under budget, we need to focus on two things: 

• Target for Efficacy: We target our testing to make sure we prioritize the most important, user-focused tests to create leverage, or a good ROI (return on investment) on QA. 
• Low-cost Repeatability: We create low-cost, repeatable tests by cloning low-cost button pushers. 

Creating Leverage

The first step in creating leverage is to target our testing. In testing, there are typically two schools of thought: you can focus on testing each individual element on its own or on testing the application holistically. I tend to focus on the second approach to maximize ROI for time spent testing. 

The developers check their code before they merge it, so we want to mak sure we don’t completely duplicate their efforts. And although it is important for QA to also confirm that each element is working correctly, if we can validate the end-user experience end-to-end, then we can presume that the individual elements are also working. 

This focus on the end-user experience is known as user flow testing. The user flow methodology prioritizes testing the product in the same way that the user will use it. It highlights the areas that are not working by approaching that testing as the user will experience the application. Leaving unit testing to developers and holistic testing to QA optimizes efficiency by making the best use of the team’s efforts.

Narrowing our efforts to prioritize user flow testing to create leverage reduces the amount of button pushing we need to perform, but it’s still not enough to ensure adequate coverage for each release. We still need more button pushing. This is where cloning comes in. 

Cloning Button Pushers

In order to clone our button-pushing expertise, we build tests that we can run automatically over and over again while we execute other tests. In order to do this, we tell a computer program which buttons to push, how and when to push them, and what to expect once they’ve been pushed. Once we’ve done that, we can run those tests as many times as we want while we focus on other priorities. At this point, we’ve effectively cloned ourselves by imbuing a computer program with our hard-won button-pushing expertise. 

However, this cloning highlights a critical issue we still need to address. You see, we can tell the computer program which buttons to push. But we need a way to tell it how and where to find the buttons that need pushing. 

Historically in testing, the methods used to determine which buttons to push have been problematic. They focused on:

• The button’s location on a screen
• One button’s position relative to other buttons on the screen
• An attribute of the button, such as its class or its name

The problem is that all of these button-locating methods fail when the application is updated. When the button-locating methods fail, the automated tests fail and need to be updated. This means that every single test has to be updated any time the application receives any updates.  

If we have to update our automated tests every time there’s a change to the software, our time allocation and budget skyrocket while the actual number of tests we can run goes way down. If our clones never get to go out and push the buttons they desperately want to push, there’s simply no reason to even create the clones. They just sit around and wait while we continue making adjustments. This prevents us from using any leverage, and we’re left with the poor outcomes discussed above.  

Empowering Clones

Fortunately, we solved this challenge of empowering clones by implementing the use of custom data tags, known as data-philters. As new pages or features are developed, our diligent developers add these data-philters to each attribute we might want to test. 

These custom data-philter tags are created specifically for use by QA for the purpose of automation testing. Since the data-philters, or custom IDs, don’t change when the application is updated, software updates no longer disrupt automated tests. This means  we can spend our time creating, rather than fixing, tests and empower our large-fingered, button-pushing clones. This process keeps test maintenance low, which allows QA to gradually increase automatic coverage without increasing the number of testers on a project. This is a continuous cycle of creating leverage.

Writing automated tests that tell the program how to reliably find the buttons you want pushed and narrowing test execution to only the buttons that are of interest to our users gives us targeted tests that can repeatedly run on their own. This means that we’ve created a fourth approach, one that allows us to fully leveraged tests and cloned button-pushing expertise. Now, whenever the application is ready to be tested, we unleash our cloned large-fingered button pushers and within minutes let developers know whether the build is ready for promotion.

When executed properly, cloning and leverage are a powerful pair. At Grio, we can apply that approach to any project at any time. You can find out more by exploring Our Services.