I recently started a project in which all testing has been done with zero documentation. I need to start creating a Regression suite and propose it to my manager. I have done regression testing earlier, but I have never put together such a document. What do I absolutely need to include and what should I include, any tips or templates would help greatly.
3 Answers
The other suggestions here are good ones.
Some additional thoughts from my experience:
- Format matters less than content: if you and your manager have something you can work with, you have enough to start with.
- You don't want to try to cover everything from the start. You're new to the project: you don't have enough context to cover everything.
- Your first priority for regression is the critical functionality and anything you need to access the critical functionality (in other words, don't sweat log on/log off - you'll cover that while you're testing critical functions for your customers).
- Start with a high level description of the functionality you're looking at: "non-taxed transactions" might be an example. Or "delete a product". You can always add more information.
- For manual regression, I recommend keeping it as light and simple as you possibly can. Humans get tired and lose focus no matter how dedicated they are.
- You will need to know the most used configuration settings. These will be the core of your manual regression tests.
- Long term, look to identify potential automation candidates and potential expanded regression candidates.
- You want to work towards a multi-tier regression suite:
- a short regression smoke test that covers the most critical items (manual)
- a longer manual regression suite that can be used when there's a need in a particularly fragile part of the system
- a set of automated regression suites run on a regular basis that you expect to always pass and are continually monitoring to make sure they're still relevant and are constantly adding new tests to.
- a set of specialized automation regression suites that may require a very long run-time but provide exhaustive checking of crucial parts of the system (such as tax calculations). These can be used when the calculation engines change.
some good ideas can be found in 37 Sources for Test Ideas
some highlights- look for similar products and similarities in other products, what are the business needs and goals, official standards and de facto standards, and most important think like a user.
I would say, there is no definite answer to that. The task you have is quite creative and you will have to improvise but here are few thoughts:
- Start with some essential and common features like login/logout, reset password, user registration etc. and add them to the regression suite.
- Talk to the people in your team, especially product people. Try to determine what are the essential user journeys in your product, go through them and create tests cases
- If that's possible, try to look at the bugs history for the project to see where most of the critical/high priority bugs occur