Peter Varhol, Seapine Software
A potential by-product of development is technical debt – a working implementation that does not conform to best practices for architecture and implementation. Almost all projects have some element of technical debt. Technical debt must typically be repaid, with interest, later in the application lifecycle.
Most teams are capable of recognizing that technical debt has been incurred, but assessing that debt can be difficult, especially under an aggressive development schedule. But having a good measure of at least one aspect of technical debt makes it possible for the team to assess whether it is better to address now or later.
One operational measure of technical debt is scalability. A robust architecture and implementation theoretically should be able to scale indefinitely. Knowing the ability of the application to scale gives the team significant information about the quality of the architecture and coding practices. Ideally, load testing can be a key indicator of when to pay down debt.
This session discusses the role of technical debt and how to assess technical debt with frequent use of load testing. It will provide a protocol for using load testing as a part of the testing process, and using it to assess the architecture and coding quality. Last, it provides a mechanism for testers and developers to collaborate in decisions surrounding design and coding practices.