How do you prioritize regression test cases?

Good regression testing attempts to prove that software changes do not compromise the existing functionality. There are two issues that must be dealt with: 1) All existing functionality still works and the new functionality also works. 2) All errors found and fixed during the test must cause the regression test suite to be restarted from the beginning.

I agree and couple that with ensuring the test cases have been reviewed regularly to ensure they’re up to date and for purpose, especially factoring in any enhancements that may have been introduced since last updated.

I think that the impact of a particular service or feature that has on the system s another aspect which can be prioritize, you can have sanity or smoke tests that can quickly check if those are good, and based on the result you can run the regression suites (if a feature is completely broken, there is no sense in performing other tests on that).

Defect density analysis of bugs identified from earlier testing would serve as a useful gauge to target test cases to focus where functionality has been proven to throw up many issues. This together with a risk based approach to shortlisting test cases using a Impact versus Probability scoring to plan cases with highest priority so as to provide the ‘maximum bang for your buck’.

For added measure, a selection of end-end test cases should also be included so as to validate systems integration if applicable given that issues often lurk around interfaces.

'Business criticality' and 'Workflow Necessity' Two key factors play a significant role in the selection of regression test cases: Business criticality and 'workflow necessity.' This means that any workflow essential for the application's functionality and critical to business success, as well as any workflow crucial to the business but not necessarily mandatory, should be included in regression testing.

The combination of manual tests and automation is very effective to assure the quality of the software. Check pages, fields, flows, integrations, documentation and the final result, all of that is closer to a side project. When you create an Architecture for testing, things can become easier to work with.