Testing im agilen Prozess

In den agilen Prozessen ist oft nicht genau definiert, welche Tests wann durchzuführen sind (siehe auch älteren Blogbeitrag). Die Diskussion ist inzwischen weiter fortgeschritten, dennoch ist oft in den Projekten strittig, wann Systemtests und Integrationstests durchzuführen sind. Vor allem in großen Software-Projekten, mit vielen agilen Teams, oder Unternehmen mit vielen Programmen (und damit auch vielen Teams), die Abhängigkeiten untereinander besitzen, ist es wichtig zu definieren, wann welche Tests durchzuführen sind. Nachfolgend ein Vorschlag, wie Test und Entwicklung im agilen Projekt verzahnt werden können:

agile testing in large projects

Während des Sprints werden funktionale Tests durchgeführt. Zusätzlich finden auch nicht-funktionale Tests, z. B. zur Usability statt. In jedem Sprint wird das Inkrement getestet (Basis ist das Sprint-Backlog). Zu entscheiden ist auch, ob und welche Regressionstests ab dem 2. Sprint stattfinden.
Am Ende des Sprints werden Integrationstests (z. B. Schnittstellen zwischen Programmen) und Systemtests (Lasttest, Performancetests) für alle Softwareteile durchgeführt. Dazu werden alle Programme auf einem System aufgebracht, dass der Konfiguration wie beim Kunden entspricht.
Der letzte Sprint ist ein reiner Quality-Sprint. Es wird keine funktionale Weiterentwicklung durchgeführt. Diese ausführliche QS-Phase ist notwendig, um alle Programme noch einmal intensiv zu testen, wenn die Fehler aus dem Quality Gate des letzten Sprints beseitigt wurden.

Fehlermetriken

Fehlermetriken sollen im Software-Entwicklungsprozess helfen, den Testprozess und damit auch das Projekt effizient zu steuern. Es gibt viele, auch komplexe Metriken, die in der Praxis Verwendung finden.
Doch was ist für eine Metrik wirklich wichtig? Wann ist es sinnvoll darüber zu steuern?

Aus meiner Sicht sollte die Metrik folgendes wiederspiegeln:

• Die Entwicklung der Fehler über einen Zeitraum. Eine isolierte Betrachtung "Wie sieht es jetzt gerade aus?" bringt nichts, vor allem bezüglich der Schätzung wieviel Aufwand noch geleistet werden muss.
• In einem Prozess mit Weekly Build betrachte ich...
• wie viele Fehler sind in der letzten Woche dazugekommen
• wie viele Fehler wurden in der letzten Woche ausgebaut
• wie Fehler sind insgesamt noch offen
• Bei einem Daily Build Prozess kann man die Metrik auch auf eine tagesweise Betrachtung anpassen. Die wochenweise Betrachtung kann aber auch beibehalten werden (die ich auch bevorzuge).
• Durch die Betrachtung der Erledigung findet auch der Fehlerstatus Berücksichtigung. Es gilt im Projekt zu klären, ob man nur den Zustand offen/erledigt betrachtet, oder an dieser Stelle weiter verfeinert (z. B. Fehler gefixed, aber noch nicht getestet).
• Betrachtung der schweren Fehler. Bei einer Einteilung z. B. in die Klassen A-C sollten die leichten Fehler keine Berücksichtigung finden, da diese den Blick auf das Wesentliche verstellen. Also nimmt man die Kategorie A und B in die Metrik auf.

Folgendes Aussehen könnte die Metrik "Fehlerbehebung" haben:

Diese Metrik enthält alle Merkmale und ist recht übersichtlich. Auch für das Management bietet diese entsprechende Transparenz. 

Software-Qualität im PKW (Navigation)

Bei Fahrtbeginn höre ich, dass ab der Anschlussstelle Leipzig-Süd bis zur nächsten Anschlussstelle Richtung Süden ca. 8 km Stau sind. Im Vertrauen auf das eingeschaltete Navi im neuen Passat kümmere ich mich nicht weiter darum (na gut, ein zusätzlicher Blick auf die Verkehrlage bei Google Maps auf dem Smartphone ist ja erlaubt). Doch was macht das Navi. Leitet mich genau zur Auffahrt Leipzig-West statt südlicher und zeigt dann sofort diese 8 km Stau an. Was soll das denn? Dafür gibt es die Schulnote 6

Im weiteren Verlauf der Fahrt ein weiterer Fall. Ich befinde mich auf der A70. Im Radio höre ich, dass sich auf der A73 (nicht im Anschlussbereich der A70) ein Geisterfahrer befindet. Keine Minute später zeigt das Navi eine Gefahrenmeldung an. Geisterfahrer auf meiner Autobahn. Löst völlige Verunsicherung bei mir aus (natürlich auch eine Menge Stress). Keine Meldung im Radio zur A70. Kein Geisterfahrer auf meiner Strecke. Das Ganze löst sich in Luft auf. Schulnote 6

Meine Schlussfolgerungen:

Autohersteller sollten sich auf die Kernkompetenzen konzentrieren und die Navigation denen (Navigon, Google etc.) überlassen , die in diesem Feld die Kompetenz haben

Software-Qualität im PKW (Müdigkeitserkennung)

Kürzlich war ich auf Dienstreise mit einem neuen Passat (Leihwagen). Morgens früh nach etwa 30 min Fahrt schreckt mich eine Meldung auf: "Müdigkeit erkannt. Bitte Pause." Etwa eine Stunde später wieder die gleiche Meldung. Ich habe jedoch frisch und munter mein Ziel erreicht.

Auf der Rückfahrt, am nächsten Nachmittag, fühlte ich mich bei großer Hitze schon bei Fahrtantritt recht platt. Nach 90 min war ich so müde, dass ich eine längere Pause machte. Doch diesmal kam keine Meldung vom Fahrzeug.

Mit dieser Erfahrung komme ich zu folgenden Schlussfolgerungen:

• Die Software arbeitet unzuverlässig - würde ich dauerhaft abschalten
• Als Fahrer fühle ich mich sehr verunsichert
• Es ist dem Fahrer klar, wie die Software zu diesen Ergebnissen kommt (Gesichtsanalyse?)
• Was macht das Fahrzeug mit den Daten - werden diese dauerhaft gespeichert um Meldungen wegen bestimmter Verhaltensmuster anzuzeigen?
• Warum baut der Hersteller so etwas überhaupt ein - hält man die Fahrer nicht in der Lage, selbst zu entscheiden (eine ethische Frage)?

Aus meiner Sicht ist die Qualität leider unbefriedigend.

Ansichten zum Qualitätsverständnis

Im folgenden sehenswerten Video http://vimeo.com/41485653 (ca. 7 min) sprechen zwei Mitarbeiter von it-agile darüber, was Software-Qualität ist. So hat sich aus ihrer Sicht das Qualitätsverständnis in den letzten Jahren verändert:
Nicht die korrekte Umsetzung der am Projektanfang gesammelten Anforderungen (klassisches Wasserfallmodell), sondern die Zufriedenheit des Kunden entscheidet über die Qualität der Software. Dazu ist eine enge Zusammenarbeit mit Kunden und regelmäßiges Feedback notwendig (Kunde steht im Mittelpunkt).
Dem kann man auf jeden Fall zustimmen. Ebenfalls zustimmen kann ich der Ansicht, dass QS-Maßnahmen permanent im Entwicklungsprozess durchgeführt werden müssen. Qualität kann nicht am Ende hineingetestet werden. Ich kann auch zustimmen, dass jeder im Team für Qualität verantwortlich ist (Unit-Tests, Code-Review, ExtremeProgramming, Paartests etc.).
Aber keine Team-Mitglieder, die sich nur um das Testing kümmern? In großen Projekten keine Integrationstests am Ende (also ein reiner Q-Sprint)? Sämtliche QS-Aktivitäten nur durch Entwickler -die das Testen nicht lieben? Das kann nur in kleinen, stark abgegrenzten Projekten gelingen, oder?

Agile Methoden und Test - ASQF Vortrag

Zu einem interessanten Vortrag hatte die Gruppe Software-Test des ASQF eingeladen: Agile Methoden und Test. Der Referent berichtete von seinen Erfahrungen aus verschiedenen agilen Projekten und nahm dabei besonders die Rolle des Test-Managers und Testers in diesen Projekten unter die Lupe.
In agilen Projekten, vor allem von Scrum, kommen die QS-Rollen kaum vor (in der Literatur finden diese auch wenig Beachtung?!). Doch nicht die "Universalgenies" befinden sich in den agilen Teams, sondern "ganz normale Software-Entwickler". Damit müssen auch die Testing-Rollen im Team besetzt werden. Und diese Rollen haben in jedem Abschnitt eines Sprints ihre Aufgaben. Das beginnt mit der Startsitzung und endet mit der Freigabe der Software.
Einige Abschnitte im Scrum und die Aufgaben des Testings aus Referentensicht:

• Projekt-Start: Definition der Testumgebungen, Auswahl der Testwerkzeuge und- methoden
• ToDo zum Backlog: Definition von Akzeptanzkriterien, Review der User Stories, Priorisierung der Items auch nach Testanforderungen
• Planungsmeetings: Aufwandsschätzung für Testaufgaben,
• Eigentlicher Sprint: Hier fallen dann die Testaufgaben an, wie Testfallerstellung, Testdatenerstellung, Testdurchführung, Testautomatisierung, Regressionstests, etc.

Besonders wichtig ist in Augen des Referenten die Testautomatisierung, denn sonst werden die Regressionstests am Ende eines jeden Sprints zum Zeit-Killer.
Eine interessante Veranstaltung, die zum Nachdenken über die Praxis anregt...

Timeboxed Testing

Was steckt hinter dem Begriff Timeboxed Testing? Wie der Name sagt, handelt es sich um einen Test, der in einem begrenzten Zeitrahmen stattfindet.

Das wichtigste Ziel ist es, sich gemeinsam intensiv auf das Testen einer Software zu konzentrieren.

Timeboxed Testing

Die Teilnehmer werden je nach der durchzuführenden Variante gewählt. Möchte ich verschiedene Testergebnisse miteinander vergleichen, muss der Test nach vorgegebenen Szenarien stattfinden (und am besten mit Fachexperten). Freies Testen bietet sich an, wenn man den Service, Manager oder Personen aus anderen Entwicklungsteams einbeziehen möchte. Dann bekommt jeder Teilnehmer ein Testgebiet (Featuregruppe, Modul, Teilanwendung etc.) zugewiesen.  

Wann ist eine Softwarekomponente fertig?

Angeregt durch Kollegen, hier ein paar Gedanken zum Thema "Wann ist eine Softwarekomponente fertig?"
Fertig wird eine Software sicher nie (außer am Ende des Lifecycle - dann ist eben Schluss). Kaum ist ein Release geplant, kommen schon neue Anforderungen, die zum Teil dann auf ein späteres Release verschoben werden müssen. Aber wann ist dann ein Release fertig? Wann ist eine Funktion fertig? Wann ist ein Basiskomponente fertig?

Das nachfolgende Schaubild enthält die sechs Schritte, die eine Komponente durchläuft, bevor sie fertig ist. Das kleine Modell (aus der Praxis entstanden) ist nicht als Vorgehensmodell (wie z. B. Wasserfall) zu verstehen, sondern im Sinne des Projektmanagements. Damit kann dies auf jede Aktivität angewendet werden.

six steps to completion 

Wann ist also eine Komponente fertig?
Sicher nicht, wenn der Programmierer den ersten, aus seiner Sicht fertigen, Stand des Codes übergibt (vielleicht 40%). Sicher nicht, wenn die QS ein paar Smoke-Tests durchgeführt hat und befindet "Das sieht ganz gut aus" (ca. 55%). Und sicher auch nicht, wenn irgendjemand sagt: "Jetzt ist es fertig", weil ein bestimmter Termin erreicht ist (x% fertig).
Da die Softwareentwicklung ja kein linearer Prozess ist, muss auf geänderte Anforderungen reagiert werden. Müssen Fehler nachgebessert werden (deshalb der Schritt Fertigstellung). Integrationsmaßnahmen durchgeführt werden (u. a. der Schritt Freigabe). Und und ...

Die kleine Methode six steps to completion, aus dem Baukasten Six Sigma für Software, bietet damit einen Rahmen für die notwendigen Schritte. Der Aufwand je Schritt kann in der Praxis natürlich variieren. Die Schritte haben im ein oder anderen Projekt vielleicht andere Bezeichnungen. Aber die Aufwände bleiben...

Und wann ist das Release dann nun fertig? Wenn alle geplanten Anforderungen umgesetzt wurden, und nach den QS-Maßnahmen festgestellt wird, das sie allen funktionalen und nicht funktionalen Vorgaben entsprechen. Wenn die Qualität wirklich passt. Dann ist es fertig. Oder?

Das Richtige testen

In letzter Zeit muss ich immer wieder über einen Vortrag zum explorativen Testen (Erklärung des Testansatzes) nachdenken. Schnell entwickelte sich zwischen den Teilnehmern die Diskussion, ob man nur explorativ Testen darf. Ob dies überhaupt eine anerkannte Methode sei. Oder ob diese Vorgehensweise nur als zusätzliches Verfahren zu standardisierten Testmethoden eingesetzt werden sollte.
Doch die Referentin argumentierte schlagfertig: "Was nützen mir 5000 sorgfältig verwaltete und durchgeführte - vielleicht sogar teilweise automatisierte - Testfälle, wenn ich im entscheidenden Moment nicht den richtigen Testfall durchführe? Das vermittelt nur scheinbare Sicherheit."
Deshalb: Egal welche Testmethoden man anwendet. Egal wie gut man die QS-Maßnahmen organisiert. Egal ob die Vorgehensweise hemdsärmelig oder wissenschaftlich ist, man muss das Richtige zum richtigen Zeitpunkt testen...