Testing Following Release Development

Alongside the maintenance required by fault correction, project management will also plan extensions and other changes to the system in order to keep it competitive and expand the customer base. Most systems are subject to continuous development—for example, to build improved releases of the product. Such releases are usually coordinated with scheduled maintenance work. For example, these may be quarterly maintenance releases and “real” functional updates on an annual basis.

Case Study: VSR-II development planning

The VSR-II development plan for Release 2 includes the following changes:

1. The ConnectedCar communications software is to be extended to ensure compatibility with the new generation of IoT sensors built into the latest model range.
2. Various functional extensions that were not ready in time for Release 1 will be delivered with Release 2.
3. The installed base is to be extended to include the company’s dealers worldwide. This requires localization work for additional countries and includes translation of the system menus and manuals.

Change #1 results from a planned change in external resources and systems. Change #2 is a function that was planned from the beginning but hasn’t yet been implemented due to time restrictions. Change #3 is part of a set of extensions that are required for preplanned market expansion.

None of these changes are due to fault correction or unforeseen customer requests, but rather part of VSR-II’s normal iterative/incremental product development process.

Testing following such release development follows two main objectives:

1. Checking that every new or extended function works as intended
2. Checking that pre-existing functionality is not (unintentionally) impaired

In order to achieve objective #1 you need to develop and perform new test cases. Objective #2 requires appropriate regression testing .

Testing before decommissioning

An interesting case occurs when a system is due to be permanently retired. Here, you need to check before decommissioning whether the system data can or must be archived or transferred to the successor system.