A common theme that I have come across when coming onto client sites is that people cannot tell me why they are testing what they are. If I am lucky, the reply is that it is identified in the Test Plan. When I look at the Test Plan however, I tend get 20 to 30 pages of hard work that still does not tell me what and why people are testing.

Now I am not planning on re-analysing the IEEE 829 template test plan. This is a great document and can assist greatly. However I want to look at the overall purpose and necessity to plan. Regardless of the overall development methodology, e.g. SCRUM or Waterfall, some time needs to be spent defining the approach to testing.

Recnetly I provided a short presentation on non-functional testing to the North London BCS group (reported from a participant perspective in an earlier blog). From a presenter perspective it was very good group to present to, with an obvious high level of knowledge and involvement from the group. It is always healthy to be challenged by your piers!

The gist of my presentation was to “remind” people about non-functional testing, identify what it is, some of the myths and challenges and some activities from a management perspective that could be done.

It is a widely held belief that Non Functional testing should be done at the end of the Functional test phase and before/during/after User Acceptance testing.

In practice I believe that this adds too much risk to the programme. What happens if you find a performance defect that requires a major redesign of the functionality? Believe me, this does happen.

The common argument against this is that to create automated scripts, a stable User Interface is required.

Is there any scope for using the term Technical Testing any more? With the standardisation work that is going on by SIGIST at the moment, the word Technical Testing no longer appears. I think that this is valid since Technical testing can mean many things to many people, but does not cover the gamit of Non Functional test areas.

Non functional testing is as it's name states, i.e. testing all other areas of the final solution that are not directly related to the functionality. This includes areas like useability, reliability and performance.