How to decrease the regression testing time?

Hello All,

Currently in our organization we are following the process like below.

  1. For regression testing ( Around 200+ test cases) execution they have decided to give 5.0 hrs of time.
    A. Including test cases execution on Testrail
    B. Defect updating/Raising
    C. Report placing
    D. New functionality verification

As my team manager asked me to help on this to reduce the regression testing hours.

What are the suggestions from your end. How can i improve the testing process?

Is there any way you can run your tests concurrently?

I had to do that and it cut our testing time dramatically.

1 Like

On weekly basis we will get the front end release. On every week we need to do the regression testing manually.

Front end release includes

  1. Defects fixes majority part

I’m sorry, I misunderstood. I thought you meant with automation.

There isn’t much I could suggest since I don’t know the context of your test cases but… is there any chance you are doing too much testing?

Is there a possibility you can implement some automation testing to reduce the testing time, too?

1 Like

@froberts

We have automation team as well but we need to do the manual execution on Front ends later automaton team will execute the regression once.

I thought we are doing too much testing but that is not more pro active because of the time they have given.

Could you identify your highest risks first at product, then release and workout a plan from their. You may well find ways to reduce the tests you run while increasing your confidence that your biggest risks are mitigated.

3 Likes
  • Figure out how much of the “test” time is spent documententing. Try to reduce that time.
  • Partial automation or scripts can reduce the test time a lot.
  • Figure out the risk of NOT running each test. If the risk is small, then the test may be omitted.
  • Figure out which tests are covered in other test cases (i.e. if you can’t do a check out without logging in first, then the log-in “Happy path” test is redundant)
  • Figure out which tests are close enough to other tests to combine them.
  • Figure out which tests are already covered by automation and/or unit testing. These can then be removed. (It is either more than you think or less than you expect)
  • For regular releases (i.e. weekly, monthly), only test high-risk areas, or those impacted by the changes. With the remaining time, spot check the rest of the functionality.

Now to what I would do, which may be totally inappropriate for your situation…
I would test the impact of not doing manual regression testing at all, or maybe just from a very short checklist. I would then use the extra 5 hours to run a few exploratory testing sessions for pre-existing functionality. The scripts and tests which you have already created may help with ideas about what and how to test during your sessions.

Compare the results of the three options. How is the product improved by “regression testing” plus overhead? How is the product improved by doing no testing for pre-existing functionality? How about using testing sessions instead of factory-testing? Which process has more overhead (planning, documentation, etc)? Which finds more issues? Which encourages communication with the team? Which provides more coverage (short term AND long term)? Which is less impacted by the pesticide paradox?

Personally, I really prefer session based testing. For me, it increases time spent testing, reduces time spent documenting and updating tests, and allows me to test differently every time, thus increasing coverage in the long term. The big down-side is that there is a chance that some functionality gets missed. So perhaps a combination of techniques?

4 Likes

I had used similar approach in the past when automation is not up to the level we need in regression checks.

Basically, team of testers talking to dev to understand potential impact areas. Run through happy path across product areas first. Then, followed by timeboxed in-depth exploratory testing sessions in identified high risks areas. Also, ask for help from others if you need more help with testing, get Dev, BA, PO, Support, Business to help out with the happy path checkings. Get testers focus on in-depth exploratory testing in the high risk areas.

Thanks for the valuable inputs on this.

Currently we have third party team who are doing the development and simply they will handover to the testing.

Here we are interacting them very rarely.

Is there any reason stopping the team collaborating more?

Talk to dev if co-located
Talk to dev via online collaboration tools if not on the same location

2 Likes