ASQF Testing-Day: Agiles Testen vs. ISO 29119

Einen sehr unterhaltsamen und informativen Vortrag hielten zwei Referenten der imbus AG zum Thema Agiles Testen vs. ISO 29119. Beide Referenten polarisierten geschickt mit der Zuspitzung der beiden Positionen

• Agiles Testen ist doch: "jeder macht was er und wann er will" und "da wird ja gar nichts geplant"
• ISO Norm ist doch: "da ist alles starr und fix vorgegeben" und "das lässt mir keine Freiheitsgrade"

Und eigentlich liegen beide Themen gar nicht so weit auseinander. Denn für beide Vorgehensweisen, egal ob agil oder stark an der Norm orientiert, gilt aus Sicht der Referenten:

• Nutze das aus der Norm, was interessant für das aktuelle Projekt ist (was bietet einen Mehrwert für das Projekt) - damit bietet auch die Norm Flexibilität
• Nutze eine Norm (oder Teile der Norm) als Vorlage für Verbesserungen oder auch als Vorlage für test cases
• kläre wieviel Dokumentation benötigt wird ("just enough documentation")
• wie sieht ein Testreport am Ende eines Sprints oder Meilensteines aus? wieviel muss er enthalten? kann die Norm hier Hilfestellung geben.

Nicht nur der Vortrag war kurzweilig. Auch beim Get Together waren die Referenten interessante Gesprächspartner.

ASQF Testing-Day: Test meets Security

Einen spannenden Vortrag gab es auf dem ASQF Testing Day in Erlangen. Dieser beschäftigte sich mit dem Thema des Security-Testing. Aus meiner Sicht stellte der Referent folgende Eckpfeiler dar:

• Die zunehmende Vernetzung (Fahrzeuge, Industrie 4.0, etc.) rückt die Security-Tests stärker in den Focus
• Derzeit nimmt der Referent zur IT-Sicherheit einen deutlichen Paradigmenwechsel wahr (Security wird immer wichtiger)
• Die Tests sollten sich nicht nur auf die Applikationen beziehen sondern auch die IT-Infrastruktur berücksichtigen
• Wesentlicher Bestandteil des Testens sind unit-Tests
• Schwachstellen in Applikationen setzen sich aus zwei Kategorien zusammen:
• Entwurfsfehler
• Programmierfehler
• Zur Prüfung auf Programmierfehler sollten automatisierte Fuzzing-Tests durchgeführt werden
• diese sind mit unit-Tests zu automatisieren
• so kann eine hohe Variation in den Tests erreicht werden
• dieses können zur Regression immer wieder ausgeführt werden
• Modellbasiertes Testen ist für diese Tests sehr gut geeignet und sollte in Betracht gezogen werden

Letztendlich zeigte der Vortrag, dass man bei der Entwicklung das Thema Eingaben und Dateneingabeformate immer intensiv beim Test berücksichtigen muss.

Testing, Checking oder einfach nur testen?

Der Testexperte Gojko Adzic (Link zu seinem Blog) hat in einem seiner Artikel eine interessante These aufgenommen. Die besagt, dass das Testen eigentlich aus zwei unterschiedlichen Disziplinen oder Arten besteht:

1. Das Überprüfen erwarteter Ergebnisse. In Testfällen wird beschrieben, wie sich eine Anwendung verhalten soll. Dies wird dann überprüft. Diese Disziplin wird als checking bezeichnet. Gängige Tests sind dafür Unit-Tests, Tests von Datenformaten, Datenmigrationen, Schnittstellen etc.
2. Die Analyse der Anwendung auf das Verhalten bei Nutzung. Damit wird getestet, ob sich eine Anwendung unerwartet verhält. Ob Undefiniertes und Unbekanntes auftritt. Diese Disziplin wird als testing bezeichnet. Darunter fällt z. B. usability testing und exploratives Testen.

Eine spannende Unterscheidung. Denn die Tests, die unter checking fallen, bieten sich auch stark für Automatisierung an und sind in der Regel vom Entwickler (z. B. im Pairprogramming) umzusetzen. Das testing wird dann von erfahrenen Testern manuell durchgeführt.

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 Softwaerentwicklung

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...