Das Beitragsformat „Tester-Tea-Time“ greift Themen und Problemstellungen auf, die Testerinnen und Tester tagtäglich und vor allem wiederkehrend beschäftigen. Hier wollen wir solche Phänomene erläutern und Lösungen dafür finden, sowie Diskussionen und neue Denkweisen anregen. Im Testing können wir viel voneinander lernen, indem wir unseren Alltag beobachten!
Moderator: Willkommen zur Tester-Tea-Time! Im Interview mit Testerinnen und Testern der ZEISS Digital Innovation (ZDI) sprechen wir regelmäßig interessante Themen an. Heute geht es um das Thema Dokumentation im Projektalltag. Dazu unterhalten wir uns mit Sandra Wolf (SW), Testerin bei ZDI.
Sandra, warum bezeichnest du die Dokumentation als „ewig Ungeliebte“?
SW: Der Alltag einer Testerin oder eines Testers ist oft stressig und von hohem Zeitdruck geprägt. Wir machen die Erfahrung, dass deshalb für einige Aufgaben keine oder zu wenig Zeit bleibt. Dazu gehört unter anderem die Dokumentation. Sie wird gern vergessen oder aufgeschoben – deshalb der Titel „die ewige Ungeliebte“. Das liegt unter anderem daran, dass es Zeit frisst, etwas adäquat zu dokumentieren. Zeit ist kostbar. In unserer modernen Gesellschaft wird sie daher meist für die kritischsten Aufgaben im Arbeitsalltag verwendet. Wir wollen uns heute damit beschäftigen, was für eine Auswirkung eine gute Dokumentation auf den Alltag der Testerinnen und Tester haben kann und warum wir in Bezug auf deren Wichtigkeit umdenken sollten. Denn eines ist sicher: Sie hat einen festen Platz in unserem Leben als Tester verdient.
Moderator: Wo im Projektalltag begegnen die Testerinnen und Tester dem Thema Dokumentation?
SW: Im normalen Alltag wird jede Testerin und jeder Tester damit konfrontiert, Testergebnisse oder Abweichungen dokumentieren zu müssen. Hier ist es vor allem wichtig, alle Informationen zu hinterlegen, die andere Teammitglieder benötigen. Doch was ist mit der Dokumentation zum Zweck der Wissensvermittlung? Gerade bei komplexer Software kann es enorm wichtig sein, gewisse Kniffe oder fachliches Know-how niederzuschreiben. Der Umfang und die Aufmachung richten sich hier natürlich nach dem Projekt selbst. Liegt bereits eine Dokumentation durch die Konzeption durch den Kunden vor? Dann lässt sich darauf aufbauen. Wenn nicht, sollten alle Teammitglieder das Ziel haben, eine solche Dokumentation schrittweise aufzubauen. Viele werden nun denken, dass das viel zu aufwendig ist. Dafür ist im Projektalltag keine Zeit. Wir Testerinnen und Tester sollten jetzt innehalten und überprüfen, wie positiv sich eine gute Dokumentation auf unseren Arbeitsalltag und den Alltag der Kolleginnen und Kollegen auswirken kann.
Moderator: Und was genau sind die positiven Auswirkungen einer adäquaten Dokumentation?
SW: Die Dokumentation ist eine Grundvoraussetzung für das Wissensmanagement, d.h. für die Entwicklung, den Austausch und den Erhalt von Wissen. Durch ein gutes Wissensmanagement kann erreicht werden, dass aufkommende Fragen zuerst in der Dokumentation nachgeschlagen werden. Das spart Meetings, Anrufe und Zeit. An zentraler Stelle finden sich viele wichtige Informationen – die Basis, um selbstständig arbeiten zu können. So entfallen beispielsweise wiederkehrende Fragen durch Teammitglieder und die Einarbeitung neuer Kolleginnen und Kollegen wird vereinfacht. Auch beim Testing bestimmter komplexer Anwendungsbereiche kann eine solche Wissenssammlung unterstützen, um spezielle Tests zu dokumentieren oder fachliches Hintergrundwissen zu vermitteln. Auch der Test selbst kann durch das Nachschlagen dieser Anforderungen und Tipps beschleunigt werden.
Alle beschriebenen Beispiele sparen Zeit, die wir vermeintlich nicht haben, um etwas zu dokumentieren. Natürlich ist der Aufwand zunächst hoch, um ein solche Wissensbasis aufzubauen, aber dadurch entsteht ein wertvolles Instrument, um auf lange Sicht Zeit zu sparen und den Arbeitsalltag und den Testing-Prozess effizienter zu gestalten.
Moderator: Das bedeutet, das es sich auf jeden Fall auszahlt, wenn das Projekt in den Aufbau der Dokumentation Zeit investiert?
SW: Ja, zusammenfassend kann ich sagen, dass sich die Investition von Zeit und Ressourcen in den Aufbau einer Wissensbasis lohnt. Der Gewinn aus dieser Investition ist wiederum Zeit, die im Arbeitsalltag stets knapp bemessen ist. Sie kann für andere Aufgaben genutzt werden. Zur Steigerung der Effizienz ist ein gutes Wissensmanagement für jedes Projekt unerlässlich.
Moderator: Wie kann nun eine Einführung bzw. Umsetzung dieses Wissensmanagements im Projekt aussehen? Dazu fragen wir Max Wielsch (MW), Entwickler bei der ZDI. Max, was kannst du uns zu diesem Thema sagen?
MW: In meinem Projekt gibt es eine sehr umfassende Wiki-Dokumentation in Confluence. Sie wird ergänzt durch eine codebasierte Dokumentation, die in das Wiki eingebunden wird. Diese Wissenssammlung habe ich in Zusammenarbeit mit meinem Team geschaffen. In der Vergangenheit gab es zwar bereits eine Dokumentation, allerdings war sie reduziert auf zwei Word-Dateien und es gab zu diesem Zeitpunkt keine Wissensträger mehr. Da wir eine sehr komplexe Plattform, bestehend aus mehreren Microservices betreuen – vor allem auf technischer Seite – war für uns aber klar, dass eine umfassende Dokumentation einen entscheidenden Mehrwert bringen wird.
Moderator: Wie genau hast du denn diese Mammutaufgabe gelöst? Kannst du anderen Kolleginnen und Kollegen ein paar Tipps mit auf den Weg geben?
MW: Mein Ziel war es, Struktur in das vorhandene Chaos zu bringen. Natürlich ist das Schaffen einer guten Dokumentation nie ganz abgeschlossen. Es braucht auch im späteren Verlauf eine dauerhafte und adäquate Pflege der Doku, um eine korrekte Wissensvermittlung zu gewährleisten. Am Anfang habe ich mich jedoch erst einmal informiert und dafür entschieden, arc42 als Struktur-Vorlage für das Wiki zu nutzen. Sie wurde für unser Projekt angepasst. Da wir ein komplexes System von Systemen haben, ist die Doku auch entsprechend gegliedert. Einzelne Module bzw. Bausteine können wiederum eine neue Unterstruktur haben. Außerdem haben wir verschiedene Arten von Dokumentationsbereichen: Die Architekturdokumentation, die sowohl eine technische als auch eine fachliche Doku beinhaltet und die Betriebsdokumentation. Diese Bereiche befinden sich alle im Wiki. Zusammenhängende Themen werden untereinander verlinkt, damit ein einfacher Wissensaustausch und -aufbau möglich ist. Auf all diesen Seiten werden beispielsweise Prozesse erklärt, auf fachliche Erläuterungen in Glossareinträgen verwiesen oder Konfigurationen eines Moduls beschrieben. Auch spezielle Filter des Issue-Trackers (Jira) binden wir ein, um relevante Bugs oder kommende Stories auf einen Blick sichtbar zu machen. Kontext ist einfach alles!
Moderator: Das klingt sehr aufwendig, aber interessant. Hat sich die Einführung einer solchen Dokumentation für dich gelohnt?
MW: Auf jeden Fall! Wir gewinnen allein schon dadurch Zeit, wenn wir bei Fragen der Fachbereiche, des Betriebes oder anderen Stakeholdern auf entsprechende Seiten verweisen können. Außerdem ist diese Dokumentationsstruktur das perfekte Werkzeug, um neue Software-Versionen an den Betrieb zu übergeben. Wir haben beispielsweise besondere Felder in unseren Storys und Bugs, die wir dann auf speziellen Release-Wiki-Seiten in Tabellen auflisten können. Wir können verschiedene Aspekte der Änderung darstellen. Einerseits haben wir die Release-Notes für die Kommunikation an Stakeholder, andererseits gibt es bei uns die sogenannten „Ops-Notes“. Mit ihnen können wir gezielte Hinweise zum Betrieb einer neuen Funktion geben. Natürlich sind dort entsprechende Links auf Seiten der Betriebsdokumentation enthalten. Man sieht, Dokumentation zieht sich von der Planung bis zum Betrieb durch. Schlussendlich haben wir immer die Sicherheit, nachweisen zu können, dass Änderungen am Softwarestand vollständig übergeben und der Betrieb alles zur Verfügung gestellt bekommen hat, was er wissen muss.
Moderator: Wow, dieses Beispiel zeigt wirklich sehr gut, welche Vorteile die Dokumentation im Projekt haben kann. Gibt es aus deiner Sicht auch Nachteile, die es zu berücksichtigen gilt?
MW: Ja, die gibt es immer. Eine komplexe Dokumentation ist pflegebedürftig. Sie will aktuell gehalten werden. Alte, obsolete Informationen müssen entfernt werden. Es ist auch nicht immer leicht, die Dokumentationsstrukturen zu bewahren. Für die inhaltliche Pflege muss genau der richtige Detailgrad gefunden werden, damit die wirklich nötigen Informationen da sind und alles, was verzichtbar ist, nicht gepflegt werden muss. Es ist immer eine Kosten-Nutzen-Abwägung zu treffen und diese ist stark vom Projektkontext abhängig. Was die Bewahrung der Struktur angeht: Eigentlich ist das ganze Team verantwortlich für die Dokumentation. Doch wie so oft braucht es manchmal einen Verantwortlichen, der beobachtet, kontrolliert und korrigierend eingreift. Das kann insbesondere bei großen Projekten, beziehungsweise vielen Entwicklerinnen und Entwicklern hilfreich sein, damit eine klare Linie in der Dokumentation zu erkennen ist. Wenn alle Entwicklerinnen und Entwickler die Prinzipien der Doku verinnerlicht haben und diese korrekt anwenden, braucht es das vermutlich weniger. Aber auch das ist eben sehr stark vom Projekt, d. h. der Teamzusammensetzung, den Fähigkeiten und den Spezialgebieten abhängig.
Moderator: Das ist ein gutes Schlusswort. Vielen Dank, Sandra und Max, für diese Einblicke. Zusammenfassend sehen wir, dass sich eine gute Dokumentation für das Projekt auszahlen kann, die Entscheidung für deren Aufbau allerdings von den Rahmenbedingungen im Projekt abhängig ist. Dieses ungeliebte Thema hat mehr Aufmerksamkeit verdient, da es das Potenzial hat, auf Dauer Zeit zu sparen und das Arbeiten im Team effizienter zu gestalten. Denn wie in der ISO-Norm 24765 beschrieben wird, ist die Dokumentation ein Aspekt der Produktqualität und somit auch der Qualität der erstellten Software, was ihre Wichtigkeit unterstreicht.
In den folgenden Beiträgen werden wir weitere Problemstellungen aus dem Alltag von Testerinnen und Testern aufgreifen und besprechen, welche möglichen Lösungsansätze es dafür gibt.
Dieser Beitrag wurde verfasst von:
