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.
Die Komplexität und Interaktion der Softwareanwendungen, die in Unternehmen eingesetzt wird, ist in den letzten Jahren stark gestiegen. Werden heute Releases ausgerollt, steht ein Teil der neuen Funktionen immer im Zusammenhang mit dem Datenaustausch zu anderen Anwendungen. Das merken wir auch im Bereich Softwaretest: Der Fokus der Tests hat sich von reinem Systemtest auf den Bereich der Integrationstests erweitert. Darum kommen auch Mocks zum Einsatz.
Wir arbeiten in einem Testcenter und führen für unsere Kunden den übergreifenden Integrationstest über seine komplexe Anwendungsinfrastruktur durch. Daher bauen wir die Testumgebungen passend zur Produktivumgebung auf. Also wozu brauchen wir dann Mocks, wenn die Integrationstestumgebung bereits alle Software-Komponenten besitzen?
Zum Teil liegt man mit dieser Denkweise schon richtig, allerdings werden auf den unterschiedlichen Staging-Ebenen beim Test verschiedene Fokusse gesetzt. Mocks werden im Systemtest eher weniger verwendet, da in diesem Bereich die Funktionen der Software getestet werden. Dafür werden Mocks häufiger in Integrationstest verwendet. Da es aber nicht immer möglich ist, den kompletten Nachrichtenfluss zu testen, wird als Alternative die Kommunikation an der Schnittstelle geprüft.
Werden im Integrationstest 3 Komponenten getestet, die im Nachrichtenfluss direkt hintereinanderliegen, kann bei Verwendung aller 3 Softwarekomponenten nicht hundertprozentig sichergestellt werden, dass die Prozedur ohne Probleme läuft. Es könnte sein, dass die jeweiligen Fehler der Komponenten den Nachrichtenfluss verfälschen und im Nachhinein wieder richtiggestellt wird, der Fehler quasi maskiert wird. Daher stellen wir Mocks an die jeweiligen Enden der Komponenten, um gezielte Ein- und Ausgaben zu bekommen.
Um die beschriebenen Probleme und Eigenheiten eines Mocks zu erklären, nutzen wir als zu testende Anwendung einen Rest-Services. Der Rest-Service sollte in der Lage sein, ein GET und ein POST–Befehl durchzuführen. Würde unsere Komponente nun nach personenspezifischen Daten beim Mock nachfragen mit einem GET-Befehl, könnten wir unseren Mock so konfigurieren, dass er standardisierte Antworten zurück gibt oder bei POST-Befehlen einfache Berechnungen durchführt.
Mit Microsoft Visual Studio kam man in C# schnell ein WebAPI-Projekt erstellen, welches die grundlegende Funktion eines Rest-Services besitzt. Die Methoden des Controllers müssen nur noch angepasst werden und man hat eine funktionierende Rest-API zur Verfügung.
Datei > Neu > Projekt > Visual C# > Web > Webanwendung
Wenn man sich die Controller der WebAPI anschaut, kann man sehen, dass bestimmte URLs, Funktionen innerhalb der API aufrufen. In diesem Beispiel wird eine kleine WebAPI verwendet, die als Helden-Datenbank genutzt wird.
Die Route beschreibt den URL-Pfad um die HttpGet(GET-Befehl)- oder HttpPost(POST-Befehl) Funktion aufzurufen.
Beispiel: http:localhost/api/helden/add
Sobald man die Rest-API zum Laufen gebracht hat, ist es mit einem API-Tool(Postman) oder einem Browser möglich, unterschiedliche Rest-Befehle an die URL zu schicken. Wenn nun ein POST-Befehl an die Rest-API geschickt wird, nimmt der Service diesen an und erkennt anhand der URL, dass die Funktion AddHeldenDetails() aufgerufen werden soll. Die Funktion nimmt die mitgeschickten Daten auf und fügt sie ihrer Datenbank hinzu. Als Antwort liefert sie den Return-Wert der Funktion. In diesem Fall die Bestätigung über das Hinzufügen des gewünschten Heldes.
Wir haben nun mit unserem POST-Befehl die Heldin Maria der Datenbank hinzugefügt. Nun können mit dem GET-Befehl die gespeicherten Helden abrufen werden. Hier ein Beispiel zum Format des GET-Befehls, welcher an die Rest-API geschickt wird mit der dazugehörigen Antwort der API:
In der Antwort ist zusehen, dass die Heldin Maria der Liste hinzugefügt wurde und nun jederzeit abgerufen werden kann.
Nun wissen wir um die Funktionsweise den Rest-Services Bescheid, welcher Input zu welchem Output führt. Mit dieser Information können wir uns dann an den Bau eines Mocks begeben. Mit diesem Thema werde ich mich im nächsten Teil genauer befassen.
Das war „Mocks in der Testumgebung Teil 1“ … Teil 2 folgt 🙂
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.
