Hinweise, wie man testet und Testberichte schreibt, damit sie allen
Beteiligten möglichst viel nützen.


Ralph Matthes  (19.01.05)


Zielrichtungen: die getestete Gruppe, die Testgruppe, die Praktikumsleitung

Natürlich erhofft sich die getestete Gruppe ein Feedback von Leuten,
die nicht "betriebsblind" sind, also nicht eingefahren in die
Denkgewohnheiten der Entwickler der Implementierung.

Die Testgruppe dokumentiert, was sie getestet hat und kann dann auch
bei Rückfragen gut antworten (und weniger Rückfragen werden nötig). Die
Gruppe ist nicht nur eine Person und testet nicht nur ungestört in einem
zusammenhängenden Zeitbereich, also wird über eine sinnvolle
Dokumentation auch doppelte Testarbeit vermieden.

Die Praktikumsleitung wird auf mögliche Probleme aufmerksam gemacht,
die aus Mißverständnissen oder auch ungünstigen oder gar
widersprüchlichen Vorgaben resultieren. Zudem auf Testszenarien, auf
die man eben nur durch Zufall kommt, die aber doch etwas zutage
gefördert haben. Es ist daran gedacht, Spannendes hierzu auch allen
verfügbar zu machen (passend anonymisiert). Die Praktikumsleitung
benotet die Gruppen nicht und gebraucht die Ergebnisse nicht zu
Scheinentscheidungen, da diese immer individuell und nicht
gruppenbezogen getroffen werden.


Wann man schreibt: möglichst parallel zum Testen. Nachher wird man
selten Lust verspüren, noch einmal alle Eindrücke zu sammeln.
Professioneller noch ist das Schreiben vor dem Test: ein
Testplan. Sinn: Man verliert über dem eventuell anziehenden Spiel die
eigentliche Aufgabe nicht aus den Augen und arbeitet zielgerichtet auf
mögliche Schwächen des Systems hin.

Was man aufschreibt: viel Information, wenig Bewertung. Idealerweise
drängt sich jedem Leser eine Gesamtbewertung auf, wenn er die
vorgetragene Information gesehen hat. Natürlich ist eine lange Liste
von Fehlern ein Negativmerkmal, bedarf aber keines zusätzlichen
Werturteils. Und auch eine Gewichtung kann sehr sinnvoll sein,
z.B. eine Aufteilung in Unschönheiten, Verletzungen der Spezifikation,
kurioses Verhalten in Spezialsituationen, kurioses Verhalten in
Standardsituationen und Fehler, die das Spiel in seiner derzeitigen
Form unbrauchbar machen. Auch das ist mehr technische Information als
Wertung - auch wenn sich daraus eben sofort eine Bewertung ableiten ließe.
Wer andererseits schreibt, daß die Grafik sehr realistisch ist und die
GUI völlig intuitiv und sicher bedienen läßt, der impliziert in diesem
Bereich eine positive Bewertung, spricht sie aber nicht aus.

Was man konkret aufschreibt:

- wer testet (Gruppenname oder auch Person)
- wessen Code benutzt wird (Gruppenname), *evtl.* welche Modifikation der
  im WWW verbreiteten Version vorgenommen wurde (auch beim eigenen Code!)
- konkretes Szenario: welcher Art Rechner (mit welchen
  Betriebssystemen) und welchen Java-Versionen (java -version !) und
  welcher Netzwerkverbindung
- wie man den Code zum Laufen gebracht (in verschiedene Verzeichnisse
  für Server und Client gebracht, entpackt (oder auch nicht), ob das
  alles in der Anleitung stand
- ob die Anleitung hilfreich war (vielleicht braucht man sie gar
  nicht)
- ob gefundene Mängel auch dokumentiert waren (aber auch dann kurz
  ansprechen)
- bei gefundenen Mängeln möglichst das Problem eingrenzen (also
  kleinstmögliches Szenario suchen, wo er auftritt), evtl. Namen der
  Spielvariante (notfalls verwendete eigene Spielvarianten dem Bericht
  beifügen) angeben, Stacktraces in Bericht kopieren, Meldungen von
  Server/Client auszugsweise oder als Datei beigeben. Dies umso
  ausführlicher, je wahrscheinlicher es ist, daß die getestete Gruppe
  den Fehler nicht so leicht reporduzieren kann. 
- wenn kein Mangel auftrat: vermerken, daß man z.B. 5 Minuten lang
  gespielt hat mit n Spielern und dabei zahlreiche Versuche
  unternommen hat, falsche Züge auszuführen

Was nicht zu testen vergessen werden sollte:

- Vertragen mit eigenen Spielvarianten- und Spielverlaufs-Dateien.
- Korrekte Entscheidungen, wer gewonnen hat.
- Funktionsumfang der Spielwiedergabe
- mehrere Spiele mit mehreren Spielern gleichzeitig
- nebenbei Chat im Hauptkanal und in den Spielkanälen (allgemeine oder
  private Nachrichten)
- Wiederanmeldung nach Abschießen eines Clients oder künstlichem
  Netzwerkproblem (Verbindungskabel ausstecken)
- Kann man den Port frei wählen für die Registry?
- grobe Aussagen über Antwortzeiten ermitteln (evtl. Netzlast erfassen)

Noch zwei Tipps: 
- üppige Konsolenausgaben von Server oder Client sollten in Dateien
  umgelenkt werden, damit man nachher noch das gesamte Protokoll hat
- mehrere virtuelle Bildschirme benutzen (jedes Fenster muß sich vom
  Fenstermanager passend verlagern lassen)

Zu guter Letzt:

Bitte beginnen Sie frühzeitig mit dem Testen (also schon gestern!).
"Getting started" ist hier besonders wichtig, da Sie ja am Wochenende
wohl keine neue Version mehr bekommen, auch wenn da nur ein paar
Dateien gefehlt haben. Melden Sie besonders unerwartete und
gravierende Dinge - besonders wenn sie auch andere betreffen könnten -
schon vor der Abgabe des Testberichts, z.B. an die betroffene Gruppe
(deren Mailingliste, die vermutlich vom Gruppenbetreuer moderiert
wird) oder an den eigenen Gruppenbetreuer. Das Diskussionsforum eignet
sich natürlich auch häufig.

Wie im Plenum gesagt, ist ein Großteil dieser Ausführungen weitgehend
evident auf der Basis unserer Anforderungen vom letzten Mittwoch.
Checklisten sind das generell auch und doch oft nützlich. Ich hoffe,
das trifft hier ebenfalls zu.

---