QWE2000 Session 5T

Ruud Teunissen [Belgium]

Improving Developer's Tests

Key Points

Presentation Abstract

This paper discusses the reasons for improving the developers' tests. Next, a practical approach is given for improving the quality of the developers' tests (i.e. program test and integration test). The emphasis of the approach is on: The paper concludes with two case-stories.
Testing theory states the importance of early testing. The developers perform one of the earliest forms of testing. There is sufficient literature on how this kind of testing should be performed, including a lot of techniques and tools. However, there is a large gap between theory and practice. In practice, developers often test based on their intuition and in an unstructured way, in stead of using techniques, etc. Based on our own experiences, this paper gives reasons why better developer testing is important and how improvements can be implemented. The paper concludes with two case-stories. Our experiences originate from the world of administrative automation (financial institutions, government, industry), and "new media" projects (such as internet, knowledge management, data ware housing).
Characteristics of developers' tests
Typical developers' tests are the program test and the integration test. Some characteristics of these tests (and differences with other types of tests) are:
Should developers' tests be improved?
When asking the developers whether their ways of testing need improvement, frequent answers are: There are of course a number of reasons for improving developer testing: These arguments sound good enough, but in practice seldom win from the arguments given against improvement. However, there is a new development adding arguments in favour of improving. This important development is the increasing strategic use of software, i.e. supporting the primary business of an organisation, directly dealing with the customers and readily adaptable to new challenges. This means a different kind of customer than the traditional IT department, demanding quality software delivered in time. Improving only system and acceptance testing will result in failing to meet these "in time" demands. Improving developers' tests is an important step towards meeting the demands.
How to improve? An approach
Below, a practical approach on how to improve developers' tests is described. The approach has the following key aspects:


Perhaps the most important aspect of the approach is that an Application Integrator (AI) will be made responsible for the progress of integration and for the quality of the outgoing product. The AI negotiates with the project manager or the development team leader what level of quality is required: under what conditions can the system be released to the next phase (exit-criteria). The AI also demands insight in the quality of incoming modules or programs (entry-criteria). A module or program is only accepted into the integration process if it meets the entry-criteria. In order to prevent mixing interests, the AI should not be development team leader. This creates a deliberate tension between the AI, who is responsible for quality, and the development team leader, who tends to focus on functionality and the amount of time and resources spent. Since the AI is a member of the development team, this generates far less resistance from the developers against improving their testing than other test approaches would do and considerably raises the awareness of quality within the development team. For test specific expertise, test professionals (outside of the project) support the AI. The AI communicates with the customer on quality issues. Because communication is essential, it is very important for the AI to have good social skills.

Use of test design techniques

The approach does not prescribe 100% use of formal test design techniques, as this will (in our experience) generate too much resistance. Instead, the AI, program testers and project manager or development team leader negotiate: important parts of the system will be tested using formal test design techniques, less important parts will be tested using informal techniques or even in the old-fashioned, undocumented way of testing without use of any techniques. A good balance has to be found, for which several aspects play a role:

Popular techniques often applied in our projects are checklists and marking test situations in the functional specifications. Only test situations too complex to be tested directly from these markings are detailed further into specific test cases. Although definitely not watertight, the marked up documents supplied with the tester's initials serve as test evidence.

Use of a test life-cycle model

Exit- and entry-criteria and other agreements are laid down in a test plan (phase 1), test cases are prepared (phase 2) and executed (phase 3). Again, practical use prevails: writing documentation such as a test plan is not a target in itself, but serves as a means of communication between project leader, AI and customer, and should be kept as minimal as possible.

About the Speaker

Since 1989, Ruud Teunissen is employed in the testing world. He has been involved in a large number of ICT projects and has performed several functions within the testing organization: tester, test specialist, test advisor, test manager, etc.

Based on his experience, Ruud participated in the development of the structured testing methodology TMap and is co-author of several books on structured testing. The last years Ruud is involved in implementing structured testing within organizations on the Belgian and Dutch market.

At this moment Ruud is working in Belgium for Gitek n.v. as Manager Testen. Ruud is frequently speaking in Benelux and Great Britain.