 |
|
|
Devtest's
methodologies are based on over ten years experience in successful
software development using the Microsoft Framework Solutions as a
guide. Below are some of the practices Devtest Solution Teams
employ. |
|
|
|
|
|
|
Constant Stability |
|
|
|
Devtest employs the
practice of effective version management and daily builds to sustain
a project that is constantly in a state of stability.
Automated build verification and regression test are utilised to
ensure that the foundations remain intact as additional features are
added to the product daily. |
|
|
|
The Daily Build |
|
|
|
Implementation of the
"Daily Build" includes automation of the code check-in, build
verification tests, deployments to multiple environments, together
with automated testing.
Combined with
parallel testing, this loop slowly
builds the product, infrastructure and
deployment environments into
a "sacred build". On the target
code complete milestone, we will have already tested 80% of the code
base and identified and corrected 80% of defects. |
|
|
|
Monitoring the Heartbeat |
|
|
|
Devtest provides a
monitor that measures the 'heartbeat' of a project. Using
defect metrics and a pre-defined 'quality bar' or defect threshold,
our monitoring provides clear visibility of the status of the
project at all times. Metrics, statistics and historical
defect trends gathered daily are fundamental to our ability to
communicate "course corrections" to management and the development
team.
|
|
|
|
Benchmarks and Targets |
|
|
|
A healthy software
development project will follow a marked course on the trend charts.
The daily prioritisation of defects is the mechanism to drive the
quality through the healthy trend lines towards deployment.
This information allows the project team and, importantly, the
project sponsors to accurately and reliably forecast software
quality and progress towards the target completion date. |
|
|
|
The Quality Bar: The
Active Defect Threshold |
|
|
|
A 'quality bar' is a
target that defines the level of quality required during each
release. Because we track the results of the defect fixes
throughout the development, we can statistically
compute the expected
threshold of bugs and drive the team to remain below that threshold
at all times. |
|
|
|
Stop and Stabilise |
|
|
|
When defect tracking
approaches the threshold, the practice of "stop and stabilise" is
introduced: that is, a stabilisation period is observed in
which coding of new features stops and only bug fixes are performed. |
|
|
