Testen aber richtig (einfach)

Warum schreiben über das Testen? Wo es doch so viel schönere Dinge in der Softwareentwicklung gibt?

Ich arbeite in einem kleinen Team und wir haben Jahre gebraucht, um unsere Testsystematik auf ein solches Niveu zu bringen, dass wir sagen können: a) wir testen effektiv und b) wir testen effizient.

Grund genug mal etwas über den Test anzureißen. Was fällt mir denn da so ein?

  1. Qualitätssicherung und Test – eine Landkarte
  2. Test hat doch nur 2 Ziele!
  3. Testziele und Testplanung – ohne geht nicht
  4. Testläufe und Ergebnisse – nur Looser brauchen Bugtracker

Die QS-Landkarte

Um die gewünschte Qualität zu erreichen, reicht natürlich stumpf los zu testen genauso wenig, wie stumpfes Coding meistens nicht so das richtige Mittel für guten Code ist.

Zunächst sollte man sich damit abfinden, dass der Test keine Phase nach der Kodierung ist, sondern in allen Phasen verschiedene Maßnahmen durchgeführt werden müssen, um die richtige Qualität zu erzielen. Zunächst erfordert dies etwas Planung.

Die Planung kann eine einfache Mind Map sein, wo ich mir z.B. Fragen beantworte wie „was soll getestet werden“, „was haben wir für Ziele damit“ oder „wer testet mit welchen Mitteln“. Das ist also eine klassische Managementaufgabe und natürlich sollten wir das Lenken und Prüfen, sprich den Plan allen Projektbeteiligten freundlich eintrichtern und die Einhaltung des Plans dann überprüfen.

Wenn der Bug im Code einmal drin ist, ist es schwer diesen aufzufinden und zu entfernen. Das Gegenmittel heißt konstruktive Qualitätssicherung. Dies sind alle Maßnahmen die Fehler zu vermeiden helfen. OOP wird per se oft schon als fehlervermeidend angesehen (ich habe dazu meine eigene Meinung), natürlich helfen auch Style Guides und Checklisten.

Die analytische Qualitätssicherung beschäftigt sich damit, die Fehler zu finden, die real entstanden sind. Zu selten eingesetzt wird meiner Meinung nach die statische Analyse und besonders Reviews. Reviews haben nämlich neben dem Finden von Fehlern auch den Vorteil der Selbstreflektion und können Anregung für neues Design sein. Auch ich habe hier eine kleine Technik entwickelt: das Design Problem Chart. Ja, ich erhebe den Anspruch der Erfinder davon zu sein! So viel Eitelkeit muss sein.

Die dynamische Qualitätssicherung ist nun endlich das, was wir eigentlich unter Testen verstehen. Hier können Unit Tests, Integrationstests und Systemtests abgefackelt werden. Für Tests gibt es unendlich viele Methoden und Werkzeuge. Wenn man will,  kann man also auch eine Wissenschaft daraus machen.

Man kann übrigens auf zwei grundverschiedene Arten testen: to spec und to error . Im ersten Fall testet man, ob das Erwartete funktioniert, z.B. ob die erwarteten Funktionen realisiert sind, ob das spezifizierte technische Design die erwarteten Lastszenarien aushält und ob das UI-Design so gut wie erwartet ist. Im zweiten Fall testet man das, was nirgendwo niedergeschrieben steht, ja was niemand geäußert oder nur im Entferntesten daran gedacht hat. Auch dies lässt sich auf das Produktdesign, das technische Design und das Layout beziehen.

Test hat doch nur 2 Ziele

Wenn man sich in den Tiefen des Softwaretests befindet und irgendeine neue tolle Technik zur Testautomatisierung umsetzt, kann man leicht vergessen was die Ziele des Tests sind:

  1. Fehler zu finden
  2. Vertrauen in das System zu gewinnen

Wenn ich mich z.B. mit Details von Unit Tests beschäftige, mich z.B. gerade in eine Mock-Bibliothek einarbeite, dann sollte ich im Hinterkopf haben, dass ich mit Unit Tests normalerweise keine Fehler finde. Unit Tests sind dazu da, um Vertrauen in den eigenen Code zu gewinnen. Natürlich ist dies ideal in Verbindung mit einer Metrik. Fehler finden kann ein Unit Test eigentlich nur bei Refactorings oder in Ausnahmefällen bei komplizierten Algorithmen, deren Seiteneffekte man beim Entwurf kaum überblickt.

Das andere krasse Beispiel ist ein freier Test. Ein guter Tester findet immer Fehler. Und wenn er dazu fiese Tricks verwendet, wie komische Sprachen mit fremden Schriftzeichen, eine Manipulation des Keyboard-Kabels oder das Installieren von seltenen Windows-Patches. Irgendwie kriegt man Software immer tot. Bei dieser Methodik wird man aber sicher kein Vertrauen in die Software gewinnen.

Man sieht, um beide Ziele zu erreichen, benötigt man mehr als eine Art von Test. Ein Test der nicht mind. einem dieser Ziele dient ist unnütz.

Testziele und Testplanung

Am Anfang eines Projektes muss man schon so viel machen, jetzt auch noch eine Planung des Tests? Muss das sein?

Ja! Aber das kann man eigentlich in einer Stunde erledigen. Der Testplan meiner Software KnowMyUsers sieht z.B. ganz simpel aus:

Testplan KnowMyUsers 

Was wird getestet?

Alle Funktionsteile werden getestet, alle Features, alle Masken, Layout in gängigen Browsern, Konsistenz Layout. Es wird sowohl Client (die Tracking-Library), als auch der Server (AppendLog, Dashboard) getestet.

Warum wird getestet?

Es geht darum Features in der Benutzbarkeit zu verbessern, Fehler zu entdecken und Vertrauen in die Anwendung aufzubauen, denn es soll ein stabiles, performantes Produkt für den kommerziellen Einsatz geschaffen werden.

Wann?

Es gibt keine feste Zeitplanung. Der Test erfolgt abends, sowie am Wochenende.

Wo?

Der Test erfolgt auf dem produktiven Webserver unter 64bit, sowie in einem virtuellen Image mit einer Demoversion des Windows Server 2008 32bit.

Die lokale Installation zählt nicht als Testumgebung (da leichte Abweichungen zwischen IIS-Versionen).

Für verschiedene Webbrowser wird ein virtuelles Image verwendet.

Wie?

Die Testausführung erfolgt manuell, bzw. in wenigen Fällen automatisiert. Die Verwaltung erfolgt systematisiert mit einem Test-Case-Management Werkzeug.

Womit?

IIS6, IIS7 + MVC3. Testlink, NUnit, WatiN

IE9, IE8, Opera, FF, Chrome, Safari

SQLite-Admin, http://sqliteadmin.orbmu2k.de/

Von Wem?

Nur von mir.

Testläufe und Ergebnisse – nur Looser brauchen Bugtracker

Bugtracking-Systeme gibt es ja zuhauf. Produktiv habe ich außer Mantis noch nie ein anderes eingesetzt und es ist sicher nicht das schlechteste Tool.  So ein Bugtracking ist also eine feine Sache und dass man es braucht, steht ja seit dem Joel On Software Test außer Frage. Und es hat ja gleich auch noch so viele tolle Reports, wo man sehen kann, welches Modul wie viele Fehler hat. Ist doch alles toll oder?

Für Software-Maintainance ist Bugtracking perfekt, aber für Weiterentwicklungsprojekte sind es behäbige Werkzeuge.

Ich verrate hier mal ein Geheimnis: Nur Looser brauchen Bugtracker.

Wenn Sie Bugtracker während der Entwicklung brauchen, haben Sie wahrscheinlich ein schwaches Vorgehensmodell, was viel zu spät testet, nicht agil ist und Sie ziemlich viel Zeit und Geld kostet.

Die Grundlage für effektive und effiziente Testläufe ist eine gute Entwicklungsplanung. Beim Work Break Down müssen Iterationen geplant werden, wo jedes Endergbnis „lieferbar“ bzw. „installierbar“ ist. In einer Iteration wird konzipiert, entwickelt und getestet. Alle Bugs werden in dieser Iteration behoben. Das Zauberwort heißt in diesem Zusammenhang „sofort“. Wenn Sie in einem Test 2 Bugs entdecken und diese dem Entwickler einfach nur „sagen“, kann er die sofort beheben. Wenn der Entwickler aber bereits 10 Entwicklungspakete in der „Hardening“-Phase hat und der Tester seine Bugs, die eigentlich recht trivial sind in eine lange Liste von Bugs einreiht, wird die Reproduktion immer schwieriger. Was ich vor 2 Wochen getestet habe, kann ich heute doch nicht mehr reproduzieren!

Natürlich sollte man den Testlauf schriftlich protokollieren, denn wenn man 20 Fehler findet, kann man sich die nicht alle merken. Aber dazu benötige ich kein kompliziertes Tool, welches eine Versionierung der Testfälle vorhält. Es reicht eine einfache Textverarbeitung und ein Screenshot-Tool. Hier ein Layout-Fehler, da ein Textfehler und hoppala, hier ist ein Rechenfehler.

Fazit

Testen tut jeder, aber mit einem vertretbaren Aufwand eine gute Qualität zu erzielen, dass ist die Kunst. Zwar benötigt man sicherlich gute Tools, wie zum Testfallmanagement oder zur Testautomatisierung, aber Tools und das Detail-Know-How sind gar nicht das Entscheidende. Viel wichtiger ist es, den Test richtig einzuordnen, denn dann kann man schon mit einfachen Mitteln viel erreichen.

Nachtrag: diese grundsätzlichen Best Practices habe ich in dem Tool Quality Spy abgebildet.