Kategorien
Testmanagement
Heute geht’s mal wieder darum, ein wenig von euch zu erfahren. Eigentlich möchte ich mein Gewissen beruhigen, denn es geht um eine Disziplin, die ich in den letzten Jahren sehr vernachlässigt habe, bis mir letzte Woche so ein wenig die Augen geöffnet wurden. Es geht um Testmanagement.
Ich habe ja schon viel über funktionale Tests geschrieben. Selenium wäre hier zum Beispiel ein Buzzword. In den meisten Fällen ist es doch so, man nimmt sich ein Produkt/Feature und testet es mit seinen Werkzeugen, bis man das Gefühl hat es vollständig abgedeckt zu haben. Vielleicht reicht dies in den meisten Fällen ja auch. Aber wann weiß man, wann man genug getestet hat. Wie ist die Abdeckung meiner Anwendung? Bei Unit-Tests ist es einfach, da nehme ich die Code Coverage und bin glücklich. Funktional sieht das schon ganz anders aus. Was fehlt also? Genau: Testmanagement.
Wie sollte es also im Bestfall ablaufen? Wir entwickeln ein Produkt und dokumentieren sauber unsere Anforderungen (requirement engineering). Jetzt haben wir schon mal eine Basis, auf die wir aufsetzen können. Schreiben wir Tests, dann testet der immer ein Requirement (manchmal auch mehrere auf einmal). Dieses Mapping notieren wir uns auch. Eigentlich sind wir jetzt schon fertig (wir vereinfachen das jetzt alles mal). Nun wissen wir, welche Features mit Tests abgedeckt sind und welche nicht. Wir haben eine messbare Größe, die wir verwenden können.
Nicht nur, dass wir jetzt wissen, wann wir aufhören können mit testen, nein wir wissen sogar, welches Requirement nicht mehr tut, wenn ein spezieller Test fehlschlägt. Packen wir an unsere Anforderungen nun noch einen Business Value, dann kann man jetzt leichter entscheiden, ob der Bug nun sofort gefixt werden muss oder man die Beine noch ein wenig baumeln lassen kann.
Leider glaube ich, dass nicht viele von uns so ein gewichtetes Mapping ihr eigen nennen können. Da muss ich auch selbst auf die stumme Treppe, aber eigentlich wäre es doch toll. Ich weiß natürlich, dass es nicht so einfach ist, wie es klingt, denn Anforderungen ändern sich schneller, als man das will. Und auf dem Papier wird das meist auch nur sporadisch nachgezogen.
Aber eigentlich wollte ich ja wissen, wie ihr das handhabt? Gar nicht? Mit Excel? Professionelles Tool?
Das Tool, mit dem man seine Anforderungen verwaltet ist denke ich erst mal zweitrangig. Wichtig ist, dass alle Anforderungen an einer Stelle zu finden sind und nicht über Word-Dokumente, Mails und Ticketsysteme verstreut sind.
Idealerweise sind die Anforderungen natürlich vollständig, widerspruchsfrei und auf dem neusten Stand 😉
Aber das ist ja alles überhaupt nicht trivial. Ich glaube es muss je nach Größe des Projekts mindestens eine Person geben, die dafür verantwortlich ist, dass die Anforderungen an die Anforderungen eingehalten werden.
Wenn die Anforderungen „perfekt“ sind, dann ist die Verwaltung der Tests eher trivial. Schön wäre natürlich wenn aus den Anforderungen direkt Tests generiert werden könnten. Ich denke da zum Beispiel an Cucumber. In der PHP-Welt gibt es da mit Behat wohl auch etwas: http://everzet.com/Behat/
Jörg hat mit Tools für BOD ja schon den richtigen Einstieg geboten. Zumindest in agilen Prozessen kann man sich mit Tests sehr gut an der Formulierung der Anforderungen und deren Akzeptanzkriterien orientieren.
Aber um auf deine Kernfrage zu kommen: wann weiß man, ob man genug Tests geschrieben hat? Ich „glaube“, es gibt keine wirklich messbare Methode für funktionale Tests, wie etwa die Code-Coverage bei Unit-Tests. Zwar gibt es ja auch hier gewisse Anwendungspfade für ein Feature, aber bei Funktionalen Tests spielt Fuzzy-Testing ja noch eine andere Rolle, als bei Unit-Tests. Insofern lässt sich sicher keine 100%ige Abdeckung erreichen. Die Verantwortung kann man also, wie bei dir schon ein wenig angedeutet, vor allem auf die Anforderungen „schieben“. Die sollten die Anforderungen klar genug beschreiben, so dass hieraus Testfälle entwickelt und vorab geschrieben werden können. Man kann sich dann hier auch wieder total verrennen und alles testen wollen, was überhaupt keine Sinn mehr macht. Aber hat man gute Anforderungsbeschreibungen und klare Akzeptanzkriterien, hat man eine gute Mindestbasis, die durch funktionale Tests abgedeckt sein sollte.
BDD meinte ich natürlich -.-
Es gibt ja durchaus unterschiedliche Arten von Anforderungen.
Funktionale Anforderungen beschreiben den kompletten Funktionsumfang einer Software und dienen deshalb ja hervorragend als Dokumentation für funktionale Tests (man bemerke an dieser Stelle gewisse Ähnlichkeiten in den Wörtern ;-)). Und von daher kann man doch auch sehr gut entscheiden, ob die Testabdeckung vollständig ist oder nicht: Ist jede funktionale Anforderung von einem Test abgedeckt?
Nur fehlt einem meist dieses Mapping und genau das hat Nils ja beschrieben.
Die Ursachen dafür liegen wohl meist in ungenügenden Anforderungen.
Jörg hat ja schon geschrieben, dass eigentlich jemand die Anforderungen testen müsste und Verifikation und Validierung von Anforderungen machen müsste. Aber davon sind wir gerade in der Web-Entwicklung wohl noch ziemlich weit entfernt.
Aber auf die Frage von Nils würde ich Issue-Tracker in Spiel bringen.
Viele sammeln ihre Anforderungen dort und eigentlich kein schlechter Platz für so ein Mapping.
Ein anderer Ansatz statt BDD, könnte über die Sammlung der Features und den Akzeptanztest laufen ?
Hab mir mal diesen Link vor eine Weile vorgemerkt, aber noch keine Erfahrung in der Richtung gesammelt: http://fit.c2.com/
Basis ist wohl ein einfaches Excel oder Word, oder LibreOffice Calc mit den Anforderungen in einer Sprache die Kunden und Entwickler verstehen (nicht Gherkin). Da passiert dann das Mapping zu den Tests.
Das passende PHP-Projekt dazu ist laut Wikipedia
http://de.wikipedia.org/wiki/Framework_for_Integrated_Test
dies hier: http://developer.berlios.de/projects/phpfit/
Vielleicht melden sich die Beteiligten von phpfit ja noch hier…
Man will ja aber nicht nur den Sonnenschein-Fall einer Anforderung abtesten. Durch „negativ“-Tests wird die Robustheit der Anwendung sicher gestellt.
Wenn mein einen Issue-Tracker für das Anforderungsmanagement verwendet, muss man nur aufpassen, dass keine Threads in Romanlänge an den Tickets entstehen. Ansonsten wird es schwer, die Anforderungen, die in einem Ticket beschrieben sind, in akzeptabler Zeit zu erfassen.
Noch ein Ansatz: man nehme für die Sammlung eine Sprache, die Entwickler und Kunde gleich schlecht können ? Ein Wiki !
Scheint aber sehr beliebt zu sein, außerdem erstmal unabhängig von der Umgebung oder Programmiersprache:
http://www.fitnesse.org/FitNesse.UserGuide.OneMinuteDescription
(einen schönen Überblick liefert die Grafik am Ende der Seite)