German Testing Day 2017, Frankfurt: Vortrag von Marcus Ciolkowski (Senior Berater bei QAware). Abstract: Kontinuierliche Beurteilung der Qualitätsschulden beflügelt die Qualität von Softwareprojekten, für Sanierungsprojekte ebenso wie für Projekte auf der „grünen Wiese“. Wichtig sind die agilen Prinzipien kontinuierliches Feedback und Vermeidung von Broken Windows. Für statische Kennzahlen (meist Codemetriken) ist das einigermaßen gut bekannt und beherrscht (z.B. mit SonarQube). Schwieriger zu greifen sind dynamische Kennzahlen für Qualitätsschulden. Beispiele sind Veränderungen von Ausführungszeiten oder Speicherverbrauch in Tests sowie von Ausführungszeiten im Betrieb, die auf schwer sichtbare Abhängigkeiten im Code oder auf Leaks deuten können. Die Daten dafür fallen sogar meistens „nebenbei“ an, z.B. während Unit- und Lasttests, oder in Form von Logfiles. Existierende Werkzeuge haben allerdings Probleme bei der Messung und ausreichend feingranularer Speicherung der zugehörigen Daten. Wir zeigen für einen Big Data fähigen Ansatz anhand von Daten aus Unit- und Integrationstest folgende Schritte: • integrierte Messung von dynamischen Kennzahlen • feingranulare Speicherung in einer Zeitreihendatenbank als Data Lake • Überwachung der Kennzahlen per Dashboard

1. Bewertung von Qualitätsschulden mit dynamischen Daten
aus Test und Betrieb
Eine Machbarkeitsstudie
Marcus Ciolkowski, QAware GmbH
German Testing Day, Frankfurt, 19./20.6.2017

2. 2
Agenda
1. Wieso bewertet man Qualitätsschulden in Projekten?
2. Wieso benötigt man dynamische Kennzahlen?
3. Wieso sind die Daten dafür oft vorhanden?
4. Wieso eine Zeitreihendatenbank, um Indikatoren abzulegen?
5. Wie sieht ein Fallbeispiel dazu aus?
6. Was ist das Fazit?

3. Was verstehen wir unter Qualitätsschulden?
3
■ Qualitätsschulden:
■Kosten zur Erreichung „angemessener“ Architektur / Qualität
■ Zusätzlich: Qualitätsschulden verursachen Zinsen (Folgekosten):
■Neue Features / Fehlerbehebung werden teurer
■Kosten für Betrieb steigen
■Testfälle müssen geändert werden
■ Beobachtung: Fehlerkosten steigen überlinear
zur Dauer zwischen Fehlerursache und Behebung
■Daher: Frühzeitig erkennen und beheben

4. 4
Keine zerbrochenen Fensterscheiben akzeptieren!
QAware20. Juni 2017

5. Das Konzept der Qualitätsschulden ist nicht neu. Bestehende
Ansätze ignorieren aber oft dynamische Aspekte.
6
■ Basis der gängigen Qualitäts(schulden)messung: Statische Metriken
■existierende Tools wie SonarQube fokussieren auf statische Metriken
■diese sind Ieicht zu erheben
■es gibt viel Erfahrung bei Darstellung
■wenige dynamische Kennzahlen (Ausnahme Testüberdeckung)
■ Aber: Statische Code-Eigenschaften reichen nicht, denn dynamische Indikatoren beeinflussen
■Kundenzufriedenheit
■Betriebs- und Infrastrukturkosten
Hier verstecken sich oft die harten Fälle der Wartbarkeit
(Hinweise auf schwer sichtbare Abhängigkeiten oder Leaks)

6. Wir wollen auch dynamische Indikatoren berücksichtigen.
Die gute Nachricht: Die Daten gibt es häufig schon.
7
■ Dynamische Indikatoren entstehen durch Ausführung eines Systems und sind zum Beispiel:
■Veränderung in Performance
■Ausführungsdauern von Methoden, Services
■Speicherverbrauch
■…
■ Daten dafür liegen in den meisten Projekten vor. Zum Beispiel
■Ausführungsdauer oder Speicherverbrauch von Tests
 entstehen z.B. bei jedem Build
■Performance-Kennzahlen in Test und Betrieb
 entstehen z.B. als Logfiles oder Protokolle

7. Die Anforderungen an Erfassung und Visualisierung stehen im
Konflikt mit existierenden Unterstützungen.
9
■ Benötigte Eigenschaften der Messdaten
■feingranulare Erfassung (z.B. bis auf Methodenebene)
■Speicherung der Historie
■Unterstützung von gemischten Zeitpunkten: Messpunkte zu Metriken fallen zu unterschiedlichen
Zeitpunkten an (Build, Unittest, Laufzeit)
■ Existierende Tools (z.B. SonarQube) reichen nicht aus:
■Messungen nur bis Dateiebene
■Historie nur auf Modul-/Paketebene verfügbar
■alle Metriken müssen zum gleichen Zeitpunkt gemessen werden

8. Beispiel: Ausführungsdauer von Tests
10
■ Ausführungsdauer von Tests ist ein Indikator für Qualitätsschulden
■Ursache—Wirkung: unbeabsichtigte Seiteneffekte führen zu Änderung an anderer Stelle
■die andere Stelle ist eine Testmethode z.B. in einem anderen Modul
■diese Daten fallen bei jedem Build an
■ Hinweise auf Qualitätsschulden können sein:
■langsames Wachsen über die Zeit
■Sprünge, die über die normale Fluktuation herausgehen
■lange Dauer der Tests (dann lässt man Tests oft weg)

9. Idee: Speicherung der Messdaten als Zeitreihen in einer
Zeitreihen-Datenbank
11
■ Pro Ressource + Metrik habe ich ein Zeitreihe
■Wichtige Fragen für Bewertung: Absoluter Wert zum Zeitpunkt t, Trend
■Wichtige Funktionen: Glättung, Ausreißer-Erkennung, Aggregation
z.B. Methode
Projekt
Modul
…
Klasse
Methode
Größe
Komplexität
Testausführungsdauer
Ressourcen-
Hierarchie
Ressource Metrik
Zeitreihen-(Datenbanken)
unterstützen diese
Anforderungen von Haus
aus!

10. Welche Zeitreihen-Datenbank? Chronix schlägt andere
Zeitreihendatenbanken in Indexgröße und Zugriffszeit
12
Chronix-Indexgröße: 30-70%
Chronix-Zugriffszeit: 12-25%

11. Chronix ist Open Source und unterstützt eine Reihe von
Datenquellen und Visualisierung.
13
Datenkollektoren
für unterschiedliche Quellen
Speicherung von Zeitreihen
als Solr-Dokumente für
- schnelle Suche
- Ausführung von Funktionen
- horizontal skalierbar
unterschiedliche Front-Ends
für Analyse und Visualisierung

12. 14
Fallbeispiel: Enterprise-Search Projekt mit Suchindex aus mehr
als 20 Systemen
Index
(Solr)
27 Sprachen
63 Mio. Objekte/Sprache
1,2 TB Index in 20 Cores
Einsatz weltweit
ca. 50.000 Nutzer
~150.000
Fahrzeuge/Woche
Logfiles:
~25 Mio Events/18 GB pro Tag
System A
System B
System C
System F
System M
System Z
Loader (ETL)
Index speist sich aus
> 10 Backendsystemen
Backendsysteme aggregieren
Daten aus > 30 Datenquellen
integriert zur Laufzeit
zusätzlich 10 Systeme

13. Idee: Daten einsammeln aus unterschiedlichen Quellen
15
Chronix
System
ETL
SVN
JIRA
…
SonarQube
Laufzeit
Datenversorgung
Build

14. Fallbeispiel: Messdaten seit Projektbeginn (7/2012)
16
■ Projekt läuft seit 7/2012 mit durchschnittlich 20 Mitarbeitern
■ Verfügbare Daten für diese Fallstudie:
■111 Metriken, ca. 8000 Klassen
■Seit Februar 2016: 61 Messpunkte (Februar 16 –Januar 17; Messungen mind. wöchentlich)
■zusätzliche Historie: 20 Messpunkte bis 2012 (seltenere Messungen zu Releases bzw. Sprints)
■Indexgröße der Zeitreihen-Datenbank: 240 MB (ca. 1 Mio. Zeitreihen-Dokumente)
■ Beispiel Testausführungsdauer
■wir betrachten folgende Regel: 15 Sek. Testausführungszeit sind kritisch
(die Messung erfolgt mit Branch Coverage; das verlangsamt die Testausführungsdauer um Faktor 3)

15. Grafana-Dashboard mit allen Daten zu Testausführung und
Sonar-Violations
17
Testausführungsdauern
seit 7/2012
Sonar-Violations
seit 7/2012
Sortierung und Auswahl
der Datenreihen
häufigere Messfrequenz ab
02/2016

16. Mit den eingebauten Möglichkeiten von Grafana kann man
bereits gut Anomalien sehen und untersuchen
18
3 von 3000 Testklassen
sind problematisch
Alarme bei Überschreitung
der Obergrenze von 15s
Man sieht ein Refactoring:
Zielvorgabe 0-Violations

17. Eine Zeitreihe zeigte hohe Varianz bei Testausführung. Den
Effekt des Refactorings kann man gut erkennen.
19
Beobachtungen mit einem ersten
Prototypen führten Mitte 2016 zu einem
Refactoring. Ursache:
Nichtdeterministisches Verhalten
(Timeout) bei einem eingebetteten Solr.

18. Auffälligkeiten bei der Testausführung: wachsender Trend
20
Zwei der Top-3 Methoden zeigen
einen wachsenden Trend, ohne
Änderungen im betroffenen Code.
Diese Anomalie wäre bei
Beobachtung leicht entdeckbar
gewesen, blieb aber unentdeckt

19. Auffälligkeiten bei der Testausführung: Sprung
21
Die Ursache ist im Commit
ersichtlich: Testfall verändert
Eine weitere Zeitreihe zeigt
einen deutlichen Sprung.

20. Weitere Ideen und Potential, das wir im nächsten Jahr angehen
wollen
22
■ Unterschiedliche Dashboards bzw. Widgets für unterschiedliche Testprofile:
■Unittest, Integrationstests, Performancetests, …
■Idee: Einen einfachen Performancetest in Nightly Build integrieren
■ Nutzung und Vergleich von Produktionsdaten
■Ausführungsdauern von Services:
Entwicklung über Produktivstände (z.B. Releases)
■Ausführungsdauern, Speicherverbrauch der ETL-Jobs
■ Weitere Datenquellen anbinden: SVN commits, JIRA
■in der Fallstudie haben wir Commits und Tickets manuell geprüft
■direkter Zugriff in einer Darstellung beschleunigt
Analyse und Ursachenerkennung

21. Fazit der Machbarkeitsstudie: Zeitreihen bieten einen Mehrwert.
23
■ Ziel war: Nutzung anfallender dynamischer Indikatoren als Zeitreihen sinnvoll?
■dazu haben wir einen Prototyp entwickelt, um Machbarkeit zu untersuchen und Potential zu erkennen
■ Wir sind davon überzeugt,
■ dass dynamische Indikatoren wichtig zu überwachen sind
■ dass viele dynamische & statische Indikatoren gut als Zeitreihe abbildbar sind
■ Die Frage war:
■ Gibt es bereits einen Nutzen bei einfachen Indikatoren wie Testausführungszeiten?
■ Lässt sich zeigen, dass eine Zeitreihendatenbank trägt?

22. Fazit der Machbarkeitsstudie: Nutzen.
24
■ Erste Erfolgte Refactorings wie z.B. Ausbau von Sonar-Violations, Refactoring von Tests oder
Komponenten-Upgrades (Java8, Glassfish4) sind sichtbar
■ Erkenntnisse bei Testausführungsdauern
■Der präzise Blick auf Ausführungsdauern ist wertvoll:
■Für das gesamte Projekt/Modul sieht alles gut aus.
(insgesamt benötigt das Projekt ca. 15 Min. im Build inkl. Tests bei Messung mit Branch Coverage)
■Erst beim Blick auf Methoden gibt es Auffälligkeiten.
■Mit dieser Machbarkeitsstudie wurden einige Auffälligkeiten und Langläufer-Tests entdeckt
■Spannend sind Trend-Verläufe, hohe Variationen oder Sprünge, die mit einer Zeitreihen-Datenbank
direkt und lokal auf Zeitreihen erkannt und als z.B. Alarm gemeldet werden können.
■Potential: Nutzung von Zeitreihen-Funktionalität

23. Umsetzungskosten für den Prototypen sind niedrig. Wir haben
anfallende Daten in Zeitreihe gepackt und gespeichert.
27
Chronix
Grafana
Chronix-Konnektor
Importer
Elastic Search
SonarQube
…
Importer
Entwickeln mussten
wir lediglich
Datenimport nach
Chronix
…sowie kleine
Anpassungen am Grafana-
Konnektor für Chronix
Chronix gab es auch schon
Die Mess-Infrastruktur im
Projekt gab es schon

24. Zusammenfassung
29
■ Bewertung von Qualitätsschulden benötigt auch dynamische Kennzahlen
■oft harte Fälle der Wartbarkeit (Hinweise auf schwer sichtbare Abhängigkeiten oder Leaks)
■ Dynamische Kennzahlen fallen oft an, werden aber nicht genutzt
■Build, Logfiles
■ Messdaten für Qualitätsschulden sind Zeitreihen
■pro Metrik und Ressource
■mit unterschiedlicher Frequenz
■ Speicherung in Zeitreihen-Datenbank auf Solr-Basis als Data-Lake ist ein vielversprechender
Ansatz
■Integration mit Datensammlung und unterschiedlichen Visualisierungs-/Analysewerkzeugen
■skalierbar für große Datenmengen

25. 30