SlideShare ist ein Scribd-Unternehmen logo
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
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?
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
Keine zerbrochenen Fensterscheiben akzeptieren!
QAware20. Juni 2017
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)
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
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
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)
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!
Welche Zeitreihen-Datenbank? Chronix schlägt andere
Zeitreihendatenbanken in Indexgröße und Zugriffszeit
12
Chronix-Indexgröße: 30-70%
Chronix-Zugriffszeit: 12-25%
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
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
Idee: Daten einsammeln aus unterschiedlichen Quellen
15
Chronix
System
ETL
SVN
JIRA
…
SonarQube
Laufzeit
Datenversorgung
Build
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)
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
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
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.
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
Auffälligkeiten bei der Testausführung: Sprung
21
Die Ursache ist im Commit
ersichtlich: Testfall verändert
Eine weitere Zeitreihe zeigt
einen deutlichen Sprung.
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
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?
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
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
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
30

Weitere ähnliche Inhalte

Ähnlich wie Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - Eine Machbarkeitsstudie

DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
QAware GmbH
 
Swk vortrag metriken
Swk vortrag metrikenSwk vortrag metriken
Swk vortrag metriken
Alexander Michehl
 
Cloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniertCloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniert
QAware GmbH
 
Web Analytics Day bvh Multivariates Testen (2010-10-26)
Web Analytics Day bvh  Multivariates Testen (2010-10-26)Web Analytics Day bvh  Multivariates Testen (2010-10-26)
Web Analytics Day bvh Multivariates Testen (2010-10-26)
ro11 GmbH
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
Ernest Wallmueller
 
2015 alfresco-day-vienna rechnungshof
2015 alfresco-day-vienna rechnungshof2015 alfresco-day-vienna rechnungshof
2015 alfresco-day-vienna rechnungshof
Alfresco Software
 
Die Macht der Zahlen
Die Macht der ZahlenDie Macht der Zahlen
Die Macht der Zahlen
Gerrit Beine
 
Risikomanangement in der Entwicklung
Risikomanangement in der EntwicklungRisikomanangement in der Entwicklung
Risikomanangement in der Entwicklung
suxeo gmbh
 
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Torsten Kleiber
 
Mit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managenMit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managen
Christoph Schmiedinger
 
Fallstudie Usability-Test FH Münster
Fallstudie Usability-Test FH MünsterFallstudie Usability-Test FH Münster
Fallstudie Usability-Test FH MünstereResult_GmbH
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
Tobias Schlüter
 
Steigern Sie die Effizienz beim Testen Ihres S/4HANA-Systems
Steigern Sie die Effizienz beim Testen Ihres S/4HANA-SystemsSteigern Sie die Effizienz beim Testen Ihres S/4HANA-Systems
Steigern Sie die Effizienz beim Testen Ihres S/4HANA-Systems
panayaofficial
 
Design od Experiment - Zeit und Sicherheit gewinnen
Design od Experiment - Zeit und Sicherheit gewinnenDesign od Experiment - Zeit und Sicherheit gewinnen
Design od Experiment - Zeit und Sicherheit gewinnen
Ralf Becker
 
Devops
DevopsDevops
Devops
inovex GmbH
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Digicomp Academy AG
 
Vorgehensmodelle - Methoden der Wirtschaftsinformatik
Vorgehensmodelle - Methoden der WirtschaftsinformatikVorgehensmodelle - Methoden der Wirtschaftsinformatik
Vorgehensmodelle - Methoden der Wirtschaftsinformatik
Claus Brell
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
René Spengler
 
BrightTag DAALA Berlin
BrightTag DAALA BerlinBrightTag DAALA Berlin
BrightTag DAALA Berlinluna-park GmbH
 
Strukturierte problemloesung mit datenunterstuetzung
Strukturierte problemloesung mit datenunterstuetzungStrukturierte problemloesung mit datenunterstuetzung
Strukturierte problemloesung mit datenunterstuetzung
Minitab, LLC
 

Ähnlich wie Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - Eine Machbarkeitsstudie (20)

DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
 
Swk vortrag metriken
Swk vortrag metrikenSwk vortrag metriken
Swk vortrag metriken
 
Cloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniertCloud Migration – Eine Strategie die funktioniert
Cloud Migration – Eine Strategie die funktioniert
 
Web Analytics Day bvh Multivariates Testen (2010-10-26)
Web Analytics Day bvh  Multivariates Testen (2010-10-26)Web Analytics Day bvh  Multivariates Testen (2010-10-26)
Web Analytics Day bvh Multivariates Testen (2010-10-26)
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
 
2015 alfresco-day-vienna rechnungshof
2015 alfresco-day-vienna rechnungshof2015 alfresco-day-vienna rechnungshof
2015 alfresco-day-vienna rechnungshof
 
Die Macht der Zahlen
Die Macht der ZahlenDie Macht der Zahlen
Die Macht der Zahlen
 
Risikomanangement in der Entwicklung
Risikomanangement in der EntwicklungRisikomanangement in der Entwicklung
Risikomanangement in der Entwicklung
 
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017
 
Mit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managenMit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managen
 
Fallstudie Usability-Test FH Münster
Fallstudie Usability-Test FH MünsterFallstudie Usability-Test FH Münster
Fallstudie Usability-Test FH Münster
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
Steigern Sie die Effizienz beim Testen Ihres S/4HANA-Systems
Steigern Sie die Effizienz beim Testen Ihres S/4HANA-SystemsSteigern Sie die Effizienz beim Testen Ihres S/4HANA-Systems
Steigern Sie die Effizienz beim Testen Ihres S/4HANA-Systems
 
Design od Experiment - Zeit und Sicherheit gewinnen
Design od Experiment - Zeit und Sicherheit gewinnenDesign od Experiment - Zeit und Sicherheit gewinnen
Design od Experiment - Zeit und Sicherheit gewinnen
 
Devops
DevopsDevops
Devops
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
 
Vorgehensmodelle - Methoden der Wirtschaftsinformatik
Vorgehensmodelle - Methoden der WirtschaftsinformatikVorgehensmodelle - Methoden der Wirtschaftsinformatik
Vorgehensmodelle - Methoden der Wirtschaftsinformatik
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
 
BrightTag DAALA Berlin
BrightTag DAALA BerlinBrightTag DAALA Berlin
BrightTag DAALA Berlin
 
Strukturierte problemloesung mit datenunterstuetzung
Strukturierte problemloesung mit datenunterstuetzungStrukturierte problemloesung mit datenunterstuetzung
Strukturierte problemloesung mit datenunterstuetzung
 

Mehr von QAware GmbH

Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
QAware GmbH
 
50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf
QAware GmbH
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
QAware GmbH
 
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN MainzFully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
QAware GmbH
 
Down the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile ArchitectureDown the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile Architecture
QAware GmbH
 
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
QAware GmbH
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
QAware GmbH
 
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit PlaywrightDer Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
QAware GmbH
 
Was kommt nach den SPAs
Was kommt nach den SPAsWas kommt nach den SPAs
Was kommt nach den SPAs
QAware GmbH
 
Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo
QAware GmbH
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
QAware GmbH
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
QAware GmbH
 
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
QAware GmbH
 
Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!
QAware GmbH
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
QAware GmbH
 
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAPKontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
QAware GmbH
 
Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.
QAware GmbH
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
QAware GmbH
 
Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.
QAware GmbH
 
Per Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API GatewaysPer Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API Gateways
QAware GmbH
 

Mehr von QAware GmbH (20)

Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
 
50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
 
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN MainzFully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
 
Down the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile ArchitectureDown the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile Architecture
 
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit PlaywrightDer Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
 
Was kommt nach den SPAs
Was kommt nach den SPAsWas kommt nach den SPAs
Was kommt nach den SPAs
 
Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
 
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
 
Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
 
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAPKontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
 
Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
 
Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.
 
Per Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API GatewaysPer Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API Gateways
 

Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - Eine Machbarkeitsstudie

  • 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