Regression Testing for Network Quality

Network demands have grown increasingly complex in recent years. For example, people’s reliance on smartphones for everything from navigation to mobile banking means that networks must be more robust and secure than ever. Meanwhile, the proliferation of IoT-enabled devices has introduced new protocols and device configurations.

As a result, regression testing has become more time consuming and expensive. But it has also become all the more critical for ensuring consistent network quality; accelerated changes mean more patches and updates that can introduce bugs or negatively impact network performance. Indeed, regression testing can eventually come to include thousands of individual user-interface (UI) tests that must be run in cascading sequences.

Choose Regression Test Cases Wisely

Increased network complexity directly correlates with increased feature test cases. All too often, telcos will simply dump all these feature test cases into their regression test case suite, leading to a totally unmanageable number of regression test cases–and to engineers’ testing only critical features.

Instead, the team should select regression test cases based on a strict set of guidelines to streamline the process while addressing full functionality. Appropriate test cases fall into five categories:

• Failure test cases: Choose enough unique failure test scenarios to ensure network robustness. A good rule here is to choose test cases that are error-prone and tend to fail after even the smallest updates.
• Integration test cases: These should all be included because they cover multiple functionalities and therefore eliminate the need for simple functionality cases.
• Complex test cases: All of these should be tested since one complex test case can cover multiple functionalities.
• Boundary value test cases: To test for vulnerabilities to errors introduced by external systems, all boundary value test cases should be part of regression testing.
• Successful test cases: To eliminate multiple tests of the same functionality, include only a representative sample of successful test cases, rather than all of them.

Note that the primary goal of this exercise is to eliminate redundancies. For example, it is unnecessary to run a test on call origination functionality if there’s a second test case for mobile call handoffs; this second test will also fail if call origination isn’t functional.

Meanwhile it’s also important to systematically remove obsolete test cases, which can accumulate quickly in today’s fast-paced technological environment. Each time new feature test cases are added, take the time to remove those that are no long relevant or that are covered by a newly added test. Obsolete cases also include those that are specific to bugs or failures that have already been resolved.

Introduce Automation to Further Reduce Effort

Regression testing requires significant time and effort. Errors are often made during set-up and configuration, requiring QA and rework. And testers may have limited knowledge of the process, slowing the process. However, multiple steps of regression testing can be automated, dramatically reducing the time and cost of the process:

• Regression test setup
• Test case execution
• Test result verification

Additionally, automated regression testing allows batched execution, that is, multiple tests can be conducted simultaneously, instead of one at a time. Regression testing can also be scheduled to occur outside regular office hours, with no manual intervention required.

Learn More About Test Automation

Click below to see how SEGRON’s ATF can help you automate testing.