Information Technology Reference
In-Depth Information
11.12 Testing During Post-Delivery Maintenance
Through the course of development, the product development team will have
broad overview of the product, but, as a result of rapid turnover, members of the
postdelivery maintenance team will be involved in the original development.
Therefore, the maintainer tends to see the product as a set of loosely related
components and is not aware that a change to one code artifact may affect one or
more other artifacts. Even though the maintainer wished to understand the product,
the pressure to fix it with such little time can make it impossible. Sometimes even
the documentation is not be available to assist. One alternative is to use regression
testing, that is testing the product against the previous test cases to ensure it still
works correctly. This is why it is extremely important to keep test cases. As a
result of changes being made the test cases will have to be changed as well.
Depending on the maintenance performed, some valid test cases become invalid.
There is no extra work involved in maintaining a file of test cases and their
expected outcomes. It is sometimes argued that regression testing is a waste of
time, however, the dangers of neglecting it are too great to hold the argument. As
such regression testing is an essential aspect of maintenance (Schach
2007
).
11.13 Metrics and Challenges of Post-Delivery
Maintenance
Metrics in software engineering have been discussed for a long time, but not used
widely as a means of increasing the quality of the product or process. The real
problem is that we cannot measure exactly what we would like to measure; we
must assume that there are relationships between that which we can measure and
that which we would like to measure. Process related metrics measure things like
man-months, schedule time, and number of faults found during testing. Below are
the metrics collected when working with OOSE :
• Total development time
• Development time in each process and subprocess
• Time spent modifying models from previous processes
• Time spent in all kinds of subprocesses, such as use case specification, use case
design, block design, block testing for each object
• Number of different kinds of fault found during reviews
• Number of change proposals for previous models
• Cost for quality assurance
• Cost for introducing new development process and tools
For instance, if we know the average time to specify a use case, we can predict
the time to specify all use cases. These measures vary greatly between different
projects, organizations, applications and staffing. Therefore it is dangerous to draw
