Most full-time software
developers like nothing
better than sitting down and
writing code. Many can sit
down early in the morning
and write code for hours at
a time. Of course, along
with the coding comes the
testing, which many
developers have never
enjoyed as much. But it is
during the testing process
that you really find out
what kind of programmer you
are. Were the hundreds, or
thousands, of lines of code
just so much garbage, or did
testing prove the beauty and
logical strength of your
code? In fact, the software
testing process shows much
more than what a good
programmer you are. It also
shows how well you captured
your business requirements
and how well you designed
your application.
It is worth stating the
obvious about the reason we
perform testing at all.
First, we want to ensure
that the solution meets the
business requirements. For
instance, if a specific
business transaction follows
a logical path from A -> B
-> C -> D, we want our
testing to prove that this,
in fact, happens. Second, we
test to catch errors and
defects. These may be
programming errors or errors
that were introduced earlier
in the development
lifecycle. In other words,
we need to prove that our
solution is correct, while
at the same time proving
that there are no errors or
defects. You may not catch
many errors, but you still
need to prove that the
solution meets the business
requirements.
The essence of testing is
to:
-
Catch as many
errors as
possible
-
Correct the
errors
-
Track the errors
to understand
their causes and
any patterns
that may exist
-
Revalidate the
stability of the
solution,
including
ensuring that
the correction
of one error
does not lead to
the introduction
of another error
somewhere else
|
 |
In some organizations the
testing process is handled
by a separate team of
testing specialists. This
test team is usually very
disciplined in their testing
approach, and they are able
to thoroughly test because
they do not have any
preconceived notions of how
things "should" work. They
only know how the solution
"does" work. The construct
team passes their programs
and test data to the test
team for testing and
validation. The test team
performs the actual testing
and provides feedback to the
construct team on the
success and errors
encountered.
However, it is more typical
for the Test Phase to be
completed by the same group
of people who worked on the
Construct. This has some
benefits in terms of their
familiarity with how the
solution is supposed to
work. They also have the
advantage of being able to
quickly go from testing
error to code correction and
then back to testing again.
Both organizational models
are valid and are used
successfully in many
companies.
Some Basic Tenets of Testing
Regardless of the type of
project you are on, you want
to catch as many errors as
early in the lifecycle as
possible. There are projects
that purposely blast through
the Analysis, Design and
Coding Phases with a
philosophy that they will
fix all the problems in
testing. This is usually
disastrous. It’s not so bad
to correct programming
errors that you discover in
your testing. It is much
more difficult when you
realize that a design error
resulted in information
missing from your database.
It is even harder if you
discover that your analysis
missed an entire business
process.
At the same time, you cannot
ensure that your software is
perfect. Even with the best
tools, it is impossible to
test every logic path of
every program. Therefore,
you cannot ever be sure that
your code is bug-free. There
are times when software that
has been stable for ten
years suddenly breaks
through an unlikely
combination of circumstances
that never occurred before.
(These are “subtle” bugs.)
Since you cannot build the
perfect, bug-free system,
the project team needs to
understand the cost of
testing and when the cost
exceeds the benefit. You can
get into a lot of trouble if
your testing is not rigorous
enough. However, testing too
much can be a waste of
precious resources as well.
You can’t deliver a perfect
system, but you can
determine how much testing
makes sense given the
characteristics of your
project. Building an
internal application to
track client complaints does
not need the testing rigor
that was required for the
Apollo moon mission.
The Testing Process
The Test Phase is toward the
end of the traditional
waterfall development
process. However, hopefully
this is not the first time
you have thought about
testing. Depending on the
characteristics of your
project, you may already
have created an initial
Testing Strategy in the
Analysis Phase and a
Testing Plan in the Design
Phase. You would have
already performed initial
unit testing in the
Construct Phase. Now,
however, you are ready for
the standalone testing
process that belongs in the
Test Phase.
Note again that some
methodologies combine the
testing process into the
Construct Phase.
LifecycleStep breaks out the
formal testing process into
its own phase to provide
emphasis on the focused
testing that takes place at
this time. If the testing
process uncovers error and
bugs, the team will need to
correct them, which will
mean briefly going back to
the construct and unit test
process. However, some
errors may also require you
to backtrack further and
make design changes. In
fact, you may encounter
major errors that could
impact your requirements.
This could be caused by
determining that certain
requirements were missed or
that certain stated
requirements need to be
modified to accommodate
problems that were uncovered
in the testing process.
There are a number of
specific tests that can be
part of the testing process.
The specific ones your
solution needs will be
defined in your testing
strategy and plan.
441.0 Validate Test Coverage
442.0 Integration Testing
443.0 System Testing
444.0 Acceptance Testing
448.0 Re-plan for the
Remainder of the Project
449.0 Obtain Approval to
Proceed
Supporting Templates
-
Test Cases
-
Test Script
-
Test Case Validation Log
-
Test Error Report
-
Test Error Log
