Adapting to change

One of the core Agile principles in software development states that “requirements may evolve but the timescale remains fixed”. If at any point in time during a project’s life cycle, the need for changing a set of requirements arises, the deadlines and milestones must remain fixed. If possible, there must always be deliverables whenever it was planned so.

The statement “requirements may evolve” gives a clear indication that even during the development and testing phases, new functionality can be added or existing functionality might be changed. An in-depth analysis of the impact of such changes must always be carried out. There may be changes that are minor and rarely affect other aspects of the product, while other major changes can heavily impact the core functionality of an application.

Usually, such changes are conceived by a client and communicated to the business analyst or consultant.  The information arrives to the project manager who will delegate the work accordingly if approved.

Now, it might be the case where this information is delivered to the software developers but not the testers. One of those unknown diseases that a few companies suffer from: dishonouring the role of a software tester.

READ MORE ABOUT DEALING WITH CHANGE- Change Management during Maintenance

At all times, the software tester must be fully aware of these changes, especially those that would affect the core functionality of the product being tested.  In some cases, the software tester may also be the one entrusted to manage these changes along with the project’s requirements. Either way, if a tester is left in the dark and is not well informed, then the product would be tested against a wrong set of requirements.

Changes to requirements should be seen like a gear change – necessary but will only work if all parts work as intended.

Consider a care management system for patients with diabetes. Some changes might be simple for instance, changing a ‘Date of birth’ field in a patient’s registration form, from being mandatory to non-mandatory. Other changes, however, can affect the whole workflow of an application.  Let’s say that one of the main features of this system is to provide the clinician with a recommended amount of insulin to be administered to a patient. This amount would be a result of an algorithm based on a set of parameters. A change in this algorithm would affect this result and thus, the amount of insulin needed by a patient can be different. This would heavily impact the whole care path in the system as future medication would depend on such parameters. Not to mention that the patient’s health might be put at risk.

The mismanagement of change requests brings about highly undesirable results. Changes must be fully analyzed before they are authorized. The tester must not only be aware of the changes, but fully understand their meaning and their impact on the product.

A tool like ReQtest can help manage these changes together with the requirements. If not controlled properly, change might do more harm than good.
Confessions of a Tester is written by Johnny, a test leader by profession and friend of ReQtest’s. Johnny loves clean code and is suspicious of anything that seems to be completely bug free. Apart from bug tracking at his day job, Johnny plays guitar, watches action and gangster movies and is a great fan of comic books and superheroes. This blog is a chronicle of Johnny’s Software Testing Nightmares.