Wir in Bayern befinden uns ja eigentlich in der “staaden Zeit”, in der besinnlichen Adventszeit, in der wir nach dem Motto des Rattenberger Advents “die Ruhe im Herzen finden” sollen. Aber kann sich das ausgehen, wenn die heiße Testphase einer sehr umfangreichen Web-Anwendung in diese Zeit fällt?
Leider nein. Die besinnlichen Abende bei Kerzenschein werden durch Kunstlicht und Bildschirmflackern ersetzt und rot sind bei mir weniger die Krzen am Adventskranz denn die Augen…
Aber da ich hier ja nicht auf die Tränendrüse drücken und mich bedauern lassen will, hier nun ein paar konkrete Gedanken und Erfahrungen vom Testen. Ich warte nämlich gerade drauf, dass die Programmierer die neue Version einspielen, in denen wieder ein paar mehr Bugs behoben sind, und habe also etwas Zeit.
Testen – da fallen mir 4 verschiedene Ansätze ein:
Ich spiele Anwender und arbeite so mit der Anwendung, wie das später einmal der Fall sein soll. Da ich als Autor des Fachkonzepts natürlich alle Feinheiten kenne, teste ich in dieser Rolle zunächst nur das Verhalten der Anwendung bei bestimmungsgemäßem Gebrauch. Was der boshaft “DAU” (dümmster anzunehmender User) genannte Anwender vielleicht tun könnte, kommt mir natürlich nicht in den Sinn. Aber wenn mein Anwendertest keine Fehler mehr zeigt, ist schon fast die halbe Miete drin.
Ich nehme mir das Fachkonzept zur Hand und vergleiche Stück für Stück, ob alles passt. Ich gehe die Abbildungen der Dialoge durch und vergleiche, ob alle Felder vorhanden sind und alle Texte passen. Ich führe die genannten Benutzeraktionen durch und prüfe, ob sie das spezifizierte Verhalten hervorrufen. Das ist zum Anwendertest sinnvoll, denn von den über 100 Seiten Fachkonzept habe ich natürlich nicht mehr jedes feine Detail imKopf.
Ich werde zum anwendungsorientierten Tester. In dieser Rolle teste ich bewusst auch den nicht bestimmungsgemäßen Gebrauch der Anwendung. Nach dem Motto “garbage in, garbage out” kann ich zwar nicht erwarten, dass eine Anwendung aus nutzlosen Eingaben Gold macht. Ich erwarte aber schon, dass sie mich zumindest einigermaßen führt und versucht, auf den Pfad zu sinnvollen Angaben zurückzubringen.
Man kann es kurz ausdrücken: Auch wenn sich der Anwender auf die Tastatur setzt, darf die Anwendung nicht abstürzen, sondern muss in einem definierten Zustand bleiben. Wenn sie in einer solchen Situation die Fehlermeldung ausgibt, dass der Anwender seine Eingaben noch einmal überprüfen soll, weil sie nicht den Erwartungen entsprechen, wäre das beispielsweise eine gute Reaktion.
In Fachkreisen wird hier auch von Extremwert-Testfällen gesprochen. Bei einem Eingabefeld für Buchstaben sollte man z.B. auch einen Test mit der Eingabe von Zahlen oder Sonderzeichen durchführen. Auch unsere deutschen Umlaute erweisen sich in der aktuellen Anwendung als böse Stolpersteine, die nicht immer korrekt angezeigt werden.
Kann ein Eingabefeld nur eine maximale Zahl an Zeichen aufnehmen, sollte man auch ausprobieren, was passiert, wenn man an diese Grenze bzw. über diese hinaus geht. Ich hatte gestern beispielsweise den – fast lustigen – Fall, dass mit der Eingabe des letzten zulässigen Zeichens meine numerierte Liste in eine durchgehende Zeichenkette umgewandelt wurde…
Können Bilder in die Anwendung hochgeladen werden, lohnt es sich auch, einmal zu testen, wie mit Bildern verschiedener Größe verfahren wird. Zwar ist es gemein, ein fast 1 m breites Bild in ein maximal 10 cm breites Bildfenster hochzuladen, aber genau das sind die Extremwerte. Ich erwarte nicht, dass dieses Bild dann noch erkennbar ist. Aber ich erwarte, dass es unter Beibehaltung der Relationen aus Höhe und Breite so verkleinert wird, dass es im vorgesehenen Rahmen Platz findet.
Dann gibt es noch einen weiteren Ansatz, mit dem die Studenten in Informatik-Studiengängen im ersten Semester vertraut gemacht werden. Es handelt sich allerdings eher um einen theoretischen Ansatz, der nicht nur die imperative Programmierung sondern auch kleinste Programmieraufgaben voraussetzt, die nur in Klausuraufgaben, nicht aber in der Praxis vorkommen. Die Idee hinter diesen Tests zur Pfadüberdeckung ist, dass jede Zeile des Code im Test einmal durchlaufen werden muss. So wird geprüft, ob alle if/then/else-Weichen und Schleifen durchlaufen werden oder überhaupt erreichbar sind.
Aber da ja heute überwiegend objektorientiert programmiert wird, entfällt diese Möglichkeit zum Test schon aus diesem Grund. Und selbst bei einer COBOL-Anwendung, an der ich noch vor einem Jahr mit programmiert habe, waren sie aus mengenmäßigen Gründen nicht durchführbar.
Je nach Anwendung werden gegen Ende auch noch Performance- oder Lasttests durchgeführt, um festzustellen, was passiert, wenn der erhoffte Ansturm der Nutzer kommt.
Den abschließenden Test, den Abnahmetest, wird dann natürlich der Kunde durchführen. Er wird die Anwendung sicher auch noch zusätzlich aus dem Blickwinkel des Anwenders betrachten und prüfen, ob alle Abläufe leicht verständlich und intuitiv sind…und welche weiteren Features in der nächsten Ausbaustufe nachgeschoben werden.
Wie ist das nun mit den Fehlern? Muss sich der Programmierer für jeden gefundenen Fehler schämen? Kriegt der Tester für jeden gefunden Fehler ein “Gutzetterl”? Die fehlerfreie Anwendung gibt es nicht. Das lernt man auch schon im 1. Semester Informatik. Fehler passieren immer, das ist ganz normal – also Entwarnung für den Programmierer. Und solange er und der Tester nicht zu dem Irrglauben kommen, sie befänden sich in einem persönlichen Kleinkrieg, ist die Welt in Ordnung. Das Ziel ist eine Anwendung, die so fehlerarm wie möglich ist. Logischerweise ist das bei einer Anwendung, die beispielsweise eine Mondrakete steuert, wesentlich enger auszulegen als bei einem unbedeutenden Spiel.
Meine Programmierer haben mir nun die neue Version geliefert, und ich “mutiere” wieder zum Fehlerdetektiv.
Über die Anwendung wird nach den Go-Live sicher auch hier noch zu berichten sein, denn es ist eine höchst interessante Geschichte. Aber ein bisschen Geduld ist noch erforderlich.
Verpassen Sie keinen Beitrag und abonnieren Sie unseren RSS-Feed.
Testen einer Web-Anwendung
admin, 18. Dezember 2007 kein Kommentar RSS
Wir in Bayern befinden uns ja eigentlich in der “staaden Zeit”, in der besinnlichen Adventszeit, in der wir nach dem Motto des Rattenberger Advents “die Ruhe im Herzen finden” sollen. Aber kann sich das ausgehen, wenn die heiße Testphase einer sehr umfangreichen Web-Anwendung in diese Zeit fällt?
Leider nein. Die besinnlichen Abende bei Kerzenschein werden durch Kunstlicht und Bildschirmflackern ersetzt und rot sind bei mir weniger die Krzen am Adventskranz denn die Augen…
Aber da ich hier ja nicht auf die Tränendrüse drücken und mich bedauern lassen will, hier nun ein paar konkrete Gedanken und Erfahrungen vom Testen. Ich warte nämlich gerade drauf, dass die Programmierer die neue Version einspielen, in denen wieder ein paar mehr Bugs behoben sind, und habe also etwas Zeit.
Testen – da fallen mir 4 verschiedene Ansätze ein:
Man kann es kurz ausdrücken: Auch wenn sich der Anwender auf die Tastatur setzt, darf die Anwendung nicht abstürzen, sondern muss in einem definierten Zustand bleiben. Wenn sie in einer solchen Situation die Fehlermeldung ausgibt, dass der Anwender seine Eingaben noch einmal überprüfen soll, weil sie nicht den Erwartungen entsprechen, wäre das beispielsweise eine gute Reaktion.
In Fachkreisen wird hier auch von Extremwert-Testfällen gesprochen. Bei einem Eingabefeld für Buchstaben sollte man z.B. auch einen Test mit der Eingabe von Zahlen oder Sonderzeichen durchführen. Auch unsere deutschen Umlaute erweisen sich in der aktuellen Anwendung als böse Stolpersteine, die nicht immer korrekt angezeigt werden.
Kann ein Eingabefeld nur eine maximale Zahl an Zeichen aufnehmen, sollte man auch ausprobieren, was passiert, wenn man an diese Grenze bzw. über diese hinaus geht. Ich hatte gestern beispielsweise den – fast lustigen – Fall, dass mit der Eingabe des letzten zulässigen Zeichens meine numerierte Liste in eine durchgehende Zeichenkette umgewandelt wurde…
Können Bilder in die Anwendung hochgeladen werden, lohnt es sich auch, einmal zu testen, wie mit Bildern verschiedener Größe verfahren wird. Zwar ist es gemein, ein fast 1 m breites Bild in ein maximal 10 cm breites Bildfenster hochzuladen, aber genau das sind die Extremwerte. Ich erwarte nicht, dass dieses Bild dann noch erkennbar ist. Aber ich erwarte, dass es unter Beibehaltung der Relationen aus Höhe und Breite so verkleinert wird, dass es im vorgesehenen Rahmen Platz findet.
Aber da ja heute überwiegend objektorientiert programmiert wird, entfällt diese Möglichkeit zum Test schon aus diesem Grund. Und selbst bei einer COBOL-Anwendung, an der ich noch vor einem Jahr mit programmiert habe, waren sie aus mengenmäßigen Gründen nicht durchführbar.
Je nach Anwendung werden gegen Ende auch noch Performance- oder Lasttests durchgeführt, um festzustellen, was passiert, wenn der erhoffte Ansturm der Nutzer kommt.
Den abschließenden Test, den Abnahmetest, wird dann natürlich der Kunde durchführen. Er wird die Anwendung sicher auch noch zusätzlich aus dem Blickwinkel des Anwenders betrachten und prüfen, ob alle Abläufe leicht verständlich und intuitiv sind…und welche weiteren Features in der nächsten Ausbaustufe nachgeschoben werden.
Wie ist das nun mit den Fehlern? Muss sich der Programmierer für jeden gefundenen Fehler schämen? Kriegt der Tester für jeden gefunden Fehler ein “Gutzetterl”? Die fehlerfreie Anwendung gibt es nicht. Das lernt man auch schon im 1. Semester Informatik. Fehler passieren immer, das ist ganz normal – also Entwarnung für den Programmierer. Und solange er und der Tester nicht zu dem Irrglauben kommen, sie befänden sich in einem persönlichen Kleinkrieg, ist die Welt in Ordnung. Das Ziel ist eine Anwendung, die so fehlerarm wie möglich ist. Logischerweise ist das bei einer Anwendung, die beispielsweise eine Mondrakete steuert, wesentlich enger auszulegen als bei einem unbedeutenden Spiel.
Meine Programmierer haben mir nun die neue Version geliefert, und ich “mutiere” wieder zum Fehlerdetektiv.
Über die Anwendung wird nach den Go-Live sicher auch hier noch zu berichten sein, denn es ist eine höchst interessante Geschichte. Aber ein bisschen Geduld ist noch erforderlich.