Regression testing

Regression testing is a really common term used within the software industry, not only by QAs, but also for developers, PMs, clients, this term is sometimes confused by some people and I'm going to explain what a regression testing means to me.

First things first, every single project must have regression testing, from my perspective, before every single release to the client, QA must execute a regression testing to ensure the deliverables are in place and that other areas of the system were not affected by the multiple changes and new functionality added, this testing needs also to be done before every update to pushed to live.

Regression testing is a type of testing where you confirm and double check that the system works correctly with the new functionality added and that the previous functionality developed before works fine with no bugs, that being said, a regression testing involves the testing of every single page, module, functionality, service, etc in all the browsers, mobile devices and OS version included in the scope, I know this takes a lot of time, but you have to ensure that all functionality works correctly on every single device and browser.

Now there are a lot of techniques to use in here and the order to perform the regression testing may vary depending on your expertise and the way you to things, you can either test all the site by dividing the system into modules and just run one by one, or prioritize the most important areas and then test the other ones after finishing, and the other one is just to test some areas, I don't like the last approach, for me all areas must and need to be tested, of course, this also depends on timing and client requests.

You can track you progress on regression testing via Google Docs, a spreadsheet, your test case management tool or even using mind maps, the important thing in here is that all areas have their bugs logged (hopefully there are no bugs) and the status of all cases or all functionality that passed or not, this also gives visibility of the testing coverage made by QA and percentage tested. It's also important and obvious (sometimes this is not obvious) to say that the regression testing time must be estimated by the QA team, not by any other member of the project, you must estimate your work and you must estimate the time when the regression testing will be done, the sooner the better, but try to meet your goals and accomplish your pending tasks in the correct time. Another point to highlight is that developers don't need to wait until the QA team finishes the regression, they can start tackling bugs in the mean time and update the QA server for QA to test. If you ask me, depending on the bug, QA can stop the regression testing, check if the bug is fixed on the QA environemnt, and then continue the regression testing. Time and progress is key on agile.

Regression testing is the most robust, time consuming and biggest test during a project, you can save time by running automated scripts, but still all visual stuff and different configurations (if you are working with a CMS) take time to test really deep to ensure the quality of the system or product you are delivering. Don't forget QA is the gate keeper of the project and testing process, but the quality of the project depends on all members of the team.

@LuchoAgileQA