Testverfahren
Was testet man eigentlich? Gerne werden verschiedene Testmethoden durcheinandergewüfelt. Hier meine persönliche Einteilung:
Ebene 1: Unit-Tests (Klassentests)
Test der einzelnen Funktionen (oder Klassen, je nach Sprache). Diese Tests werden leider sehr vernachlässigt, sind jedoch absolute Basis des Erfolgs. Man kann mit JUnit-Tests automatisieren. Wichtig bei diesen Tests ist es, die Fehlerfälle zu testen. Schon hier muss zwingend eine Fehlerbehandlung bei falschen Eingaben erfolgen. Beim Extreme-programming schreibt man die Tests und dann erst die Klasse!
Die Tests werden durch die Entwicklung definiert und durchgeführt.
Ebene 2: Komponententests
Die nächste Stufe. Machen die Softwarekomponenten, was sie sollen. Auch hier: Automatisierung rules! Die Tests werden durch die Entwicklung definiert und durchgeführt.
Ebene 3:Integrationstests
Der erste Test, ab der Kunde beteiligt wird: Läuft die Software in der gewünschten Umgebung? Die Tests werden gemeinsam von Betrieb und Entwicklung definiert und durchgeführt.
Ebene 4: Oberflächentest
Wichtig (nicht nur) bei Web-Frontends. Passen allen Links? Passt die Fensterbreite etc. Hier dürfen die Anforderer testen.
Ebene 5: Abnahmetests, BlackBox
Achtung Falle! Hier testet man die Applikation gegen das Konzept. Sprich: Macht die Applikation das, was konzipiert wurde. Oft werden bei der Gelegenheit gleich Änderungen mit eingetütet die dem Anforderer in letzter Sekunde eingefallen sind. Das ist in soweit auch legitim, jedoch nicht Bestandteil der Tests. Es werden dann „mal eben“ Änderungen vorgenommen sich sich später in keiner Dokumentation wiederfinden. Solche Änderungen sind Change-Request und gesondert zu behandeln. Die Verantwortung für Planung und Durchführung der Tests liegt bei der Projektleitung.
Weitere Tests:
Last-Tests: Wieviele benutzer schafft die Applikation. Ein sehr aufwändiger, aber wichtiger Test
Usebility-Test: Leider fehlt dafür oft das Geld.
Stress-Test: Extrem Wichtig! Was passiert in Ausnahmesituationen? Man solltest mindestens mal den Server vom Strom-Netz trennen und schauen ob alles wieder anläuft.
Bei der Abnahme unterscheide ich immer zwischen 3 Fehlertypen:
1) Abnahmerelevante Fehler
Die Applikation läuft gar nicht oder so falsche, dass man sie auf keine Fall nutzen darf. Die spezifizierten Prozesse laufen also gar nicht (oder nur teilweise). Der Abnahmetest wird beim Auftreten eines solchen Fehler sofort abgebrochen. Weitere Tests finden erst statt, wenn der Fehler behoben ist.
2) Fehler welche die Abnahme nicht unterbrechen, jeodch verhindern
Diese Bugs verhindern zwar die Abnahme, unterbrechen aber nicht den Abnahmetest. Die Prozesse laufen also nicht sauber, aber sie laufen. Beispiel: Man kann keine Umlaute in einer Adresse eingeben (ja, das ist auchheute noch ein Problem…). Man kann weiter testen, aber die Software nicht sinnvoll nutzen.
3) Fehler, die im Support behoben werden
Diese Fehler behindern nicht die Abnahme (z.B. Schreibfehler, kleine Bugs etc.). Die Abnahme findet statt und der Fehler wird über die normale Gewährleistung behoben.
Und hier noch der ultimative Guerilla-PM Tipp:
Abnahmetests durch projektfremde Personen durchführen lassen. Man drückt den Leuten die Spezifikation/Anforderungsdokument in die Hand und los geht’s. Vorteil: Man kann gleich sehen, ob die Dokumentation was taugt, die Tester machen gleich einen Usebility Test und man kommt nicht in die Versuchung, neue Anforderungen reinzumogeln!
‹ Testen kann Spaß machen Entzugserscheinungen ›