Testing times

Smith: Testing is important and should be done thoroughly

In technology testing, organisations need to balance being first to market with being the best in the market. In most businesses, a sales and marketing team will push for products to be ready for certain market conditions, to be ahead of competitors and to position the organisation as a leader.

This, however, is an issue when testing security products. Testing cannot be rushed.

A semi-formal approach to testing will help keep things relevant to the real world.

Many have used mathematical testing to prove a product is robust and safe. However, some of the maths behind the software testing algorithms has been demonstrably flawed.

Some organisations do not use validation testing, instead releasing a beta and correcting errors and bugs as they go along.

Yet you need to prioritise the risks involved. For example, online banking products must be deemed safe before they are introduced to customers.

Testing also needs to be as efficient, accurate and fast as possible. There may be millions of lines of code written by a programmer who has left the company. The code might be hard to understand and, even if a bug is found, difficult to fix. A new programmer could therefore need to start from scratch.

Many issues can be easily overlooked in the rush to get a product to market. Unfortunately, testing is often seen merely as an overhead.

Many program managers struggle to articulate their ideas and plans and often find themselves under pressure from marketing and sales managers to deliver a product to market before it is adequately tested.

The commercial reality of needing to get a new product to market must be balanced with a tester’s typical risk-averse attitude. There needs to be an effective, productive compromise.

Product stability must be tested and questions such as "does it do what it says?" and "does it do what the marketing and sales department has asked for?" answered. Ease of use is also critical.

One of the main reasons Apple has been a success is because of its focus in the early days on the human/computer interaction aspect of its products. Apple tested its user interfaces to assure they could be used by anyone and that everything was where a user would expect to find it.

Developers, solution providers and integrators must follow this example to keep customers satisfied.

Quality control is vital. Situations where an application allows a user to enter a number between one and 10 must be tested and validated. A product must be able to cope with irregular input and exception trap reliably.

Some leading firewall products let users enter any syntactically incorrect data and then give obscure error messages. When the product compiles the policy, in some cases it crashes as the data was incorrect.

Many of the exploits on banking sites that we hear about are from bad coding. Banks have realised this over the past few months and are now investing in accurate code checks.

It is not possible for businesses to stay competitive if products need to be constantly redeveloped and bugs removed.

The more time spent in the early stages of a software production cycle, the better the results and cost efficiencies at the later stages. A bug found during the requirements specification or design is cheaper to fix than the same bug found later in the testing phase.

One way of ensuring a product is meeting the original objectives is to break the process down into smaller projects. This allows developers to see clearly if they are on target.

Use object-oriented techniques to ensure proven and robust code is used and reduce overall development times. Over time, businesses can develop lots of objects for different tasks. This creates a pool of re-usable code, which can prove invaluable with future projects.

Programmers should ensure also that they annotate and document their coding so another programmer can edit and develop the code further with ease.

Steve Smith is managing director at Pentura