Mit dem QA Navigation Board haben die agilen Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann das QA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden. » QA Navigation Board
Das QA Navigation Board wird innerhalb eines Workshops entwickelt, welcher von einem agilen QA-Coach durchgeführt wird. Der Workshop sollte nicht langer als 1,5 Stunden dauern.
Vorbereitung
Es sollten alle Beteiligten des agilen Projektes eingeladen werden:
Entwicklerteam (Entwickler, Tester)
Scrum Master
Product Owner
weitere Stake- und Shareholder
Das QA Navigation Board wird an einer (Pinn-) Wand befestigt. Zusätzlich wird der QA-Oktant als Arbeitsblatt für jeden Teilnehmer ausgedruckt.
Schritt 1:
Vorstellung des QA Navigation Board und der Ziele des Workshops durch den Moderator (agiler QA-Coach) sowie Vorstellung der Beteiligten.
Schritt 2:
Kurze Vorstellung des QA-Oktanten und der Qualitätskriterien. Ziel ist es, dass alle Beteiligten das Arbeitsblatt ausfüllen können und alle die Qualitätskriterien verstanden haben bzw. nicht anschließend aneinander vorbeireden.
Des Weiteren stimmen sich die Teilnehmer über die Dimensionen des QA-Oktanten ab: Wie sollen die Abstände des Diagrammes bewertet werden (1, 2, 3 oder S, M, L, XL etc.)? Danach werden die Arbeitsblätter ausgeteilt und innerhalb von 5 bis 10 min von jedem Beteiligten alleine ausgefüllt und mit seinem Namen versehen (siehe Blogbeitrag: Wie verwende ich den QA-Oktanten).
Schritt 3:
Nach Ablauf der Zeit sammelt der Moderator die Arbeitsblätter wieder ein und platziert sie auf einer (Pinn-) Wand.
Die Aufgabe des Moderators ist es nun, die einzelnen Qualitätskriterien durchzugehen. Dazu identifiziert er pro Kriterium den gemeinsamen Nenner (Durchschnitt) und bespricht die größten Abweichungen mit den dazugehörigen Personen (siehe Planning poker). Wurde im Team ein Konsens über den Wert des Kriteriums erzielt, wird dieser Wert vom Moderator dokumentiert.
Schritt 4:
Auf Basis der Wertung der Qualitätskriterien leiten nun die Beteiligten die notwendigen Testarten ab. Je wichtiger ein Qualitätskriterium bewertet wurde, desto wahrscheinlicher muss es durch ein passendes Testvorgehen geprüft werden. Die identifizerten Testarten werden vom Team in der Testpyramide des QA Navigation Board platziert.
Schritt 5:
Sind alle Testarten identifiziert und platziert, können die notwendigen Testressourcen und anderen Testartefakte auf dem QA Navigation Board platziert werden. Hier kann eine Checkliste helfen (siehe Blogbeitrag: Die QA-Karte oder „Wie fülle ich das QA Navigation Board…“).
Schritt 6:
Hat das Team das QA Navigation Board weitestgehend ausgefüllt, wird es an einem passenden Platz im Teamraum aufgehängt. Der Moderator schließt den Workshop ab und verweist darauf, dass das QA Navigation Board vom Team weiterentwickelt und auch in den Retrospektiven genutzt werden kann.
Mit dem QA Navigation Board haben die Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann das QA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden. Aber wie lassen sich die Testarten und anderen Testartefakte auf dem QA Navigation Board platzieren?
Um die Frage „Wie und wo wollen wir testen?“ zu beantworten, müsste das Team den gesamten Entwicklungsprozess nach Test- und QA-Aspekten durchforsten und diese dokumentieren. Je nach Projekt kann der Entwicklungsprozess unterschiedlich ausgeprägt sein und damit die Fragestellung schnell recht komplex werden lassen.
Abbildung 1: Entwicklungs- und QA-Prozess
Um auch hier den Teams einen mühelosen Einstieg in das Thema zu geben, haben wir die QA-Karte entwickelt. Die QA-Karte bietet dem Team eine praktische Möglichkeit, die Maßnahmen für eine optimale Testbarkeit der Projekte zu planen und zu dokumentieren. Ziel ist es, bereits zu einem frühen Zeitpunkt alle QA-relevanten Fragen für die Teams und Entwicklungsprojekte durch einen spielerischen Ansatz zu ermitteln.
Abbildung 2: Die QA-Karte
Nach der Definition der Testschwerpunkte durch die Nutzung des QA-Oktanten und der Bestimmung der notwendigen Testarten können alle Aspekte der Teststrategie wie Testarten, Ressourcen und Werkzeuge visualisiert, diskutiert und priorisiert werden.
Als Good-Practice der durchgeführten Workshops kristallisierte sich heraus, dass es hilfreich ist, bei der Steuerung der Befüllung der QA-Karte zwei Hilfsmittel zu nutzen. Zum einen einen guten Moderator, der den Workshop in die richtige Richtung leitet und zum anderen die Nutzung einer Checkliste. Die Checkliste beinhaltet passende Fragen, die im Workshop als Anregung dienen sollen, um die verschiedenen Teile der QA-Karte zu befüllen. Diese Fragen sind nachfolgend aufgelistet und dem jeweilig zu befüllenden Feld zugeordnet.
Requirements
Wo liegen die Anforderungen?
Unterstützen die Anforderungen die Testfallerstellung?
Lassen sich Anforderungen und Tests verknüpfen?
Test / Code
Wo werden die Tests platziert?
Haben wir die nötigen Skills?
Repository
Wo werden die Testartefakte gespeichert?
Gibt es unterschiedliche Artefakte?
Test Management
Wie planen wir unsere Tests?
Wie dokumentieren wir unsere Tests?
Wie informieren wir? Und wen?
Automation
Wieviel Testautomatisierung ist nötig?
Benötigen wir weitere Werkzeuge?
Benötigen wir Testdaten?
Build
Wie oft wollen wir bauen und testen?
Wie wollen wir die QA integrieren?
Wollen wir Wartbarkeit prüfen?
Test Environments
Haben wir für jeden Test die passende Umgebung?
Kommen wir uns in die Quere?
Abbildung 3: Beispiel 1 eines ausgefüllten QA Navigation BoardsAbbildung 4: Beispiel 2 eines ausgefüllten QA Navigation Boards
Sobald alle Testarten ausgewählt wurden und das Team begonnen hat, die anderen Testartefakte (z.B. Werkzeuge, Umgebungen) zu platzieren, kann sich der Moderator zurückziehen. Das finale Wandbild sollte vom Team plakativ im Teamraum angebracht werden. So dient das QA Navigation Board als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung.
In meinem Blogartikel „QA Navigation Board – Wie, wir müssen das noch testen?“ habe ich das QA Navigation Board vorgestellt. Nun möchte ich unsere Erfahrungen teilen, wie sich der darin enthaltene QA-Oktant bei der Suche nach den notwendigen Testarten nutzen lässt.
Eine der Fragen zu Beginn eines Softwareprojektes ist, auf welchen Qualitätskriterien der Fokus der Entwicklung und damit auch der Qualitätssicherung liegt. Um den Teams einen einfachen Einstieg in das Thema zu geben, nutzen wir den QA-Oktant. Folgend der ISO 25010 beinhaltet der QA-Oktant die Qualitätskriterien für Softwaresysteme. Sie geben aber auch einen Hinweis auf die notwendigen Testarten, welche sich aus der gesetzten Gewichtung der unterschiedlichen funktionalen und nichtfunktionalen Kriterien ergeben.
Je nachdem wie stark die umgesetzten Anforderungen auf die Qualitätskriterien einzahlen, ergibt sich die Notwendigkeit, diese Qualitätskriterien mit einer entsprechenden Testart zu prüfen. So benötigen Apps mit hohem Datendurchsatz Effizienztests und Webshops Prüfungen zur Kompatibilität in verschiedenen Browsern. Durch die einfache Visualisierung und Gewichtung der unterschiedlichen Qualitätskriterien kann der QA-Oktant für die Planung genutzt werden.
Das Team stellt dem Product Owner oder dem Fachbereich die Frage „Wie wichtig sind die einzelnen Qualitätskriterien?“. Ziel der Fragerunde ist es, eine Abstufung in der Gewichtung der verschiedenen Kriterien erkennbar zu machen. Dabei werden die meisten Befragten keine große Abstufung zwischen den Qualitätskriterien machen oder besser gesagt wird die Antwort lauten: „Alles ist wichtig!“.
Das Team bzw. der Moderator des Meetings haben nun die Aufgabe, die Fragestellung dahin zu konkretisieren, dass eine Differenzierung erfolgen kann. Dazu können verschiedene Fragetechniken zum Einsatz kommen.
Es kann eine Differenzierung nach Abgrenzung über das Einsatzgebiet erfolgen. Erfolgt der Einsatz einer fachlichen Anwendung auf HTML-Basis in einem Firmennetz und gibt es laut IT-Compliance nur einen Browser und nur eine Betriebssystemversion, dann können der Aspekt Kompatibilität und die damit verbundenen Tests niedriger eingestuft werden. Gibt es dagegen eine hohe Anzahl an Kombinationen von Plattformen, müssen umfangreiche Tests eingeplant werden.
Für weitere Differenzierung kann zum Beispiel eine Negativfragetechnik eingesetzt werden: „Was passiert, wenn z. B. die Benutzbarkeit herabgesetzt wird?“. Für eine Anwendung zur monatlichen Rechnungsstellung wird angenommen, dass die negative Auswirkung der Benutzbarkeit die Geschwindigkeit der Erstellung einer Rechnung von zwei auf vier Stunden erhöht. Da die Anwendung nur einmal im Monat benutzt wird, wäre diese „Verzögerung“ vertretbar und die Benutzbarkeit kann im QA-Oktanten niedriger eingestuft werden.
Diese Fragetechnik kann durch Priorisierung durch Risikoabschätzung erweitert werden: „Was passiert bzw. welche Auswirkungen ergeben sich, wenn z. B. das Kriterium Sicherheit verringert wird?“. Die Antworten ergeben sich hier aus folgenden Aspekten:
Welche monetäre Auswirkung hätte ein Ausfall der Anwendung, wenn der Fokus auf das Kriterium verringert wird?
Wie viele Anwender wären betroffen bei dem Ausfall der Anwendung, wenn der Fokus auf das Kriterium verringert wird?
Wäre Leib und Leben gefährdet bei dem Ausfall der Anwendung, wenn der Fokus auf das Kriterium verringert wird?
Würde die Firma Reputation verlieren beim Ausfall der Anwendung, wenn der Fokus auf das Kriterium verringert wird?
Liegen Ergebnisse und Erkenntnisse bei einem oder mehreren Qualitätskriterien vor, kann man diese mit den offenen Qualitätskriterien vergleichen und wie beim Komplexitätsvergleich im Planning oder der Estimation agieren.
Mit der richtigen Fragestellung ergibt sich eine Übersicht über die Qualitätskriterien. Durch die einfache Visualisierung und Gewichtung der unterschiedlichen Qualitätskriterien kann der QA-Oktant für die Planung der Testarten genutzt werden.
Dabei ist nicht immer nur das Ergebnis der wichtigste Aspekt des QA-Oktanten, sondern auch „der Weg ist das Ziel“. Durch die Gewichtung im Team und gemeinsam mit dem PO und/oder dem Fachbereich können unterschiedliche Meinungen besser wahrgenommen werden und ein besseres Verständnis aller Beteiligten entsteht.
Meist stehen bei Entwicklungsprojekten die Überlegungen zur Funktionalität und der Mehrwert für den Kunden im Vordergrund. QA und Testbarkeit kommen dadurch bei der Planung zu kurz. So treten während der Testphase Hürden für das Team auf, welche sich durch eine gewisse Voraussicht bei der Planung der QA-Aufgaben umgehen lassen. Tester haben für die Planung der höheren Teststufen bereits ein geeignetes Vorgehen: ein detailliertes Testkonzept, welches die Testziele dokumentiert sowie entsprechende Maßnahmen und eine Zeitplanung festlegt (Abb. 1).
Abbildung 1: Aspekte der Teststrategie / Inhalte eines Testkonzepts
Diese Detailtiefe eignet sich aber nicht für agile Projekte und Entwicklungsteams. Trotzdem sollte sich das Team vor dem Start eines Projektes über die meisten Aspekte, die im Testkonzept genannt werden, Gedanken machen. Darum haben wir ein Hilfsmittel entwickelt, welches es den Teams ermöglicht, alle Maßnahmen für eine optimale Testbarkeit in Softwareprojekten mit einzubeziehen. Das Hilfsmittel berücksichtigt sowohl die Fragen „Was ist zu testen?“ als auch „Wie und wo wollen wir testen?“.
Um die erste Frage „Was ist zu testen?“ im Hinblick auf Softwareprodukte zu beantworten, ist die Ausprägung der Qualitätskriterien der umzusetzenden Anforderungen ausschlaggebend. Die unterschiedlichen Qualitätskriterien sind in der ISO 25010 „Qualitätskriterien und Bewertung von System und Softwareprodukten (SQuaRE)“ enthalten (Abb. 2).
Abbildung 2: Qualitätskriterien nach ISO 25010
Je nachdem wie stark die umgesetzten Anforderungen auf die Qualitätskriterien einzahlen, ergibt sich die Notwendigkeit, diese Qualitätskriterien mit einer entsprechenden Testart zu prüfen. So verlangen Apps mit hohem Datendurchsatz nach Effizienztests und Webshops sollten auf Kompatibilität in verschiedenen Browsern geprüft werden.
Um den Teams den Einstieg in das Thema zu erleichtern, nutzen wir den QA-Oktant. Folgend der ISO 25010 beinhaltet der QA-Oktant die Qualitätskriterien für Softwaresysteme. Sie geben aber auch einen Hinweis auf die notwendigen Testarten, welche sich aus der gesetzten Gewichtung der unterschiedlichen funktionalen und nichtfunktionalen Kriterien ergeben (Abb. 3).
Abbildung 3: Der QA-Oktant mit gewichteten Qualitätskriterien
Durch die einfache Visualisierung und Gewichtung der unterschiedlichen Qualitätskriterien kann der QA-Oktant für die Planung genutzt werden. Product Owner können damit die Übersicht über relevante Anforderungen behalten und das Team kann gemeinsam mit dem Product Owner die Anforderungen anhand der Qualitätskriterien einordnen. Durch die Gewichtung im Team können unterschiedliche Meinungen besser wahrgenommen und eine gemeinsame Einordnung anschaulich dokumentiert werden. Aus dem Ergebnis lassen sich die notwendigen Testarten ableiten.
Um die zweite Frage „Wie und wo wollen wir testen?“ zu beantworten, müsste das Team den gesamten Entwicklungsprozess nach Test- und QA-Aspekten durchforsten und diese dokumentieren. Je nach Projekt kann der Entwicklungsprozess unterschiedlich ausgeprägt sein und damit die Fragestellung schnell recht komplex werden lassen (Abb. 4).
Abbildung 4: Entwicklungs- und QA-Prozess
Um auch hier den Teams einen mühelosen Einstieg in das Thema zu geben, haben wir die QA-Karte entwickelt. Die QA-Karte bietet dem Team eine praktische Möglichkeit, die Maßnahmen für eine optimale Testbarkeit der Projekte zu planen und zu dokumentieren. Ziel ist es, bereits zu einem frühen Zeitpunkt alle QA-relevanten Fragen für die Teams und Entwicklungsprojekte durch einen spielerischen Ansatz zu ermitteln. In Planungsrunden können gemeinsam alle Aspekte der Teststrategie wie Testarten und Werkzeuge visualisiert, diskutiert und priorisiert werden. Neben der Planung dient die QA-Karte mit ihrer plakativen Darstellung auch als Erinnerung oder schneller Einstieg in die Teststrategie des Teams.
Zusammengesetzt ergeben der Oktant und die Karte das QA Navigation Board, welches sich als Wandbild platzieren lässt (Abb. 5).
Abbildung 5: Das QA Navigation Board (mit Oktant und Karte) als Wandbild
Mit dem QA Navigation Board haben die Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann das QA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden.
Digitalisierung und Industrie 4.0 stellen neue Anforderungen an Prozesse und Softwaresysteme in allen Unternehmens- und Geschäftsbereichen. Firmen, die ihre Software extern entwickeln oder einkaufen, haben eine zusätzliche Herausforderung. Die verschiedenen Systeme unterschiedlicher Hersteller müssen für die vernetzte Arbeit im Geschäftsprozess der Unternehmen noch stärker untereinander Daten austauschen. Trotz der Tests der internen und externen Entwicklungsteams, die in verschiedenen entwicklungsnahen Teststufen die Software, bevor Sie an den Kunden übergeben wird, validieren und der anschließenden Abnahme durch die Fachbereichstests, treten beim Zusammenspiel der einzelnen Komponenten Fehler auf. Als Lösung bietet sich hier ein Testcenter mit dem Fokus auf übergreifende Integrationstests an, das aber für seinen Erfolg besondere Anforderungen erfüllen muss.
Kritische Fehler, die erst im Rahmen des Live-Betriebes öffentlich werden, stellen nicht zuletzt eine negative Werbung für ein Produkt und die beteiligten Unternehmen dar. Um dies zu verhindern, ist das Thema „Test“ in der modernen Softwareentwicklung ein grundlegender und integraler Bestandteil. Nur durch eine ausreichende Anzahl an Tests und der zeitnahen Rückmeldung von Ergebnissen lässt sich die Qualität und Reife des Produktes ausreichend genau nachweisen und bestätigen. Im Verlauf großer Softwareentwicklungsprojekte werden oft mehrere hundert neue Funktionen erstellt bzw. existierende erweitert. Entwicklungsteams testen durch Komponenten-, Integrations- und Systemtests die Software, bevor sie an den Kunden übergeben wird. Der Fachbereich nimmt die übergebene Software durch den Abnahmetest ab (siehe Abbildung 1: Testpyramide).
Abbildung 1: Testpyramide
Es gibt in Unternehmen mehrere Informationssysteme mit verschiedenen Aufgaben für Logistik, Buchhaltung, Vertrieb etc., die mit unterschiedlichsten Technologien erstellt wurden. Diese Informationssysteme tauschen bereits heute untereinander Daten aus. Durch die Vorgaben der Digitalisierung und Industrie 4.0 verstärken sich diese Effekte: Neue Anforderungen wie stärkere Vernetzung innerhalb der gesamten Wertschöpfungskette führen zu einer höheren Anzahl oder einer Erweiterung der existierenden Schnittstellen der Informationssysteme untereinander. Damit steigt die Komplexität des Gesamtsystems, aber auch die Komplexität im Softwarelebenszyklus: Abhängigkeiten müssen von dem Erfassen der Anforderungen bis hin zum Test berücksichtigt werden.
Abbildung 2: Herausforderungen für den Test mit Digitalisierung und Industrie 4.0
Besonders für Firmen, die ihre Software von unterschiedlichen Dienstleistern erstellen lassen, erhöht sich der Aufwand für die integrativen Tests enorm. In den meisten Konstellationen gibt es mehrere externe Softwarehersteller und/oder gegebenenfalls eine interne IT-Organisation, die die Softwaresysteme entwickeln. Die Dienstleister führen bereits mehr oder weniger intensive Komponenten-, Integrations- und Systemtests durch und prüfen für das von ihnen erstellte Informationssystem im Einzelnen, ob die Qualität vorhanden ist. Den Fachbereichen fällt nun die Aufgabe zu, die vernetzten Informationssysteme in ihrem Zusammenspiel zu testen (siehe Abbildung 2: Herausforderungen für den Test mit Digitalisierung und Industrie 4.0).
Die größten Probleme bzw. Fehler mit einem hohen Risiko entstehen aber im Zusammenspiel der Informationssysteme untereinander. Doch speziell die notwendigen übergreifenden integrativen Tests finden in den meisten Unternehmen nicht oder nur unzureichend statt, was zu einer unzureichenden Qualitätsaussage und zu Fehlern im Wirkbetrieb führt. Dafür gibt es verschiedene Ursachen. Ein übergreifender Test auf Entwicklungsebene wird durch die organisatorische und räumliche Trennung der beteiligten Dienstleister verhindert und die Ausführung der notwendigen Tests pro Release ist aus Zeit- und Ressourcengründen durch die Fachanwender oder Tester aus dem Fachbereich nicht möglich. Außerdem fehlt diesen mit den Tests beauftragten Mitarbeitern, die Erfahrung und das nötige Testwissen, um eine optimale Testplanung und Anforderungsabdeckung für Integrationstests umsetzen zu können. Zusätzlich werden durch die räumliche Distanz der verantwortlichen Tester in den verschiedenen Fachbereichen Absprachen und Wissensaufbau erschwert.
Für den Unternehmenserfolg wird es daher immer wichtiger, die notwendigen Tests an dedizierte Tester abzugeben und damit sowohl den in der Testdurchführung erreichten Abdeckungsgrad als auch die Häufigkeit der Testausführung (Regression) deutlich zu steigern. Als Lösung bietet sich hier ein Testcenter an, das den übergreifenden Integrationstest betreut, welcher zwischen den Tests der Dienstleister und dem Abnahmetest des Fachbereiches stattfindet (siehe Abbildung 3: Übergreifender Integrationstest durch ein Testcenter). Das Testcenter prüft dabei das korrekte Zusammenspiel der Informationssysteme und der Fachbereich konzentriert sich abschließend auf die Freigabe seiner gestellten Anforderungen.
Abbildung 3: Übergreifender Integrationstest durch ein TestCenter
Ein Testteam oder Testcenter aus dedizierten und ausgebildeten Testern bietet dabei verschiedene Vorteile:
die Qualität der Informationssysteme ist das Hauptziel des dedizierten Testteams
die Testergebnisse werden gesammelt und objektiv an die Beteiligten kommuniziert
es gibt einen Testmanager, dessen Fokus auf Qualitätsthemen liegt und der für das Management der Testgruppe zuständig ist
der Testmanager stimmt sich mit den Fach- und Entwicklungsabteilungen ab, ermittelt die zu testenden Anforderungen, koordiniert das Testteam, bindet die Tester aus den Fachbereichen ein, kommuniziert mit der Projektleitung und dokumentiert die Ergebnisse in Testberichten
Ein internes Testteam oder Testcenter hat aber auch Nachteile: Bei längeren Releasezyklen oder Verschiebungen in der Bereitstellung der zu testenden Software kommt es zu schwankender Auslastung. Das interne Testteam oder Testcenter erzeugt kontinuierliche Kosten, hat aber nicht immer ausreichend Aufgaben. Aber es kann auch zu Spitzen an Testaufgaben kommen, die nicht oder nur schwer von der bestehenden Mannschaft abgefangen werden können.
Unternehmen, die bereits bei der Erstellung ihrer Software auf Dienstleister zurückgreifen, können auch beim Einsatz eines Testcenters auf einen externen Dienstleister setzen, welcher den Integrationstest als (einen) Service anbietet. Das Testcenter stellt dabei nicht nur eine einfache Ausgliederung der Testaufgaben dar. Ein Testcenter basierend auf einer Testservicevereinbarung stellt eine Lösung dar, deren Aufgaben, Pflichten und Abrechnungsmodell individuell auf den Kunden abgestimmt wurden.
Das externe Testteam oder Testcenter besitzt eine maximale Unabhängigkeit von der Softwareentwicklung, ist hoch spezialisiert und lässt sich durch den Servicegedanken flexibel an den Testaufwand des Kunden anpassen. Damit lassen sich die angesprochenen Nachteile eines internen Testteams oder Testcenters auflösen und das Unternehmen kann sich auf seine Prozesse konzentrieren.
Damit ein Testcenter optimal auf die Wünsche des Kunden reagieren kann, müssen verschiedene Voraussetzungen erfüllt sein. Es darf keine zusätzlich abgesetzte Organisationseinheit darstellen, sondern muss offene Kommunikations- und Informationskanäle zu allen Beteiligten aufbauen. Dabei ist die Nähe zum Kunden besonders wichtig. Aus unserer Erfahrung bietet es sich an, das Testteam beim Kunden oder max. 5 bis 10 Minuten Fußweg entfernt zu platzieren. Damit wird der Wissenstransfer und die gezielte Abstimmung mit den Fachbereichen sichergestellt.
Die Abstimmung mit dem Kunden bzw. mit dem Fachbereich erfolgt über die Servicemanager und Testmanager. Der Servicemanager stimmt mit dem Kunden die Planung der Testservices ab. Dazu gehört die Definition der Inhalte der Testservices und Aufgaben des Testcenters. Da jeder Kunde andere Anforderungen und Prozesse besitzt, ist auch für jeden Kunden eine Abstimmung und Durchführung einer individuellen Transition zur Übernahme der Testaufgaben notwendig. War die Transition und damit die Übernahme der Testaufgaben erfolgreich, stimmt sich der Testmanager für jedes Testrelease mit dem Fachbereich bzw. der Testkoordination beim Kunden über den Testzeitraum, die operativen Testinhalte und die Testfälle ab. Die Kommunikation ist aber nicht nur auf diese beiden Rollen beschränkt. Die Testexperten im Testcenter und der Fachbereich benötigen für die optimale Neuerstellung, Anpassung und Review der Testfälle sowie die Abstimmung beim Aufdecken von Abweichungen direkten und intensiven Kontakt.
Das Ergebnis der Tests ist maßgeblich von dem Wissen der Tester abhängig und dieses muss mindestens drei Aspekte beinhalten: Zum einen das fachliche Know-how der zu testenden Applikationen und zum anderen ein umfangreiches Wissen zur Testmethodik. Dadurch ist gewährleistet, dass eine optimale Anforderungsabdeckung, sowohl fachlich als auch im Rahmen der Testfallermittlung erreicht wird. Zusätzlich müssen die Tester aber auch Wissen über die Arbeitsweise der Entwickler besitzen. Dadurch können sie Fehler besser identifizieren, analysieren und in einer optimalen Weise an die Softwareentwickler kommunizieren.
Abbildung 4: Abstimmungsaufgaben der Service- und Testmanager
Auf der anderen Seite muss sich das Testcenter mit den externen Dienstleistern und der Entwicklung austauschen. Ziel der Abstimmung ist zum Beispiel der Abgleich der Inhalte der bereits gelaufenen Tests mit den nachgelagerten Integrationstests, um so die Lücken in den Tests oder ggf. Redundanzen aufzudecken. Darüber hinaus wird gemeinsam mit dem Kunden die Auslieferung neuer Softwarereleases auf die Testsysteme geplant und die Analyse und Nachverfolgung von Abweichungen besprochen.
Zusätzlich zur Planung und Durchführung der Testaktivitäten des übergreifenden Integrationstests kann das Testcenter die technische Unterstützung der Tests des Unternehmens übernehmen. Das wären zum Beispiel Aufbau und Wartung der Testinfrastruktur und Testumgebungen, sowie der Aufbau eines übergreifenden Testdatenmanagements. Wichtig ist dabei, dass auf den Integrationstestumgebungen alle zu testenden Softwaresysteme aufgesetzt werden, so dass der komplette Geschäftsprozess übergreifend geprüft werden kann.
Ein weiterführender Aspekt des Testcenters ist die fortlaufende Optimierung der Testprozesse. Neben der Verbesserung der bereits eingeführten Arbeitsschritte gehören dazu weitere Punkte. Das sind zum Beispiel die Einführung und Betreibung von Testautomatisierung, die Auflösung von existierenden Abhängigkeiten innerhalb und zwischen den Teststufen, sowie die frühzeitige Prüfung von Entwicklungsständen der Softwareentwicklungsdienstleister durch sogenannte Vorintegrationstests.
Dazu werden neben den Testumgebungen für die übergreifenden Integrationstests weitere Testumgebungen aufgebaut. Auf den Vorintegrationsumgebungen stellen die Dienstleister Vorreleasestände der Software bereit und geben so dem Vorintegrationsteam des Testcenters die Möglichkeit, in Zusammenspiel mit den anderen Applikationen frühzeitig Tests durchzuführen. Die Vorintegrationstests dienen damit der schnelleren Aufdeckung von möglichen Abweichungen zwischen den verschiedenen Informationssystemen der einzelnen Dienstleister.
Für Unternehmen, die ihre Software von unterschiedlichen Dienstleistern erstellen lassen und trotzdem komplexe und vernetzte Systemlandschaften besitzen, bietet ein externes Testcenter eine schnelle und gründliche Qualitätsaussage über alle Softwaresysteme. Ziel des externen Testcenters ist die Etablierung eines integrativen Testprozesses, welcher nicht nur die Zusammenschaltung der Testsysteme beinhaltet, sondern auch eine vernetzte Testorganisation und vernetzte Testprozesse. Damit begegnet das Testcenter den Anforderungen der Unternehmen nach stärkerem integrativen Testfokus und Flexibilität durch Skalierbarkeit, Kommunikation und geballter Testexpertise.
Die Nutzung von agilen Methoden ist kein uneingeschränkter Garant für bessere Software. Der Grund dafür ist, dass viele der klassischen Verfahrensweisen zur Qualitätssicherung im agilen Kontext vor einer Bewährungsprobe stehen. Denn wie soll in einem System mit häufigen Änderungen auf Dauer sichergestellt werden, dass die bereits als funktionstüchtig geltenden Bestandteile nicht durch zukünftige Nachbesserungen wieder in einen undefinierten Zustand verfallen?
Während das Wasserfallmodell den Test erst zu Projektende vorsieht und auch im vielfach eingesetzten V-Modell (siehe Abbildung 1) eine zeitlich klar definierte Abfolge vorliegt, ist es im agilen Umfeld unabdingbar, dass Tests aufgrund der Häufigkeit in der sie ausgeführt werden, tunlichst immer unter den exakt gleichen Bedingungen und mit möglichst geringem Aufwand durchgeführt werden können. Darüber hinaus sollten sie nach Möglichkeit zeitnahe zur Umsetzung der zu testenden Funktionalität bereit stehen. Denn nur so kann gewährleistet werden, dass sie mit dem steten Wandel schritthalten.
Abbildung 1: Das V-Modell und die testgetriebene Entwicklung
Test Driven Development
Das größte Problem des klassischen Testens ist in diesem Zusammenhang also, dass es in aller Regel nachgelagert geschieht. Es wird erst dann ausgeführt, wenn es auch etwas zu testen gibt. Dies scheint auf den ersten Blick trivial, denn soll etwas getestet werden ist vermeintlich auch ein entsprechender Testgegenstand von Nöten.
Zwar können die Testfälle und ihre Daten aus der Spezifikation abgeleitet werden, ohne eigentlichen Testgegenstand gibt es bei der Ausführung aber scheinbar kein auswertbares Ergebnis. Genau dieses Dogma gilt für automatisierte Tests nicht. Während die ständige manuelle Ausführung auf Dauer unbezahlbar würde, können automatisierte Tests getrost auch kurz vor der eigentlichen Implementierung verfasst, sowie ausgeführt werden und prüfen dann vorrübergehend nur eine Hülle des späteren Testgegenstandes. Eine Hülle wie sie beispielsweise von einer Schnittstellenbeschreibung vorgegeben ist.
In diesem Fall stellt der Test eine Art automatisierter Spezifikation dar, der Anforderungen zunächst nicht erfüllt werden (roter Beriech in Abbildung 2). Der Entwickler kann während der Implementierungsphase seinen Code gegen diese prüfen und erhält damit sofort ein Feedback ob seine Arbeit den Anforderungen entspricht. Ist dieser Status erreicht (grüner Bereich), hat er einen gesicherten Zustand des Quellcodes und kann jenen umstrukturieren (gelber Bereich). Bei neuen Anforderungen oder tiefgreifenden Änderungen schlagen die Tests erneut fehl (erneut roter Bereich) und müssen zunächst wieder korrekt erfüllt werden (erneut grüner Bereich).
Aus dieser einfachen Handlungsreihenfolge ergeben sich feingranulare Strukturen. Diese führen zu einer sehr hohen Testabdeckung, mit welcher Fehler frühzeitig gefunden und deren Behebung vereinfacht wird. Darüber hinaus werden Schnittstellen und deren Implementierung robuster als bei klassischen Verfahren definiert. Dies erlaubt erst die hohe Anpassungsfähigkeit des Quellcodes, welche für agile Softwareprojekte so essentiell wichtig ist.
Abbildung 2: Der Ablauf der testgetriebenen Arbeitsweise
Als eine der wichtigsten Eigenschaften von automatisierten Tests gilt darüber hinaus deren Lesbarkeit. Denn sie können im Grunde nicht nur als Prüfung der Funktionalität, sondern auch als eine Art Dokumentation der selbigen verstanden werden. Durch ihre Nähe zur Funktionalität die sie prüfen und ihrem klar strukturierten Aufbau, schildern sie das Verhalten des zu testenden Codes auf eine Weise wie es normal geschriebener Text nicht könnte. Da ihr eigenes Ergebnis überdies vollkommen abhängig vom Testgegenstand ist, teilen sie dem Betrachter automatisch mit wenn sie nicht mehr aktuell sind.
Behavior Driven Development
Diese Lesbarkeit erstreckt sich bei Komponententests jedoch einzig auf den Personenkreis der auch die entsprechende Programmiersprache versteht und das verwendete Testframework kennt. Domänenfremde Personen wie zum Beispiel Testmanager, Projektleiter oder sogar Endanwender können der feinen Granularität und Detailgenauigkeit nur wenig abgewinnen.
Eine zweite Unzulänglichkeit wird bei der Betrachtung des gesamten Entwicklungsprozesses offenbar. Mit TDD verfasste Tests sind hervorragend geeignet um Teile der Software anhand ihrer Spezifikation zu verifizieren, nicht aber um sie gegen die Akzeptanzkriterien zu validieren. Gerade diese sind es aber die befriedigt werden wollen und somit bei einer Überprüfung noch vor der Implementierung kommen sollten.
Aus diesen Gründen ist aus dem bekannten Test Driven Development das sogenannte Behavior Driven Development oder auch Acceptance Test Driven hervor gegangen. Bei diesem verschmelzen Tests und Spezifikation dank der Nutzung bestimmter Werkzeuge und Schlüsselworte so miteinander, dass die Testergebnisse in klarsprachlicher Weise ausgewertet werden können. Dazu wird insgesamt von der Beschreibung einzelner Funktionalitäten weg und zur Schilderung eines erwarteten Verhaltens (Behavior) hin gegangen. Auf diese Weise bedarf die Definition der einzelnen Testfälle keines Hintergrundwissens mehr zur Architektur des Programms, wodurch sie auch von Nichtentwicklern nachvollzogen werden kann und führt sogar soweit, dass häufig nicht einmal mehr von Testfällen sondern von Spezifikationen gesprochen wird.
Behaviour Driven Develoment kann nicht als eine Konkurrenz zum Test Driven Development verstanden werden. Denn ersteres dient vor allem der Validierung der Software sowie der Prüfung der Systemintegration, während letzteres der Verifikation und damit der Sicherung von funktionaler Korrektheit dient. Demnach ist es durchaus sinnvoll beides in Kombination zu verwenden.
Aufwand
Durch die Besonderheit, dass neben der eigentlichen Produktentwicklung von Entwicklern auch das Schreiben der Tests erwartet wird, führt die testgetriebene Entwicklung zunächst zu einem höheren Aufwand, als dies bei klassischen Verfahren üblich ist. So muss eine entsprechende Infrastruktur geschaffen, weitere Werkzeuge erlernt und zusätzlicher Code geschrieben werden, der nicht sofort in nutzbaren Features mündet. Dies mag zunächst abschrecken, zeigt aber im Grunde nur den Aufwand, der andernfalls viel später im Projekt anfällt. Statt der Aufwände für lange Test- und Bugfixingphasen gegen Ende des Projekts, wird ein Großteil der Qualitätssicherung bereits zu einem Zeitpunkt vorbereitet, indem ein Projektteam durchaus noch komfortabel handeln kann. Dieser Aufwand wiederum sinkt mit zunehmendem Projektverlauf, da die Infrastruktur häufig nur einmal grundlegen erstellt und anschließend nur noch punktuell angepasst werden muss.
Abbildung 3: Ab wann lohnt sich TDD?
Fazit
Der Einsatz der in diesem Artikel vorgestellten Methoden stellt teilweise einen erheblichen Bruch mit den klassischen Vorgehensweisen in der Softwareentwicklung dar, ermöglicht jedoch eine Qualitätssicherung und Dokumentation wie sie sonst nur schwer möglich ist. So verrät die Software im Grunde selbst ihren aktuellen Ist-Stand ohne dass externe Ressourcen gepflegt werden müssen, die unter Umständen schnell veralten. Durch die Kombination der unterschiedlichen Ansätze kann dabei die Qualität und ein umfassendes Projektverständnis über alle Abstraktionsebenen hinweg sichergestellt werden.
