nFocus Director Scott Summers have been invited to talk at this year’s Testing & Finance conference being held 16-17 May, in London.
REGRESSION TESTING LIVE SYSTEMS – DOING IT BETTER
ABSTRACT
“Many organisations, have operational budgets for maintaining systems once they are in production and another budget for projects to develop new products or enhance existing systems. In banks this is typically called ‘Run the Bank’ and ‘Change the Bank’. Project budgets are often constrained, testing budgets are very tightly constrained and so there is little forethought for the regression tests that are required post go-live. It is understandable – it’s not the project managers’ problem and the business just want its new, shiny system as quickly and cheaply as possible. This results in systems going live with no way to adequately test them when changes and fixes start to be applied. To retrospectively create a regression pack at this point is difficult – the project team has moved on, documentation is out of date and there is little or no money in the budget. The result is increased risk to the business because regression testing is inadequate. If the desire to rectify the problem is strong enough, it often requires an expensive and drawn out solution.
By considering this eventual problem in the test strategy, the business and system owner can save time and effort while reducing business risk. Test cases can be written in a way that enables them to be automated and maintained post go-live. This needs to be planned, budgeted for and managed but it really is not a massive overhead. There are some simple techniques that can be applied and the key to success is deciding the approach early on in the testing lifecycle. Using a keyword driven framework also enables automation scripts to be generated with minimal overhead. Again, planning and implementing this during the project lifecycle is the most efficient way to operate. However, real life is not that simple and in the cut and thrust of a project, this is an easy overhead to cut. As such, it will more often than not be cut. So, post go-live how can an automated regression pack be created cheaply and quickly. We suggest an agile approach to testing and treating the development of the automated tests as a software development project. As such, a back log of requirements is created and these are picked off and assigned to sprints. In this analogy, each test case is equivalent to and becomes a requirement. The original functional requirements are related to the test case back log but these are not what is used for the sprints. This encompasses a risk based approach and the regression pack is built up over time with the most important tests being developed first. If there are no test cases to use as requirements, then these can be created at the same time as the backlog by again using a keyword driven framework. Saving time and effort when compared to writing test cases from scratch.”
MORE INFORMATION
For more information about the conference, and to book your place please click here.
