Regression Test Planning is like Packing for a trip
Are your regression test packed with too much fluff?
This is a follow up to last week's post.
Vacation Packing Experts will tell you take less than you need. Such as this tip from The Blonde Abroad:
Here's a traveler's secret. After all that packing, chances are you won't use half of what you plan to take. So why not save yourself the trouble and leave half behind? A neat trick that I've always done is set out all the clothes that I want to bring and definitely think I'll need and then take just half of them.
How does this relate to QA Regression Test Planning?
When planning the test strategy for a new function to add to the regression test, you should revise the coverage to focus on the most important functionality. When a feature is first created every part is critical but over time some of the features become less critical. When it's time to add the feature to regular regression - as part of the QA Transition Plan - some minor features are treated as critical issues.
Three Tips to Writing a Test Plan
It's QA job to balance the priority of testing the functionality to the amount of time that is available for regression testing. Here are some best practice tips I have learned over the years:
Know What is Important - The QA Team Lead needs to work with the product and Developer Lead on the critical parts of the feature. The group needs to decide what functionality is critical to the product going forward - post-launch. This is where the packing analogy comes in - decide now what is critical to take on the next release journey.
Tag Jira Tickets - When writing the test case, it's a good idea to reference the original Jira Ticket. I can't tell you how many hours have been spent searching in Jira for the QA ticket, just to find the product description or specs. I have found that test tickets may have error log notes that may help debug issues that happen long after the product was released.
After all is said and done more is said than done - I have seen projects that were once mission-critical, become a very low priority in a very short time. Despite all the "sense of urgency" that was initially given, other projects become more important. Ideally, a good QA Lead will follow up with the product to verify the priority of the feature functionality. However, balancing other projects usually distract QA from the ideal process.