??? The formal specification takes time and some mathematical ability to create and prove.
4.4.10 Extreme, Agile, and Rapid Development
These represent essentially a reworking of various approaches to minimize the administrivia of software
development and leave coders freer to code. Such approaches do not necessarily hinder system testing (and
Test Planning and Management 55
the ???Extreme??? approach, if correctly followed will at least result in a lot of unit tests being prepared), providing
that we can identify the requirements the coders satisfy. This is supposed to happen with the aid of ???user
stories.??? If it doesn??™t, testers must write their own baselines, possibly as described in section 8.2. Additionally
developers need to take long hard looks about how the architecture evolves, if it is not to become entropic.
The dangers of Extreme, Agile, and Rapid development are that:
??? The requirements will evolve and need to be captured.
??? Developers remain unaware of subtle feature interaction until the end.
??? The approach needs to be feature-driven (which it mostly is) with frequent builds of features
matched by frequent system tests of those features as they evolve.
??? Integration remains a hazardous time because of the subtle feature interactions.
??? The concern for (unit) test-driven development, will tend to produce good code but isn??™t enough
to ensure successful product release.
FIGURE 4.
Pages:
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181