Suche

Wie können wir verhindern, dass geänderter Code ungetestet ins Release gelangt?

Elmar Jürgens

Elmar Jürgens

Risikobasiertes Testen und das Aufspüren fundamentaler Organisations- und Architekturprobleme – das sind die Themen, die Elmar Jürgens (CQSE GmbH) auf der kommenden W-JAX behandeln wird. Mit dem folgenden Beitrag gibt er einen Vorgeschmack und erklärt aus seiner Testpraxis, wie Codeänderungen nicht durch die Maschen der Testabdeckung fallen.

Bei langlebiger Software treten meist dort Fehler auf, wo viel geändert wurde. Es lohnt daher, geänderte Bereiche besonders ausführlich zu testen. Erfahrungsgemäß legen Testmanager darauf in der Testplanung auch besonderen Wert und versuchen, die Tests entsprechend auszuwählen. Bei automatisierten Tests bietet es sich an, einfach alle Testfälle laufen zu lassen. Unserer Erfahrung nach decken automatisierte Tests in den meisten Systemen in der Praxis jedoch nur einen kleinen Teil der Code-Basis ab.

Daher wird in den meisten Systemen vor einem Release immer noch eine große Anzahl von Testfällen manuell durchgeführt. Häufig existiert ein Pool von mehreren tausend manuellen Testfällen. Da ihre vollständige Durchführung oft mehrere Personenmonate kostet, wird aus dem Pool für jedes Release eine kleine Teilmenge zur Durchführung ausgewählt.

Wie gut werden Code-Änderungen in der Praxis durch Tests wirklich abgedeckt?

In einem großen System ist es jedoch alles andere als trivial, die manuellen Testfälle so auszuwählen, dass sie auch die Änderungen durchlaufen, die seit der letzten Testphase durchgeführt wurden. Um besser zu verstehen, ob die Tests die Änderungen tatsächlich erreicht haben, haben wir eine wissenschaftliche Studie [1] auf einem betrieblichen Informationssystem durchgeführt. Das untersuchte System umfasst ca. 340.000 Zeilen C#-Code. Wir haben die Studie über 14 Monate Entwicklung durchgeführt und dabei zwei aufeinanderfolgende Releases untersucht.

Durch statische Analysen haben wir ermittelt, welche Code-Bereiche für die beiden Releases neu entwickelt oder verändert worden sind. Für beide Releases wurde etwa 15% des Quelltextes
modifiziert. Außerdem haben wir alle Testaktivitäten für beide Releases ermittelt. Dafür haben wir die Testüberdeckung einer Vielzahl von automatisierten und manuellen Tests über mehrere Monate aufgezeichnet. Auf den ersten Blick wurde dabei ein großer Teil des Systems abgedeckt.

Eine Auswertung der Kombination aus Änderungs- und Testdaten zeigte jedoch, dass etwa die Hälfte der Änderungen ungetestet in Produktion gelangten.

Welche Folgen haben ungetestete Änderungen?

Um die Konsequenzen der ungetesteten Änderungen für die Anwender des Programms zu quantifizieren, haben wir retrospektiv alle Fehler analysiert, die in den Monaten nach den Releases aufgetreten sind. Dabei zeigte sich, dass die Fehlerwahrscheinlichkeit in geändertem, ungetestetem Code 5x höher war als in ungeändertem Code (und auch höher als in geändertem und getestetem Code).

Die Studie führt uns vor Augen, dass Änderungen in der Praxis sehr häufig ungetestet in Produktion gelangen und dort den Großteil der Feldfehler verursachen. Sie gibt uns damit aber auch einen konkreten Ansatzpunkt, um die Testqualität systematisch zu verbessern: Wenn es uns gelingt, Änderungen zuverlässiger zu testen.

API Summit 2018
Christian Schwendtner

GraphQL – A query language for your API

mit Christian Schwendtner (PROGRAMMIERFABRIK)

Warum rutscht Code durch den Test?

Die Menge an ungetestetem Code in Produktion hat uns offen gesagt überrascht, als wir diese Studie zum ersten Mal gemacht haben. Inzwischen haben wir vergleichbare Analysen in vielen Systemen, Programmiersprachen und Firmen durchgeführt und erhalten oft ein ähnliches Bild. Die Ursache für ungetestete Änderungen liegt jedoch – anders als man vielleicht vermuten könnte – nicht an mangelnder Disziplin oder am Einsatz der Tester, sondern vielmehr daran, dass es ohne geeignete Analysen sehr schwierig ist, geänderten Code in großen Systemen im Test zu erwischen.

Testmanager orientieren sich bei der Testauswahl häufig an den Änderungen, die im Issue Tracker (Jira, TFS, Redmine, Bugzilla, …) dokumentiert sind. Für fachlich motivierte Änderungen funktioniert das erfahrungsgemäß auch oft gut. Testfälle für manuelle Tests beschreiben typischerweise Interaktionssequenzen über die Nutzeroberfläche, um gewisse fachliche Abläufe zu testen. Enthält der Issue Tracker Änderungen einer Fachlichkeit, werden die entsprechenden fachlichen Testfälle zur Durchführung ausgewählt.

Unsere Erfahrungen zeigen jedoch, dass Issue Tracker aus zwei Gründen keine geeigneten Informationsquellen sind, um Änderungen lückenlos zu finden. Erstens gibt es häufig technisch motivierte Änderungen, wie bspw. Aufräumarbeiten oder Anpassungen an neue Versionen von Bibliotheken oder Schnittstellen zu Fremdsystemen. Bei derartigen Änderungen ist es für Tester nicht nachvollziehbar, welche fachlichen Testfälle durchgeführt werden müssten, um diese technischen Änderungen zu durchlaufen.

Zweitens, und noch gravierender ist jedoch, dass in vielen Fällen zentrale Änderungen am Issue Tracker vorbeigehen, sei es aus Zeitdruck oder aus politischen Gründen. Dadurch sind die Daten im Issue-Tracker lückenhaft. Um Änderungen lückenlos zu finden, benötigen wir daher zuverlässige Informationen, welche Änderungen im Test durchlaufen wurden, und welche nicht.

Was kann man machen?

Ich stelle im Vortrag „Haben wir die entscheidenden Änderungen erwischt? Risikobasiertes Testen von gewachsener Software“ auf der W-JAX 2015 Test-Gap-Analyse vor, einen Ansatz, der statische und dynamische Analyseverfahren kombiniert, um geänderten aber ungetesteten Code zu identifizieren. Abbildung 1 zeigt eine Treemap, die den Quelltext eines Beispiel-Systems visualisiert. Jedes Rechteck repräsentiert eine Komponente. Der Flächeninhalt korrespondiert mit der Größe der Komponente in Zeilen Quelltext. Exemplarisch ist die primäre Funktion einzelner Komponenten angegeben.

components

Komponenten des untersuchten Beispiel-Systems

Die zweite Abbildung zeigt eine Treemap mit Ergebnissen einer Test-Gap-Analyse für dieses System. Die kleinen Rechtecke in den Komponenten repräsentieren hier die enthaltenen Methoden, ihr Flächeninhalt korrespondiert mit der Länge der Methode in Zeilen Quelltext. Die Farben haben folgende Bedeutung:

  • Graue Methoden wurden seit dem letzten Release nicht verändert.
  • Grüne Methoden wurden verändert (oder neu programmiert) und kamen im Test zur Ausführung
  • Orange (und rote) Methoden wurden verändert (oder neu programmiert) und kamen im Test nicht zur Ausführung.
testgaps

Test-Gaps des untersuchten Beispiel-Systems

Man kann klar erkennen, dass im rechten Bereich der Treemap ganze Komponenten mit neuem oder verändertem Code im Test bisher nicht zur Ausführung kamen. Alle in ihnen enthaltenen Fehler können daher im Test nicht gefunden worden sein. Die Test-Gap-Analyse erlaubt Test-Managern damit, derartige Lücken rechtzeitig zu erkennen und ggf. gegenzusteuern.

Ich stelle im Vortrag nicht nur die zugehörigen Werkzeuge vor, sondern gehe auch auf die Erfahrungen aus mehreren Jahren Einsatz in Teams mit bis zu 20 Entwicklern und 30 Testern ein. Ich zeige, wie Test-Gap-Analyse Transparenz in die Qualitätssicherung bringt und dabei hilft, Testaufwände bewusst zu allokieren und die Zusammenarbeit zwischen Entwicklern und Testern zu
synchronisieren.

Weiterführende Informationen zu Test-Gap-Analyse finden sich darüber hinaus in diesem (englischsprachigen) Blog-Artikel.

Geschrieben von
Elmar Jürgens
Elmar Jürgens
Elmar Juergens hat über statische Codeanalyse promoviert und für seine Doktorarbeit den Software-Engineering-Preis der Ernst-Denert-Stiftung erhalten. Er ist Mitgründer der CQSE GmbH und begleitet seit sieben Jahren Teams bei der Verbesserung ihrer Qualitätssicherungs- und Testprozesse. Juergens spricht regelmäßig auf Konferenzen wie der OOP, W-JAX, ICSE, CSMR, SQD oder den XP Days. Er wurde von den Teilnehmern zum besten Sprecher der Clean Code Days 2014 und der Software Quality Days 2015 gewählt.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: