Eight Common QA Pains Eliminated: Flaky Tests, Limited Parallel Tests, etc.

Apr 15, 2021

 

If your team suffers from common QA pain and developer pain points, such as excessive Developer Rework, Flaky Tests, Developer wait-time, frequent Context Switching, limited Parallel Testing, and high Infrastructure costs… you’ve come to the right place.

Developer and QA Pain is REAL and it hurts output!

After 15 years in the software testing space, we’ve learned and developed a strategy that cuts right into these eight common qa pain points.

The strategy is simple – introduce Intelligence into your current software testing practice.

qa pain

By turning your legacy software test practice smart, your team will experience all the benefits and cost-reductions Machine Learning can bring to software development. This is the method how Tech Titans, Google and Facebook, run their QA…why not reap some of the benefits for your own team?

We will refer to this strategy of introducing Intelligence into the current test practice as “Smart Testing.”

Smart Testing automatically determines and executes only the tests associated with recent code changes, thereby removing the need to run the entire suite. By running only the important tests, results are available to share with QA and Developers immediately. Why run 500 UI tests, when only 30 were affected with the latest commit?

Let’s dive into where Smart Testing helps alleviate common software development pain points:

1. Reduced Rework:

Reduced Developer Rework

Rework occurs when developers have to go back to fix former mistakes.

In general, programmers would prefer to write new code than correct old mistakes.

Smart Testing reduces Rework because developers receive test results from QA immediately upon commit. They are able to address defects during the coding/development stage or in real-time. By catching bugs earlier and more frequently, the likelihood of Rework later down the road is greatly diminished. Developer and QA teams celebrate! 

2. Flaky Tests:

Flaky tests are automated test failures that break for no apparent reason or change to the code. This frequently occurs due to several different reasons, such as a browser crashing, a device loses connectivity, updates, etc.

Many QA Teams waste considerable time re-testing failed scripts or Flaky Failures.

When a team is dealing with a large automation test suite, 15%+ of the tests could fail for no real reason. Many teams have policy that requires all automated tests to be passed in order for the build to be released. This leaves QA teams combing through pointless tests for hours which only hurts output and productivity. It’s no surprise that Flaky Tests are frequently the culprit for delayed releases!

Quarantine Flaky Tests

Smart testing automatically quarantines and sets aside tests deemed Flaky, AKA Flaky tests.

By being able to determine flaky failures in the automated tests, Smart Testing isolates, quarantines, and then groups the tests together and raises a singular defect. They are then automatically re-tested multiple times to ensure they pass. Quarantining and re-running Flaky Tests saves Developers and QA considerable time and energy because they no longer have to comb through large automation test suites to determine the cause of failure. They can now pass the build without delay. QA pain eliminated! 

3. Developer Downtime:

Developer downtime occurs when developers are left waiting for test results from Testers or QA.

When a developer submits a change to the application via a new commit, he can be left waiting 10 minutes or 10 hours for test results depending on the size and length of the automated tests. This is a major pain point for developers, QA, and software development teams because it holds up productivity and creates a bottleneck of information from testing. Developers can’t continue working on the same task until they get results back, or else they risk making mistakes that they will later have to correct – AKA Rework.

qa pain

Smart Testing reduces the amount of time it takes to complete the test-suite by over 90%. Therefore, Developers receive results back from Testing or QA within seconds of each new commit.

Downtime is eliminated because the bottleneck of information from the automation tests completing no longer exists. Productivity increases because teams can ship better quality product and hit release deadlines 10x faster. Developer and QA pain eliminated! 

4. Parallel Testing or Parallel Tests

Parallel testing is a method to execute several test scripts concurrently on multiple threads, with each thread consuming different resources.

Running parallel tests is limited in it’s functionality and value due to dependencies between tests, high CPU/Memory demand, and thread limits. Parallel tests sound great in theory, but hold several limitations that cannot be worked around, such as environmental constraints and types of tests being run.

Smart Testing greatly enhances parallel tests by only running the important ones through the threads. Therefore, if teams are able to reduce automation tests lengths by 30% with parallelization, they can achieve over a 90%+ reduction by incorporating prioritized testing, or Smart Testing. These complementary products working together produce extremely strong results in terms of accelerating test results. 

5. Context Switching:

Occurs when team members switch between tasks throughout the day, leading to mistakes and unproductive habits.

Context Switching is exacerbated when programmers have to wait for test results. Research suggests that it takes 15 minutes to get in the zone on a single task, and that any distraction can cause up to a 30 minute burn time in order to get back into things. If a developer is switching between 3-4 tasks throughout the day, they could be burning 90-120 minutes per day just trying to refocus their thoughts.

As Scott Hanselman, Microsoft Dev Leader, once said: “The optimal number of threads in any system is one thread.”

Reduce Context Switching

Smart Testing minimizes Context Switching in software development teams.

Context Switching is minimized because developers receive feedback immediately after their commit. If a developer is waiting more than a few minutes for test results, they are likely to switch tasks or go grab a coffee. But if test results land right back in their lap where they left off (and while still in the zone), developers can continue on without losing focus. Smart Testing gets results back from testing immediately and eliminates the urge to multi-task.

6. Failure Analysis:

Finding and correcting bugs later in the cycle can be exponentially more costly than detecting and correcting them early.

Smart Testing incorporates Advanced Reporting to show where, how, and when bugs were introduced. Plug ins are available for Jira and other popular bug-tracking tools.

qa pains

By testing more frequently and providing better feedback to team members earlier than with current test practices, Smart Testing minimizes the risk of missing defects and discovering them in the later stages of testing. Smart Testing allows teams to catch bugs as they are made, or in real-time. Some may refer to this as Shift Left!

7. Crisis Management and Overtime:

Find a bug late in the day with a pending release?

Catch Bugs Faster

If the team has a long test suite, they will be waiting hours before they can fix the issue. These frequent issues arise continuously, and force teams to work overtime or on weekends.

just run impacted tests

This scenario is all too frequent for software development teams, and is a major contributor to team frustration.

With Smart Testing, the team wouldn’t need to run all the automated tests – just the important ones. The team receives feedback immediately rather than waiting hours. They then can correct the issue and finish work early and release on time. This method greatly alleviates potential frustration of working overtime from occurring within the team.

Map to Bugs

8. High Testing Infrastructure Costs:

testing costs

 

Reducing Costs in the Cloud using Machine Learning

The costs associated with running the tests locally or on the cloud.

It’s no surprise that running big automation test suites chews up a significant amount of resources either locally or in the cloud . Planning is important to avoid high and surprising costs.

Smart Testing significantly lowers the resource tax on local and cloud testing infrastructures. By only running a prioritized set of tests, teams no longer drain local or cloud infrastructures previously done by running the whole test suite. Running only a fraction of tests, say 10%, teams save up to 90% on their cloud and local infrastructure costs. Planning is still important, but saving 90% on your cloud bill does sound nice.

Conclusion: QA Pain Eliminated

Smart testing alleviates the above pain points for legacy test practices through the introduction of Intelligence. By only running a fraction of the full automation test suite for faster test results, teams are far more productive in several areas and can significantly lower costs on infrastructure.