<< Release Control | Complexity in Software >>

Verification and Smoke Testing

<< Release Control | Complexity in Software >>

An important part of the release control process is the verification of the basic functionality of a
particular release. Often errors in the build, assembly or compilation process can result in faults in
the delivered release. Spending time identifying and isolating these faults is frustrating and pointless
since they are simply artefacts of a bad build.

A release should be verified for basic functionality through the use of `smoke tests'. That is, before
it is passed to any other group the team responsible for building a release should run a series of
simple tests to determine that the release is working properly. This catches gross functional errors
quickly and prevents any lag in releases. These tests can be automated as part of the build/release
process and the results simply checked before the release is shipped.

The term `smoke testing' comes from the electronics industry. If an engineer designs a circuit or an

electrical system the first test to be conducted is to plug it into the power briefly and switch it on. If

smoke comes out then you switch it off and it's back to the drawing board (or soldering iron). If no

smoke appears then you it's basically okay and you can try some more tests on it to see if it is

working properly. The same principle can be applied in software development.

A release should be verified for completeness as well.

Often releases can be built without a particular data or configuration file which is required. Part of
the release process should be a simple test which verifies that all of the expected components are
present in a release. This can be done by maintaining a separate list of necessary components
which can then be automatically compared to a particular build to determine if anything is missing.

Release Notes

One extremely valuable piece of documentation that is often neglected in projects is a set of
release notes. Accompanying each release should be a brief set of notes that details (in plain
English) the changes made to the system or product with this release.

The major reason for including release notes is to help set expectations with end users. By
including a list of `known issues' with a particular release you can focus attention on important
areas of the release and avoid having the same issue reported over and over again.

If the release is a Beta release to tester/customers the notes may also include some notes on how
end-users can be expected to log feedback and what kind of information they should provide. If
the release is a normal production release then the notes should be more formal and contain legal
and license information and information on how to contact support.

Release Notes : ABR SDK v3.0.5.29
Delivery Items
This release image contains three separate archive files:

Documentation archive - this archive contains all of the necessary architectural and
installation documentation for the SDK.

SDK Installation Archive - this archive is intended to be installed by users who require a
desktop version of the application.

SDK Require Binaries - an archive containing only the 'executable' portions of the SDK
This archive is intended for individuals who intend to integrate the SDK into an application.

Known Issues
1. Threadpool variation of pool sizes via registry is not enabled
An interim multi-threading model used a number of settings in a registry key that allowed changes to
be made to the number of threads available to the SDK. These settings are no longer used and the
configuration of the threading model is fixed within the SDK.
2. Removal of ABR.DLL
Part of the pre-processor functionality was contained within a separate DLL for historical reasons
the ABE DLL...