Regression testing is honestly one of the worst parts of testing, usually, at least to me. It is so repetitive, and can take forever. I’ve been at places where it’s legitimately taken 4+ weeks of regression testing prior to a release, and by the end we all had test blinders on. Regression testing is going back and checking what has worked before, and ensuring that your change didn’t affect past functionality in an unexpected, or unintended way.

Depending on how big of a change was made, your regression testing can be quick, or it can take what feels like forever. This is an area where it’s really easy to fall into the habit of over testing, so knowing exactly what was changed and what other areas that code touched are game changers. A way I’ve loved to regression test is through targeted regression – it’s made life so much easier.

So, for our Facebook login test, let’s instead pretend that along with the login being changed, the header image when you login now has been changed too. So, what would you need to regression test? For me, with regression testing I tend to also re-verify a bit of my previous testing, as it just works with my flow, so I’d start by testing the following:

• Login still works
• Logout still works
• Password reset still works
• Signing up for a new account still works
• Deactivating an account still works
• Validation around logging in with incorrect information – do you get locked out? Do you get an email for failed login attempts, etc?
• For the header image when you login, is it the same image for new and old accounts?
• If you’ve saved your login and are always signed in, does the new header show up on your next visit to Facebook, or do you have to refresh or clear cache and cookies?
• Does the header persist past the home page? Should it?
• Can you still make posts, comments, likes, etc?
• Do your saved favorites and such, that appear on the left of the screen under the header, still work?
• Happy path through basic functionality once logged in
• Anything that has a history of being finicky and breaking even when I’m told it wasn’t touched

Without having a more narrow view of exactly what has been touched your regression test has to be pretty broad. I make sure to start by checking the must have’s. What has to work? What is there no work around for, what would impact someone’s ability to use the app, or what would potentially cost the company money if it didn’t work? Then, what should work? What has a work around, but maybe isn’t the best work around? Then, what are the nice to haves? What isn’t a deal breaker, and doesn’t affect basic functionality, but is nice to have and just enhances the look or experience?