Regression testing in software engineering is one of the key cornerstones in our development process. It makes sure that what you have developed on this release cycle, actually works.
In layman’s terms, regression testing means actually testing everything about your platform, product, a website from the technical perspective. Think of it this way – if your clients can register on your website, then you test the registration process.
The methodology
Following the key methodological approaches that are recommended in almost any scenario. Depending on your situation you should choose one of these.
- Full coverage
- Partial coverage
- Prioritized coverage
- Hybrid
Preconditions
One of the key pre-conditions to fulfill is having test cases. They are nothing else except a collection of workflows that make your product. They need to have an explanation and a priority.
i.e. You have an e-commerce website. Here are a collection of test cases
- an unregistered user can browse and filter products
- registered user can buy a product
- registered user can return a product
- registered user can manage his account
- a new user can register
- an unregistered user can register and buy a product
Full Coverage
You test everything and make sure that everything is in top shape. This is the more costly approach, but it is the safest. We usually do this when there are major changes to core components.
e.g. Let’s say that in the previous test cases, you test everything.
Partial Coverage
You test partially and focus on the changed components only (or selected components as the methodology defines). This takes less time and less effort than the full coverage and it is usually explored when you trust your development workflow.
e.g. Say that you made fixes and adjustments are done on the registration workflow and you are comfortable not testing everything. then you test cases 5 and 6.
Prioritized Coverage
Normally here you test high priority test cases first, but in the real-life, you always test the key priorities set by the stakeholders and then the others. This is also less than the full coverage.
e.g. Let’s say that from the business perspective, your key priority is that your current users can make a purchase. That means that for the changes mentioned above, on the registration workflow, you test case number 2 with priority and then 5 and 6 if deemed necessary.
Hybrid coverage
This is nothing else except the partial and prioritized coverage. Even though this sounds like nothing else except a “non-methodology” methodology, it is real-life, usually, this is the way to go.
e.g. Let’s say that from the business perspective, your key priority is that your current users can make a purchase. That means that for the changes mentioned above, on the registration workflow, you test case number 2 with priority and then 5 and 6 (unlike prioritized coverage above, you must do this)
