This is also visible in the bug reports, which show that some modules have a higher number of difficulties than others. You can look at the bug complaints and figure out which regions are the most problematic.
Similarly, you can investigate user-reported issues that happened as a result of regression testing oversight. As a result, you must concentrate and priorities testing of these risky aspects. During periodic cleanup of the regression test suite, take great care not to eliminate the corresponding test cases. Keep a repository of regression test suites on hand. Create new test cases for each new update or integration and add them to the regression test suite.
Some of the existing test cases can also be moved to the regression test cases list. The purpose is to keep track of all test cases in one place, which should be run during each regression test cycle.
Not all test cases are suitable for a regression test suite; you must pick and choose which test cases to include in your regression suite. One technique to assure the accuracy and efficiency of test suites is to screen test cases on a regular basis. Test cases can be classified as reusable, re-testable, or obsolete to help you optimize your regression test suite.
When it comes to executing successful regression testing, having a well-maintained regression test suite can come in handy.
As we covered in the problems of regression testing section, when performing regression testing, the quality assurance team has limited time, resources, and is under a lot of pressure from management. This will allow the QA to stay on track with their priorities and focus solely on running the required test cases.
You can, for example, eliminate test cases for requirements that are no longer valid. Otherwise, if the original and modified requirements indicate two different things, there may be a dispute. In this situation, you can delete the test cases that were created for the integrated Module AB verification.
Nothing beats random testing at the end, no matter how cautious you were when creating test cases or how many possibilities you covered. Set aside some time to perform random testing on the application. These haphazard tests could cover whole process cycles. You could also put yourself in the shoes of various consumers and try to portray real-world circumstances as users engaging with the system.
This is more of a human resource management issue. Because the quality assurance manager is in charge of a group of individuals, he should be concerned with their motivation and interest.
If the same tester is asked to perform regression testing over and over, he may become bored, indifferent, or acquire tunnel vision. He will eventually lose motivation, and the quality of testing will deteriorate, allowing flaws to make it into the live release. As a result, a preferable strategy is to continuously rotating your personnel and assign regression testing to different testers.
Your email address will not be published. Save my name, email, and website in this browser for the next time I comment. Skip to content. What is Regression Testing? When any of the following situations occur during the software development lifecycle, regression testing is performed: A flaw has been identified and corrected.
The Tech Lead runs the code against a copy of production dataset. Turns out that the new code, which was encapsulated in a function, getPastDueInvoices dueDate , takes 5 seconds to execute against production data. The code fix took 1. The Accounting System was configured with a timeout period of 2 seconds against calls to the Invoice module. See Figure 2. Figure 2: A regression test ensures that new code in one part of the system does not cause unwanted side effects in the system overall.
It turns out the the Developer indeed retested the code fix by way of a unit test. And QA did a high-level inspection but no regression testing was performed.
The fix worked to expectation under unit testing and yet it broke the system when running in production. Had the fix been incorporated into a system-wide regression test that used a copy of the data running in production, the chances are very good that the issue would have been discovered before the release to production.
Thus, the value and importance of regression testing. Regression testing is valuable. Retesting is about making sure that a specific code change works according to expectation. Regression testing is about ensuring that the entire system works to expectation once a change has been introduced. As such, designing and implementing regression tests has a much broader scope of activity than retesting.
Typically, retesting occurs quickly, at or very near the time code is being created. Regression tests take place further along in the SDLC when more time is available to accommodate the longer timespan required to execute the testing. Yes, some retests can be quite complex and time-consuming, but nowhere near the length of time required to execute a comprehensive regression test. Remember, adequate regression testing means that all aspects of the system must be tested and just as importantly, monitored.
Performing a regression test without adequate, system-wide monitoring in place turns the testing effort into a guessing game. As we demonstrated in the opening scenario, an error can occur in one part of the system, yet be caused by behavior in another part. Adequate monitoring gives you the insights into the system you need in order to determine problems and root causes. The case for regression testing is strong. However, implementing one under Agile can be hard.
The goal of Agile and DevOps is to get working software into hands of users as quickly as possible under short, fast release cycles.
Yet, regression testing takes time, maybe more time than a single iteration can allow. One solution is to stagger the regression testing between iterations. Figure 3 below shows a timeline of three iterations. A code version is released in each iteration. However, regression testing the code created during the iteration starts halfway into the iteration and continues into the following iteration. Then, fixes can be implemented and absorbed in the following iteration.
Figure 3: Staggering regression testing over iterations supports the Agile way of development yet allows adequate time for regression testing. Confining regression testing to only the current version of code under development in an iteration runs the risk of creating a waterfall dynamic.
Development teams could be brought to a standstill waiting for regression tests to complete before performing fixes. And then, once issues are uncovered and remedied by developers, regression testers would need to wait until the new code is available before further action can take place. Staggering regression tests over iterations gives testers the time they need to perform the scope of testing required while allowing development staff to create new code in the meantime.
However, launching your product without proper testing, more importantly, regression testing could lead to lots of complaints from your end users, which is not a good sign for your product and business.
The only way to achieve high-quality digital applications is to deploy an effective software testing model that covers both functional and regression testing for each release. To maintain the best balance between fast development and frequent app testing requests, it is important to include regression testing strategy in the product release plan itself.
Playing a critical role in the release process, full regression testing is equally needed in the development phase. I was consulting one of the largest telecom firms as their QA partner for their digital app portfolio. Their business-critical mobile app was updated on a weekly basis and they were releasing fortnightly builds to production. Owing to deployment delays and pressure of achieving faster time to market, the product team only focused on new changes implemented for each release while ignoring the stable features.
There was a large number of issues cropping up in the production and the app was losing its store rating due to bad overall user experience. The client asked us to help them resolve the situation. Upon conducting due diligence, I realized that in the urgency to deploy new features to production, the existing features were rarely tested, while they were getting impacted due to changes made to new features and this was impacting the overall user experience.
We decided to come up with a risk-based regression testing strategy for this app. Regression testing comes in handy specifically during these constant churns and ensures that the earlier release is in sync with the new code. An effective regression testing strategy calls for careful planning and prioritization, as well as the active involvement of the whole team. Teams need to ensure an effective balance between speed and quality, which means they need faster and credible feedback.
Particularly in an agile environment, it is important that the feedback comes in faster, so that the required action is taken. Hence, within an agile set-up, the regression tests are run just after the changes are done and before the sprint is released. This helps in getting a quicker response for better turnaround time and implementation. Automated regression tests enable faster results and repeated testing for similar releases.
There are various challenges the enterprises and start-ups face while adopting regression tests. Without giving any second thought, regression testing should always be a part of your product deployment strategy. An application should deliver value to the customers. If you keep spending money on people and resources without picking the right strategy, you will not achieve the results as expected.
0コメント