Unlike functional testing which is directed at the specific areas which have been changed regression tests cover the entire application looking for any unintended consequences of those changes, looking for those areas which could have a catastrophic impact on the business. Ideally the regression test is the last activity before changes are moved from the staging environment into production.
In theory you can perform a regression test manually, but it will be a huge burden on not only IT staff but will also require considerable resources from then business. You could perhaps take this approach when a major application is first implemented but it is a non-starter as a regular activity.
However, before we dismiss a manual approach to regression testing, let’s consider how a human approaches such a test. Yes, they need to navigate through the application but equally, and this is the key, they also need to examine each screen to ensure it contains the intended information.
So a regression test is so much more than simply automating the navigation of an application, much more than driving transactions from ‘A” to ‘Z’. And by definition a few spot checks on specific data items doesn’t meet the standard either – if you knew where the failures were going to manifest themselves you wouldn’t need all those people.
Therefore we need a regression testing solution that will execute data-driven transactions through an application – and there are plenty of them.
But we also need a solution that can access every element of every screen, verify them automatically and report every unexpected difference