Agile Testquadranten

Auch im agilen Projekt muss man jederzeit in den Sprints alle Qualitätsfaktoren im Blick haben. Doch welche Tests sollten wie durchgeführt werden? Welches Ziel verfolgen die Tests? Dazu geben die vier agilen Testquadranten Auskunft:

Agile Testquadranten nach Crispin/Gregory

Im ersten Quadrant befinden sich die Tests, die Team unterstützend wirken und technisch orientiert sind. Das Test Driven Development ist eine Voraussetzung für die vielen Regressionstests, die in der agilen Vorgehensweise notwendig sind.
Im zweiten Quadranten sind die Tests aufgeführt die das Team ausführt, damit sichergestellt wird, dass die Funktionen so umgesetzt wurden, wie diese geplant waren. Auch bei diesen Tests kommt die Testautomatisierung zum Einsatz, jedoch mit deutlich geringerem Umfang. Als Vorgehensweisen kommen oft Acceptance Test Driven Development (ATDD Link wikipedia) und Business Driven Development (BDD Link wikipedia) zum Einsatz.
In den dritten Quadranten fallen die Tests, welche die Geschäftstauglichkeit des Produktes hinterfragen. Es sind die Tests, die die Software sehr intensiv aus Sicht des Endbenutzers betrachten. Diese werden manuell durchgeführt.
Die Tests des vierten Quadranten sind spezielle Tests, die oft auch Experten mit speziellem Wissen für Tests (z. B. für die Security-Tests) oder für die Werkzeuge (z. B. Last- und Performancetests) benötigen. In großen Organisationen werden diese oft in Testcentern gebündelt, damit nicht jedes Team mit hohem Aufwand die Infrastruktur und Know-How aufbauen muss.

Magisches Quadrat der agilen Softwareentwicklung

Das magische Quadrat der Softwareentwicklung beschreibt die vier Einflussfaktoren. Das sind

• die Kosten (im Prinzip das verfügbare Personal für das Entwicklungsteam)
• die im Projekt vorgegebene Qualität
• der Termin zu der das Produkt oder Release fertig gestellt werden soll
• die Features, die im Produkt/Release umgesetzt werden sollen

Magisch, weil die Beeinflussung eines Faktors auch sofort auf die anderen Faktoren einwirkt. Es ist natürlich verständlich, dass ein Team in der gleichen Zeit nicht so viel entwickeln kann, wenn ein Mitarbeiter länger ausfällt. Oft tritt in der Praxis der Fall ein, dass ein Team mit der Entwicklung der Features im Rückstand ist. Statt diese Anzahl anzupassen, wird dann meistens bei der Qualität (Verringerung oder Entfall von Tests) eingespart.

Im agilen Ansatz gibt es im Prinzip nur noch eine Variable in den Einflussfaktoren. In einem geschützten Team (Personal stabil) werden bei gleich bleibender Qualität (durch Test Driven Development und festgelegten Definition of Dones) bis zu einem bestimmten Termin (festgelegt durch den Sprintzyklus) eine variable Menge an Features entwickelt. Fehlen zum Go live notwendige Features, müssen entsprechend weitere Sprints durchgeführt werden. Ist der Termin jedoch fix, ist nur die umgesetzte Anzahl an Anforderungen/Features variabel.

Was ist Software Qualität? Ein Beispiel

Was ist Software Qualität? Die Frage ist gar nicht so leicht zu beantworten. Denn unter Qualität versteht jeder Mensch etwas Anderes, denn jeder hat andere eine andere Sicht auf das Produkt und andere Anforderungen (oder gleiche mit unterschiedlichen Prioritäten) an ein Produkt.

Sicherlich stehen oft die funktionalen Qualitätsfaktoren im Vordergrund:
Was kann die Software? Rechnet sie richtig? Zeigt sie die Ergebnisse richtig an? Sind die Daten korrekt und sicher abgelegt? Dort wird viel Aufwand in die Qualitätssicherung investiert. Diese Punkte stehen immer im Fokus.

Aber wie sieht es mit den nichtfunktionalen Qualitätsfaktoren aus?
Einheitliche Benutzungsoberflächen. Einfache Bedienung. Effiziente Umsetzung der Arbeitsprozesse in die Software. Das sind z. B. Faktoren die unter die Usability fallen.

Und es gibt noch eine Menge andere Faktoren, wie die Wartbarkeit der Software, die Testautomatisierbarkeit, die Skalierbarkeit uvm. Man muss sich immer fragen, welche QS-Maßnahmen werden in diesen Gebieten durchgeführt? Wie wird die Qualität in diesen Themen konstruiert?

Aus Kundensicht spielt auch die Laufzeit eine wesentliche Rolle. Ein Faktor dabei ist sicherlich auch, wieviele Daten über das Netz übertragen werden. In LANs ist das wichtig, im mobilen Netz noch viel wichtiger. Werden viele Daten übertragen, können die Apps auf dem Smartphone langsamer werden. Das Risiko von Verbindungsabbrüchen steigt. Und die Flatrates der Kunden (oft bieten die Provider 200 oder 300 MB an) können ggf. für den Monat nicht ausreichen, was dann erhebliche Geschwindigkeitseinbußen zur Folge hat.

Seit Mitte 2014 hat Google die Smartphone-Apps auf ein einheitliches Design umgestellt und dies mit Android 5.0 konsequent fortgeführt. Es ist prima über alle Apps und das System eine einheitliche und einfache Bedienung zu erhalten. Doch der Datenverbrauch der Apps und Hintergrunddienste erhöhte sich mit den neuen Apps und Android 5.0 deutlich. Wenn Kunden bei gleichem Nutzungsverhalten neue Mobilfunkverträge abschließen, damit am 20. eines Monats nicht die Drosselung zuschlägt, wurden Qualitätsfaktoren bei der Entwicklung vernachlässigt. Auch wenn dann durch minor Releases nachgebessert wird, hat man für einen gewissen Zeitraum Qualitätseinbußen.

Nur wenn alle Aspekte berücksichtigt werden, liefert man ein Produkt mit "guter Qualität" aus...

Fehlermanagement in mehreren Entwicklungslinien

In der Regel hat man ja verschiedene Versionen (Releases) einer Software. Eine beim Kunden verfügbare Version und mindestens eine Variante für die Weiterentwicklung. Nun tritt in einer Komponente (unterschiedliche Versionen) ein Fehler auf. Wie organisiert man nun das Bug-Tracking und den Ausbau? Dazu gibt es zwei prinzipielle Ansätze:

1. Im Bug-Tracker wird für jeden Softwarestand ein Bug angelegt
2. Im Bug-Tracker hat man einen Bug, der für alle Versionen gilt.

Was bedeutet dies nun, wenn man für jede Version einen Bug im System hat (1):

• Für jede Version muss man einen Bug im System einstellen (Aufwand ist aber eher ein kleiner) und bearbeiten.
• Transparenz, wie weit die Umsetzung für die jeweilige Version ist. Das ist gut für das Team, da beim Ausfall eines Kollegen (z. B. Krankheit) sofort offensichtlich wird, was noch offen ist.
• Es wird offensichtlich, in welchen Versionen der Fehlerausbau zu testen ist (unabhängig ob dies automatisiert oder manuell geschieht).

Und wie sieht es beim Ansatz (2) aus:

• Haben die Entwickler ihre Aufgaben wirklich gut im Griff (keine Ablenkung durch neue Prioritäten, neue Probleme etc.) reicht nur ein Eintrag im Bug-Tracker. Bei kleinen Teams ist dies ggf. eine praktikable Vorgehensweise.
• Es ist allerdings zu klären für welche Version der Bug im System angelegt wird (das wird vor allem schwer, wenn verschiedene Releases beim Kunden verfügbar sind).
• Die Transparenz über den Fortschritt bei Fehlerausbau und Test in den verschiedenen Versionen hat man natürlich nicht. Und wenn der Entwickler mal krank wird, ist nicht so einfach erkennbar, was bereits erledigt wurde.

Gerade in größeren Teams und Organisationen und bei Verfügbarkeit von drei (Freigabe-Release, Pilot-Release, aktuelles Release in der Entwicklung) oder mehreren Releases tendiere ich wegen der Übersichtlichkeit zur Lösung (1). Auch weil jeder Bug gleichzeitig ein Requirement für ein Release ist und damit deutlich wird was alles für das Release zu tun ist. Aber letztendlich muss jeder für sich entscheiden, welche Vorgehensweise für die eigene Organisation besser geeignet ist.

Testing Zeitschriften im Web

In den letzten zwei Jahren hat sich bei den Zeitschriften zum Testen doch einiges getan. Vor allem gibt es recht neues deutsches Test Magazin. Nachfolgend ein Update zum Artikel von vor zwei Jahren. Kostenlos verfügbare Zeitschriften:

• Testing Experience Deutsch
  erscheint einmal im Quartal - http://www.testing-experience.de/
• Testing Experience Englisch
  sehr umfangreiche Zeitschrift, die zweimonatlich erscheint - http://www.testingexperience.com/
• Professional Tester
  sehr bekannte englischsprachige Zeitschrift, zweimonatlich - http://www.professionaltester.com/
• Tea-time with Testers
  monatliche Zeitschrift - http://www.teatimewithtesters.com/
• Testing Circusenglischsprachige Zeitschrift, die monatlich erscheint - http://www.testingcircus.com/
• Testmagazine - The European Software Testerzweimonatlich - http://www.testingmagazine.com/

Der Change von klassischen Vorgehensweisen zum Agilen

Warum ändert man die Vorgehensweise in der Softwareentwicklung? Warum wird man agil, wenn man vorher klassisch Software erstellt hat? Na klar. Man möchte die Qualität erhöhen. Bezüglich der Kundenanforderungen. Bezüglich der Stabilität. Und auch bei den weiteren Qualitätsfaktoren.
Doch die agilen Projekte liefern in der Regel keine besseren Ergebnisse als klassische Vorgehensweisen, wie die Umfrage Softwaretest ermittelt hat.

Doch was sind die Ursachen? Die Diskussionen mit Experten im letzten Seminar haben dabei folgende mögliche Gründe zu Tage gebracht:

• Alle Beteiligten benötigen einen Mindshift von klassisch zu agil. Teilweise geht nicht.
• "no test - no code"
  Wer den Code nicht richtig gut getestet hat, darf diesen nicht einchecken. Sonst läuft es niemals.
• "Agilität ohne Test Driven Development geht gar nicht" (Zitat Prof. Dr. Mario Winter)
• Ohne testgetriebene Ansätze (TDD, XP, Pairing etc.) sind agile Vorgehensweisen absolut fragwürdig. Das ist dann nur "Hacken".
• Ohne eine Definition of Done wird auch keine Qualität herauskommen
• Planning Poker ohne Berücksichtigung der Testing Tasks (oder der jeweiligen Testaufwände in den user stories) ist nur Selbstbetrug

Halbe Sachen gehen also gar nicht. Ein Change-Prozess braucht viele Coaches und eine Basis, die für Veränderung bereit ist. Sonst wird aus einem Wasserfall nur ein "agiler Wasserfall"...

Neue Sicht zum explorativen Testen

Das explorative Testen ist den letzten Jahren immer mehr ins Gespräch gekommen. Vor allem im agilen Umfeld hat man immer wieder vom Einsatz gehört. Was ich bisher darüber gehört hatte, hatte mich jedoch nicht überzeugt:
Wer keine systemtischen Testverfahren verwendet, wer keine Requirements definiert und wer keine richtige Vorgehensweise hat, der macht eben exploratives Testen. Unstrukturiert und chaotisch...
So habe ich bisher gedacht. Doch eine Veranstaltung mit Prof. Dr. Mario Winter (Link FH Köln) hat mir eine neue Perspektive gegeben (natürlich liegt an seinem Aufbau und Inhalten dieser Methode).

Exploratives Testen

• ist eine zielgerichtete Vorgehensweise um Fehler zu finden (Test-Chartas)
• ist eine strukurierte und kreative Methode (Testing-Touren und Session-basiert)
• ist für die Tester sehr motivierend
• dient als Ergänzung zu systematischen Testverfahren
• ist natürlich auch eine Methode, die man nutzen kann, wenn kaum (oder keine) Konzepte vorhanden sind 

Vor allem in agilen Projekten ist der Einsatz sehr spannend. Neben dem Seminar (extrem empfehlenswert) ist auch ein Buch von James Whittaker (Testing Evangelist) sehr zu empfehlen (Link zu Amazon) 

Später mehr zur Methodik...