Do not let anyone change functionality during testing. This should be the later stage of preparations for going live and the business logic hopefully is determined by this time if all has gone well.

One of our projects generated over 70 test cases that the client had only one resource for. That resource happened to be a manager. During testing the manager noticed bugs of course, but also insisted on adding and changing features. I explained to them that doing so may invalidate previous test cases that will have to be re-checked. The manager agreed, and so feature changes were done during testing as asked. The manager, however, never re-tested approved cases. This snow balled into plenty of aggravation for all involved. Code was written, code was testing and approved, and then code was affected by feature changes. It got to the point that the manager would come in every day and complain about having tested “things” that used to work, but no longer seem to work. This in fact was the symptom of a flawed testing process.

If the manager had gone back and re-tested after feature changes, there would not have been an issue. However workloads and time constraints dictated otherwise and the user acceptance process took much longer time and effort and cost the company more money which agitated the managers higher up the ladder. I think there was a week long period during this time where nobody said good morning to me.

What to do? Offer the manager an all-expenses paid trip to a faraway place? Maybe. In retrospect, the best practice would have been to document that no feature changes can occur during testing and create a more agile feature development iteration including more testing resources. Also, keep a good travel agent in your Linkedin contacts list.