Design Process - Testing & Tracking Changes
Unit Testing
Unit testing is another important technique
we like to use during and after coding. To be honest, most developers
hate writing test cases and enforcing this practise can be difficult.
Also, management may not be willing to provide the developers the extra
time required to write unit tests. However the benefits of unit testing
are so great that we would always strongly encourage its use on any
project.
Unlike functional tests, which treat the
system as a black box and ensure that the software works as a whole,
unit tests are written to test the fundamental building blocks of the
system from the inside out. Developer's write and own the unit tests.
When development iteration is complete, the tests are promoted as part
and parcel of the delivered component as a way of communicating:
"Here's my deliverable and the tests which verify it."
As such, the goal of unit testing is to
improve the quality of the implementation code by testing core
components of the application on a regular basis. By writing tests,
developers can quickly run the tests after changing the code and gain
confidence that the changes didn't break anything. Unit testing will be
part of the build process to ensure that when a new build is done, the
sanity of the build will be verified since all major components tests
will be run before the build is released. This ensures that the build
will have passed basic sanity testing before it is given to the test
team for formal user testing.
A test case should strive to test a
particular functionality of the product. It is not necessary for
developers to write unit test cases for every class they write. Instead
developers should strive to write tests that will target major
components and/or workflows of the system. The goal is not to gain 100%
class coverage but to ensure the sanity of every build before it is
given to the test team for formal user testing. When deciding whether
to write a test case, developers should ask themselves the following
questions:
- Would the integrity of the system be compromised if this test element failed?
- Would the test raise developer confidence in the sanity of the build?
- Is a test defined for all major workflows of the use case?
If the answers to the above questions are
true and the test element is not adequately tested within another test
case, then the developer should write a test case for it.
Tracking Issues
Tracking issues using an issue and/or bug
tracking tool seems pretty obvious yet you would be surprised as to how
many projects don't do this. On one project we saw the Test Manager
e-mail the bugs he found to each developer. Their inboxes soon got
flooded with outstanding bugs. Or the manager would track key project
issues in Excel.
Nobody writes their code in Notepad anymore
so why do so many projects still track issues manually. A good issue
tracking tool should be standard on all software projects. It should
not only allow your team to enter new issues but it should also provide
the following information:
For management, an issue tracking tool
should provide reports as to how many issues are outstanding, the rate
that they are getting fixed, and the environment that they are being
found in.
Often times the issue may require multiple
changes to resolve the problem. For example, a code change and database
change may be required. An issue tracking tool allows multiple
developers to work on the same problem. The first developer can apply
their fix and forward the issue to the next developer. An issue and/or
bug tracking tool is so critical to a project success that no
development and testing should be performed without one.
Return to Design Process
|
