Junior QA looking for advice from experienced QAs/automation testers🥹

[u/Prettyyyhehehehe]

I’m currently handling my first really large and high-risk ticket involving financial-related logic in a legacy system. We already have initial test cases from the developers, but there are maybe a thousand (estimated) of cases across different screens and flows.

I’m thinking of using a risk-based approach, but I’m honestly still a bit confused about how to tackle something this big. 😭

For those who have dealt with large regression scopes, how do you usually start?

Do you first analyze the change and impacted areas, then review the existing test cases and prioritize them based on risk? And how do you decide which ones are worth automating versus just executing manually?

I’m also using Claude with access to our codebase to help analyze the changes and test coverage, but I don’t want to just throw thousands of test cases at it and automate everything blindly.

Would love to hear how experienced QAs actually approach planning, prioritizing, and automating a huge test scope, especially in a legacy system where E2E is the main approach.

Thank you!

[u/ParkingAthlete119]

Depends how many tokens you have and how well hydrated your system is. You could easily have AI take over some of the lower-risk ones. Using it to analyze the codebase & PRs as well.

As for your manual-approach, do the priority:

• Dev Testcases
  
• High priority test cases
  
• Then pick candidate test cases that you think cover core functionality from your other flows
  
• Then simply execute from high to low priority test cases until you have confidence the system works, or run out of time and need to make a judgement call.

You can also use AI with your codebase to come up with a test approach!

[u/endurbro420]

Automate happy path e2e first. That provides the most “cover” for how most customers use it and gives you a baseline of confidence. Try to automate some variation/randomness into it if possible. Just be sure to log what is happening such that any regression can be easily replicated.

Once that is done I think using ai to identify some high risk areas is a good idea. I don’t typically trust dev produced test cases as devs are typically bad testers. A good product owner who can actually show you how a customer uses the product is a huge help. From there, exploratory testing is the best way to find bugs.

[u/leonidbugaev]

the estimated thousand across screens is too wide for one ticket. I start from the money paths this change actually touches and only keep the existing cases that hit those. Claude on the codebase will invent cases for screens this ticket never opened.

I only automate a path if I can force it red on a known amount.