Iteration
Overview
This phase is called Iterations because it
happens in a circular fashion:
-
Programming Team codes to
the Functional Specification.
-
Programming Team releases
the code to the Testing Team.
-
Testing Team runs a Smoke
Test on the release to ensure a minimal level of
compliance. If the Smoke Test fails, the Programming
team must start again by fixing the build.
-
Once the Smoke Test passes,
the Testing Team fully tests the software.
-
Triage is held to discuss
defects and plan new releases.
-
This iteration continues
until a certain level of compliance is met (like no severity
1 or 2 defects).
Iteration Explained in
Detail
Once
coding begins, the budget has been set and all requirements
are locked. If any requirements change, the change must
be documented and the impact on the schedule must to be
accounted for. This normally means extending the
timeline, and it must be fully approved by the client before
this is allowed.
As coding is progressing, the
programming team leader should regularly perform "code
reviews". Code reviews are an inspection of the code to
ensure that the code is meeting the functional specification
and it is adhering to standards that have been set.
Major issues become minor issues if caught early, so the code
review is a critical part of best practices.
As the programming team is
coding the software, the testing team creates their detailed
test cases that will be run once coding is
complete. The first set of test cases is a subset
of the full test case suite and is called a "smoke
test". These are the 10 or so critical things that the
software must accomplish before it is worthy of a much more
robust testing cycle.
As soon as the programming
staff has deemed that they are "code complete", the testing
team will run their "smoke test". If it fails, all
testing ceases until the programming staff has a build that
passes the smoke test. Once this happens, the testing
team will begin testing the software using their predefined
test cases. They will also do ad-hoc and regression
testing to ensure adequate test coverage.
During the testing process,
the Testing Team will hold "triage meetings". Triage is
where the Test Lead meets with the Programming Lead to review
the list of defects found in the software. If
programmers are disputing the validity of defects, it is
resolved in Triage. Triage is also where new builds are
coordinated. The Programming Lead and Test Lead will
decide when a new build is warranted and the Testing Team will
iteratively run their Smoke Test, Regression and Test Cases on
new builds. Normally, triage is held weekly, at a
minimum.
As part of the initial test
plan, the testing team should have documented the criteria for
moving from Quality Assurance Testing to User Acceptance
Testing. This is normally a criteria based on severity
(e.g. no severity 1 or 2 defects). Using this
criteria, the team can all agree when the software is ready to
be moved from Quality Assurance testing to User Acceptance
testing. Once this criteria is met, the Testing Team
signs off on the release, allowing it to move to User
Acceptance.
User Acceptance Testing is
where the user runs the software in a pre-production
environment. They test the software for any variances to
the functional specification. At times, new requirements
will come out of this iteration. If this happens, the project
manager must work with the client to determine if the new
requirements can be postponed to a future release. This
is the preferred approach, but sometimes the requirements are
critical for this initial implementation. If that
happens, the project is re-budgeted and a new timeline is
created to accommodate this.
Similar to the testing
process, the users should have documented the criteria for
moving from User Acceptance to Production. This is
normally a criteria based on severity (like no severity 1
defects). Using this criteria, the team can all agree
when the software is ready for production. Once this
criteria is met, the User Acceptance team signs off on the
release, allowing it to move to
production.