Writing regression test cases for already developed application [duplicate]

Question

We have a web application which has been developed in last 8 months now released to production. Now we are adding new features and doing bug fixes. However the existing QA team has not written any test cases for this application. They just did high-level test to this application. Now management want to write test cases for this application. What sort of a approach we need to follow to write regression test cases. We have small team and they need to focus functional test as well for sprint

Answer 1

Read Working Effectively with Legacy Code by Michael Feathers, it's a great read for developers as well as for testers.

My personal approach would be starting small from the grounds up. Start with high level design for the tests (not necessarily the document with the same name, just a design)- break the systems into sub systems, collect whatever requirements are available (don't forget the 37 Sources for Test Ideas and think of how should you test each part, there could be more than one answer to that.

Then choose an option, it doesn't have to be the best but you do need to justify the selection, set up a Test Harness and add a couple of tests.

Make sure the tests runs stable, and move on from there either horizontally (test another sub system, possibly using another test harness) or vertically (adding more tests).

You don't have to decide on that from day one, but you do need to make a decision on when to stop adding more tests.

Finally, don't forget that manual testing is also a viable option.

Answer 2

We actually need more information for a well targeted and focused answer.

Particularly:

However the existing QA team has not written any test cases for this application. They just did high-level test to this application. Now management want to write test cases for this application.

My questions here are:

• Is qa separate from development? Why?
• What does management want from having more tests and why?
• What problem are tests intended to show?
• What kind of tests do you want and how will they relate to other Unit, Integrated, UAT and exploratory testing?
• Tests find problems but don't in themselves fix them. What is the plan to fix bugs?
• Is the main problem old bugs or (avoiding) the creation of new ones?

Given the 'usual' setup that I think you are describing I would follow the well-worn and trusted path of approaching test creation:

For UI testing (this may be specifically what you are thinking about)

Create smoke tests for the devops pipeline and then happy, sad and optional flow workflows (usually through HTML forms) as a basis for your UI test cases.