Wer weiß noch, wie unsere Großeltern gearbeitet haben? Was werden unsere Enkel über unsere Arbeit erfahren? Werden sie wissen wollen, wie man noch in fest zugeordneten Büros arbeiten konnte und weshalb die Zusammenarbeit über verschiedene Kontinente eine Herausforderung war?
Mit diesen und weiteren Fragen haben wir uns beschäftigt und viele Autoren gewonnen, die sich hierzu ebenfalls Gedanken gemacht haben. Das bestimmende Thema in diesem Heft ist die Digitale Transformation, hin zur Industrie 4.0: Es geht um Qualitätssicherung in international vernetzten, grenzenlos agierenden Unternehmen und deren Anforderungen an moderne Entwicklungsprojekte: schneller, agiler und mit brauchbaren Zwischenständen. Wie gut muss die Qualität zu welchem Zeitpunkt sein? Und wie schaffen wir es, dass die qualitätssichernden Maßnahmen auch mit der Projektkomplexität skalieren? Wie passen immer wiederkehrende Fragen der Testeffizienzsteigerung zu den verwendeten Architekturmustern oder zu Entwicklungsansätzen wie dem agilen Vorgehen?
Auf Reisen …
Richie ist gerade aus dem Silicon Valley zurückgekehrt. Vollgepackt mit neuen Ideen, Inspirationen und Demut vor dem, was sich dort gerade entwickelt. Wir haben uns lange über seine Einblicke in die dort angesiedelten Start-ups und Unternehmen unterhalten und welche Herausforderungen die neuen Technologien, Arbeitsweisen und Systeme an Softwaretest und Qualität stellen.
In Anbetracht der in vielen herkömmlichen Branchen bevorstehenden Veränderungen klingt die Bezeichnung „Digitalisierung“ fast schon etwas niedlich – die Änderungen werden vermutlich disruptiv ausfallen, neue Geschäftsfelder eröffnen und andere verschwinden lassen. In manchen Branchen wiegt man sich noch in trügerischer Hoffnung, dass dieser Kelch der Veränderung an einem vorbeigeht. Manche sehen Bedenken und Probleme, während sie schon links und rechts überholt werden. Und wieder andere sehen die Chance und nutzen die Potenziale, die Software und Daten heute schon bieten. Egal, ob sich die letztgenannten mit künstlicher Intelligenz, autonomen Systemen, vorhersagenden Techniken oder erweiterter Realität beschäftigen: Unser Kernthema Softwarequalität ist in hohem Maße betroffen.
Aus groß wird komplex
Die jüngsten Jahrzehnte waren davon geprägt, dass Systeme immer größer wurden. Dafür wurden Prozesse, Verfahren und Tools geschaffen, die dies beherrschbar machten. Immer weitere Optimierungen (z. B. Testcenter), Verbesserungen (z. B. effizientere Workflows, bessere Tools), mehr Automatisierung (z. B. Testautomatisierung auf allen Teststufen) haben uns geholfen, für große Systeme auch effiziente Qualitätssicherung zu ermöglichen.
Aber große Systeme werden von komplexen Systemen abgelöst. Die ihnen innewohnenden Abhängigkeiten, Beziehungen und Algorithmen werden immer schwerer überschaubar und begreifbar. Dennoch müssen sie qualitätsgesichert werden, also mindestens verifiziert und meistens auch getestet. Möglichkeiten der Anpassung an diesen Wandel sehen wir immer öfter: Prozessmodelle werden so entworfen, dass effiziente und schnelle Qualitätssicherung noch möglich ist; Architekturen für Systeme werden so entworfen, dass das Verständnis für gekapselte Einheiten möglich und die fokussierte Qualitätssicherung machbar sind.
Prozesse und Architektur ermöglichen Testeffizienz
Das typische Mittel zur Effizienzsteigerung ist der Einsatz der Automatisierung. Für den Test bedeutet das im ersten Schritt die automatische Testdurchführung. Die Vorteile liegen auf der Hand: schnelle Durchführung, schnelle Rückmeldung insbesondere für den Regressionstest. Lediglich die Vorbereitung der zugehörigen Testskripte erfordert bei der Erstellung oder Anpassung signifikante Aufwände.
Wie schaffen wir es aber, dass wir dieses Verfahren in sich ändernden Umgebungen anwenden können? Häufige Änderungen sind in agilen Entwicklungsprozessen zu finden. Während jedes Sprints braucht man automatisch durchführbare Testskripte, die die funktionale Qualität des Systems bewerten. Diese Testskripte müssten aufgrund der wahrscheinlichen Änderungen in dem aktuellen Sprint auch schnell angepasst werden. Eine manuelle Anpassung eines signifikanten Teils der Testskripte pro Sprint ist für jedes nichttriviale und änderungsbehaftete Projekt aber nur mit hohen Kosten realisierbar.
Sollten wir deswegen die automatische Testdurchführung aufgeben? Nicht doch! Stattdessen müssen wir Wege finden, um die Anpassungsaufwände für die Testskripte zu reduzieren. Dies findet sich bekanntermaßen in Ansätzen der datengetriebenen, schlüsselwortgetriebenen oder modellbasierten Testentwurfstechniken. Zudem ist die Qualitätssicherung nicht mehr nur eine Aufgabe des Testers am Ende der Prozesskette. Vielmehr gehört die Implementierung der notwenigen Tests zur Entwicklung, wie das Schreiben und Einchecken des Quellcodes selbst.
Die nächste spannende Frage ist, wie wir die Fokussierung der einzelnen Tests aufrechterhalten können. Wie können Einflüsse von anderen Funktionen auf die eigentlich zu testende Funktion reduziert werden? Hier spielt die verwendete Architektur eine wichtige Rolle. Kleine, austauschbare Einheiten finden intensive Anwendung im Architekturansatz für Microservices: Jeder Microservice hat seine eigenen Tests; jeder Microservice ist unabhängig von anderen und die Kommunikation ist nur über Schnittstellen definiert; jeder Microservice ist auf einen bestimmten Kundennutzen fokussiert.
Kleine Teams, übersichtliche Architektur, fokussierte Tests, Kundennutzen im Vordergrund: all diese Vorteile können sich aus der klugen Wahl der eingesetzten Architekturen, Prozesse und Testansätze ergeben. Wir haben hier exemplarisch Microservices, Agile und Testautomatisierung hervorgehoben, die in dieser Zusammenstellung auch komplexe Projekte wartbar, testbar und verständlich halten. Hier bleiben die Testaufwände angemessen, der Testfokus auf den Kundennutzen gerichtet und die Skalierbarkeit der Qualitätssicherung mit der Komplexität des zu entwickelnden Systems gegeben. Das Poster “Effizienzsteigerung im Softwaretest” zeigt die Zusammenhänge exemplarisch auf. Abbildung 1 zeigt die grobe Struktur des Posters und der dargestellten Zusammenhänge.
Qualität als Haltung im Team
Neben den zuvor genannten technischen Faktoren sind die weichen Faktoren von unschätzbarem Wert. Wer heute exzellente Software kreieren möchte, denkt den Entwicklungsprozess ganzheitlich: neben Methoden und Tools vor allem Menschen und Mindset – wenn alles in einem Flow zusammenspielt, dann entstehen Potenzialentfaltung und Innovation. Qualität wird durch das Team sichergestellt. Die Qualitätssicherung wird eine umfassende Aufgabe, getragen durch die Haltung des gesamten Teams.
Das bedeutet für viele Mitglieder des Teams einen massiven Veränderungsprozess, der Erfahrung, Empathie, Hingabe und Geduld benötigt. Mit einem Workshop oder einer Schulung ist es da nicht getan. Es braucht begleitende Unterstützung, immer wieder Impulse und Hilfestellungen, damit ein Team seinen individuellen Weg finden kann, agile Werte wie Mut, Transparenz, Offenheit und Selbstorganisation zu leben. Die Einstellung der Teammitglieder zu dem Projekt und zu dem gewählten Prozess trägt entscheidend zum Erfolg oder Scheitern eines jeden Projekts bei!
Natürlich ist eine fundierte Ausbildung die Basis, auf der so ein Veränderungsprozess fußen muss. Die gleiche „Sprache“ sprechen, das Qualitätshandwerkszeug beherrschen, die Methoden und Vorgehen verstehen und anwenden können: Für den Bereich Softwaretest liefert das Certified Tester Schema genau das als weltweit führendes berufsbegleitendes Weiterbildungsschema zum Thema SW-Qualität. (www.german-testing-board.info)
Neben den Faktoren, die den Erfolg des Entwicklungsprojekts unterstützen, gibt es zahlreiche weitere Faktoren, die über den Erfolg des entwickelten Produktes entscheiden.
Usability: Don‘t make me …
Die Akzeptanz eines Produktes, einer App oder Software liegt immer stärker auf der Usability und dem Erleben des Nutzers, dem Happening. Und das betrifft nicht mehr nur Privatanwender. Auch der Anspruch an geschäftlich genutzte Software steigt: Wenn Mitarbeiter mehrere Stunden am Tag mit langsamen, überfrachteten und komplizierten Oberflächen hantieren müssen, dann ist Frust vorprogrammiert. Start-ups orientieren sich an diesen Painpoints und lösen sie auf. Dabei sind immer wieder drei große Leitlinien zu beobachten, an denen man sich orientieren sollte:
- Don’t make me wait: Niemand möchte mehr auf irgendwas warten. Verfügbarkeit in Echtzeit zählt. Ladebalken, Schlangestehen und Warten sind ein KO-Kriterium.
- Don’t make me ask: Jede Frage hält auf. Das System kennt mich, hat meine Daten. Dann noch einmal nachzufragen ist ein No-Go!
- Don’t make me think: Das Denken abnehmen! Wer vor einer Oberfläche oder Website sitzt und zuerst einmal überlegen muss, wie was wo und warum funktioniert, der ist schnell geneigt, auf das „x“ zu klicken, oder er wird zumindest keine ausufernde Freude bei der Nutzung empfinden. Wir sind verwöhnt von Apps & Co. Sie haben hier geklickt? Dann möchte Sie vielleicht auch dies und das …
Diese Aspekte betreffen meist nicht nur einzelne Komponenten, sondern komplette Abläufe des Nutzers. Steht das Hinterfragen der Geschäftsprozesse dem Tester überhaupt zu? Na klar! Gerade sein kritischer Blick ist hier gefragt. Wie kann die Anwendung einfacher gestaltet werden? Was kann dem Nutzer abgenommen werden? Brauchen wir noch Funktion X und Y? Welche alten Zöpfe (z. B. Schnittstellen, Sonderlocken, Module) können abgeschnitten werden? Was an „historisch gewachsenem“ kann neu gedacht werden?
Wie geht es weiter?
Was fangen wir mit den Eindrücken von Richies Reise nun an? Wir leben in aufregenden Zeiten. Technologisch und insbesondere mit aktueller Software stehen uns in den nächsten Jahren Möglichkeiten zur Verfügung, die wir jetzt vermutlich noch nicht erdenken können oder nicht wahrhaben wollen.
Ein schönes Beispiel ist das autonome Fahren: Was hierzulande oft mit umfangreichen Bedenken und Auflagen gekontert wird, hat in anderen Ländern schon ganz andere Dimensionen erreicht. Wer heute durch die Straßen von San Francisco geht, sieht alle paar Minuten ein Testfahrzeug einer der unzähligen Firmen, die damit im öffentlichen Straßenverkehr fahren dürfen. Und die Fortschritte in dieser Technologie sind in den letzten Jahren enorm [CA19, Her19]. Der Anspruch an Qualität und Qualitätssicherung in diesem Umfeld ist enorm und wird wohl in Zukunft auch nicht geringer werden. Unfälle wie der von Uber gehen dann natürlich sofort durch die internationale Presse.
Vor diesem Hintergrund vergisst man leicht, dass es im Straßenverkehr mit Menschen am Steuer jeden Tag etliche Unfälle mit Toten gibt. Der direkte Vergleich zeigt auch, dass häufig Menschen schuld an Unfällen mit selbstfahrenden Autos sind [Kok17]. Die Herausforderung ist und bleibt natürlich, dass die Anzahl der Unfälle auf ein Minimum reduziert wird und dass kein einziger davon auf einen Fehler eines selbstfahrenden Fahrzeugs zurückzuführen sein darf.
Und dieser Herausforderung müssen wir uns als Tester und Qualitätsverantwortliche stellen: mit Prozessen, Architekturentwürfen, Tools, Ausbildung und einem passenden Mindset.
Der Artikel ist in der Ausgabe 01/2019 des German Testing Magazin erschienen.