TE

Test process improvement
Fixing agile
by David Gelperin
The way to manage quality debt is early
identification of quality goals
a shorter time. The situation is much clearer
when achievement is unsatisfactory. This is
when systems kill, crash or are breached.
Internal qualities such as portability,
testability and code readability, can’t be
seen by customers.
Achievement of all internal and many
external quality goals crosscut the
functional code. For example, exception
handlers should be everywhere. Crosscutting
qualities can’t be implemented in
a single module or group of modules.
They must be implemented everywhere.
This fact is a problem for any development
process that doesn’t identify its quality
goals, achievement strategies, and
verification strategies before incremental
development. Without early identification,
each early increment will have high-cost
technical debt due to voluntary ignorance.
Projects with tight
deadlines are often under
pressure to take shortcuts
that may sacrifice quality.
Big Requirements Up Front (BRUF) is
an agile anti-pattern. Agile discourages
early identification of comprehensive
requirements for fear of waste and goldplating.
Building something incrementally
and showing it to customers for timely
feedback often makes perfect sense
for functionality. But, functionality
is not the whole story.
Consider quality attributes, both external
and internal, and their goals. External
qualities can be seen by customers.
Behaviours such as safety, security and
reliability need time periods of years to
suggest their satisfactory achievement.
Other external qualities, such as ease of
use, can show satisfactory achievement in
Technical debt refers to the extra work
created when “easy-to-develop” code is
used instead of code for the best overall
solution. “Easy-to-develop” entails the use
of simplistic or unnecessarily complex
designs. Technical debt always entails
shortcuts, both deliberate and unintentional.
Unintentional debt results
from ignorance of needs or effects.
Examples of deliberate debt are code
that doesn’t validate input, handle edge
cases, or handle exceptions. Examples of
debt that may be deliberate or unintentional
are missing or incorrect functionality, code
that doesn’t comply with development standards,
and code that doesn’t deal with other
quality goals such as safety, security, or
privacy. Examples of unintentional debt are
code that has unnecessarily complex logic
or design and unnecessary functionality.
From a requirements perspective, we
distinguish functional debt from quality
4
PT - December 2016 - professionaltester.com