I wrote some code about two years ago, which was deployed to the production environment. The code deletes information that is six years old from a system. When it was first deployed there were only 300 records deleted (because only 300 were six years old).
Now there are now 10,000 – 10,000 records become six years old tomorrow. I want to retest the code but the project manager is against this (because it takes time – one day).
The deletion routine is very complex (the six year rule is only one of the rules but is the main rule).
The system has evolved over the last two years. Is it reasonable to set some time for retesting or should I assume that is it worked at the time then it will work now (as the project manager assumes)?
Is there an Agile process that describes this sort of testing?
1
Generally speaking, code doesn’t “go bad” on its own. it doesn’t rust, or require fuel or lubrication, it does’t get weaker through use. If the only variable in your system is time, you don’t need to retest, unless you have cause to believe it wasn’t properly tested in the first place.
Now, if the system has changed, those changes need to be tested. If they were not tested, they should be.
So, I think the answer to your question lies in the answer to this other question: when the system was changed, was it properly tested (ie: was all dependent code also tested?)
The only way that agile addresses this issue is that it specifies software needs to be properly tested before it is considered “done”. If you did that, you should have nothing to worry about.
All that being said, you also should ask yourself what the cost is for testing or not testing. If you don’t test, and the system fails, how bad is it? Will it be catastrophic or just inconvenient? If you are talking about sending a probe to mars, the answer will be different than if you fail to update a web based dashboard on weekly game statistics.
I don’t believe this scenario has anything to do with an agile process or not. Software development should have built-in time for regression. In a Scrum model, you probably are running this every sprint.
You should also be looking at automated unit tests and other ways to embed your regression into your builds. This allows you to have continuous feedback on whether your business logic is still working as changes occur.