Product testing consumes more time for doing regression cycle

Question

Currently, am doing product testing over past 2 years, we are giving our base product to the clients with their additional requirements for any new clients and also the version patch is updating for all existing clients in the regular interval of time.

In this situation, the Base R&D product having more changes and fixes, it is taking more time to complete the regression testing.

We currently doing only manual testing and automation part is being implemented but it is not yet completed.

Every time when we are doing regression test it is consuming more time to complete the test, as well it’s bit boring doing the same cycle

Can anyone please advise me, how I can reduce the time for regression cycle as well as the new ideas to make the testing very interesting in the short period of time.

Answer 1

A good start would be to review your test cases and prioritize them. The ones that cover the most important functionality aren't always the best choice to automate but they do at least represent the place the company will want you to focus. One cannot test everything and one certainly can't automate all the things.

If your company is totally new to test automation it may be worth bringing in a trainer or consultant to lead this work. It's a significant investment and it's easy to get it wrong and waste a lot of time.

Writing test automation is not like writing applications, performance is less important than accuracy and clarity of code or purpose. Avoid complexity, avoid fancy syntax, avoid parallel or threaded operations unless the AOT requires it.

You shouldn't try to fix the code or survive errors; it's important to report them with all the details.

Try to avoid compiled languages for writing tests, they will slow you down compared to interpreted languages that have interactive shells. These can be very powerful ways to do exploratory testing to find the paths through the code; it's then trivial to change them into tests.

Create a test repository to store the tests and try to create a packaged installer so that you can reduce setup issues.

Answer 2

From your context I assume your system is quite big and complicated. Now you are running in circle, a lot of test to do -> no time to do automate test -> no test execution effort reduced -> a lot of test to do ... on and on and on. If you don't push something back, break it, or do anything different, you will be in stuck in this loop forever.

Here is a few approaches from me:

1. Prioritize the test cases / testing tasks You might find and be able to push back some unnecessary, low-priority test cases or task. You might skip it for some platform/client or run only one time to ensure it works rather than run it for every clients.
2. Find the big time-consuming test cases / testing tasks together with the first point, if you lucky enough, you might find the low-priority test cases or testing task that the big time-consuming. Then it could reduce the testing effort.

3. Do the automation I know you mentioned

   but now the automation door is closed. We currently doing only manual testing and automation part is being implemented but it is not yet completed...

   However automation in my meaning is not fully regression framework with fancy CI flow and beautiful report. My automation means any tool, any simple script/program that help you execution test faster.

   For example; If you need to verify a thousands of records, let's create a simple script to query and validate it for you. If you need to verify a thousands of service request/response, let's using a tool such as Postman to validate it for you. If you need to verify a number of UI functionality, let's create a simple Selenium IDE record and playback to do it for you.

With all my approaches above I hope you find a critical area that you could find a low-priority big-time-consuming that you could apply any automation to have a great reduce your testing time. But not just happy and live with it. Invest this saving time back to automation to make your future better for software testing.

Hope it helps.

Answer 3

There are various test cases to be designed and executed at a certain level in the complete software testing lifecycle. Based on the importance and requirements of a particular application, the priorities need to be set for sanity tests, integration tests and a complete set of regression test cases. Whenever there are new changes, the existing regression test suites might require modification in adding, editing or removing the existing test cases. All these need to be done within the time allocated for the regression testing.

Entry/exit criteria can be implemented in regression testing as well. For entry criteria, a fixed set of conditions like reviewing bugs & regression tests based on those bugs, etc. need to be met in order to initiate the testing. And, for exit criteria, a fixed set of conditions like checking all tests are executed, no bugs remained unfixed, etc. need to be met to conclude the testing process.

A great way to maintain the effectiveness of the regression test suite is to have a good tracking mechanism between the features that are developed and the tests that are added in order to validate for future usability. This should be a consistent activity as it would help test manager verify the feature checklist and validate the test coverage for a feature that is being developed in the release.

Another technique that I came across during my research on reducing the time for regression testing was reduce, reuse, recycle and recover.

Reduce the regression testing time by creating effective regression test suites that test the changed part of the software, by identifying test cases in the regression test suite that do not need to be rerun on the changed software, and by identifying and removing obsolete test cases.

Reuse test suites created for one version of the software by identifying those test cases that need to be rerun for testing subsequent versions of the software and by computing an effective ordering for running the test cases.

Recycle test cases by monitoring executions to gather test inputs that can be used for retest-ing and by creating unit test cases from system test cases.

Recover test cases by identifying, manipulating, and transforming obsolete test cases, by generating new test cases from old ones, and by repairing test cases when the software changes

Answer 4

Write automation by following the test pyramid.

Get your developers involved in unit tests and cover the service/API/UI tests in QA to get the best mileage in short time.