White Box Tests done in Teams

Code-inspections  and walk-throughs  -- the two chosen representatives for white box tests done in teams -- have been two of the first methods of testing  without the use of a computer (this is also called ``human testing''). These test have a lot in common and share the same basic idea. They are static test methods  which can already be used in very early phases of the development process. This makes it possible to detect faults  in a stage in which they can still be removed without causing extremely high expenditures.

To give a better survey, the common order of events for these tests will be given now. They will be discussed in detail later in this chapter.

First, the team is assigned. Each member gets enough information so he can be well prepared when the team meets for the first time a couple of weeks later. During this meeting which lasts approximately two hours and should not be interrupted, an exact list of all faults found is produced. It is important that the group does not start to look for solutions, because this would require too much time and it would distract them from their work. They are only supposed to find the bugs -- once more, testing is counterproductive .

There is disunity in the literature about the ideal size of this team, but five persons are not a bad choice. Now, who should to be in such a team to have an optimal chance of success (see also [ieee89])?

• The manager  is the most important member of the team. He is the organizer, chairman , and responsible for the whole enterprise. It is absolutely required that he is acknowledged by all other members for his personality, and his specialized knowledge, and qualification. He has to control and lead the meeting , make sure that all bugs found are recorded correctly, and removed after the meeting. Last, but not least, he has to decide if it is necessary to meet again. Later he has to control if all faults found have been fixed.
• The design engineer  who has to contribute his know-how about design to the group. He should not be one of those who made the design of program which is tested; he only has to have specialized knowledge about designing such a product.
• The programmer who has to contribute his knowledge about the programming language used. He also has to know a lot about coding in general. He must not be the one who coded the tested program.
• The tester  who has to be an expert on procedures like this. It is his job to control the process in a way it is more likely to detect faults.
• The keeper of the minutes who should relieve the manager's administrative job and who should make sure that everything done gets recorded.
• The author  who wrote the program the group is testing.
• And last, but not least, the user  who should keep up the connection to the ``outside world'' . He might spend hours without understanding anything the experts are talking about, but if he is able to find one single fault , he has already made up for his costs. He also increases the products quality  if he manages that the final product is more similar to other user's expectations .

• Code Inspection
• Walk Through
• Summary