Abstracts

Ist CI/CD (Continuous Integration/Continuous Development) aus der Perspektive des Testers ein Segen oder ein Fluch? Der Vortrag beleuchtet Herausforderungen, die diese moderne Entwicklungsmethode mit sich bringt und stellt Konzepte dar, wie man sie als Tester, Testmanager oder Projektverantwortlicher meistern kann.

Viele Teams setzen bereits CI/CD erfolgreich ein und generieren regelmäßige (e.g. nächtliche) Builds, die automatisiert getestet werden. In vielen Fällen aber beschränken sich die Tests auf Unit- und Modul-Tests oder die Reports daraus sind nur für ein paar Stakeholder-Gruppen direkt verwendbar (e.g. beteiligte Entwickler/Tester). Um die Erkenntnisse der Reports anderen Stakeholdern (e.g. Managern) zur Verfügung zu stellen oder um andere Aspekte des Prüflings zu verifizieren (e.g. System Tests), muss man nachträglich die Reports entsprechend aufbereiten oder eine langwierige Test-Phase nach den CI/CD-Iterationen durchführen.

Dies hat mindestens zwei Probleme zur Folge. Zum Einem baut man Engpässe und Flaschenhälse ein: Ergebnisse der CI/CD-Iteration müssen erst von einer kleinen Gruppe bewertet werden. Zum anderen werden manche Fehler viel zu spät entdeckt: bei den nachgelagerten Systemtests. Auf Dauer führen solche Konstellationen dazu, dass größere Test-Lücken entstehen (Produkt-Risiken) und die Entwicklungszeiten unberechenbarer und länger werden (Time to market). Diese Themen sind besonders schwerwiegend bei Embedded-Software-Entwicklungen.

Darum ist es notwendig, dass eine CI/CD-Iteration (e.g. ein nächtliches Build) alle relevanten Software- und System-Qualitätsthemen berücksichtigt und sie für alle Stakeholder automatisiert aufbereitet. Das beinhaltet u.a. die Durchführung aller Test-Stufen, Aussagen über Coverage und Maturity sowie automatisierte stakeholder-gerechte Berichte. Dabei müssen Themen wie der Umgang mit bereits gemeldeten Fehlern oder mit sporadischen Findings und unausgereiften Tests adressiert werden. Für die Tests der Oszilloskop-Software bei Rohde & Schwarz haben wir ein Konzept implementiert, das viele der oben genannten Themen umsetzt.

Im Rahmen unserer nächtlichen Builds werden sowohl Unit- und Simulationstests als auch System-Tests on Target mit Hardware-Einsatz durchgeführt. Wir aggregieren die Ergebnisse und stellen automatisiert allen Stakeholdern einen Bericht zur Verfügung, der alle für uns wichtigen Fragen beantwortet. Zu diesen Fragen gehören:

• Was wurde im Vergleich zur vorigen Iteration (e.g. nightly Build) geändert – Sowohl beim Prüfling als auch im Test-System?
• Wie gut ist der Prüfling insgesamt? Wofür wäre er gut genug? Wo liegen die Probleme?
• Wie sehen die Details zu den Fehlern (Bilder, Skripte…) aus? Ist der Fehler neu, sporadisch oder bereits in Bearbeitung?
• Wie hat eine bestimmte Funktionalitätsgruppe insgesamt performt?
• Welche Anforderungen werden wie getestet? Welche Lücken sind sichtbar?

Unser Test-System sieht eine Architektur vor, die die Test-Durchführung in Phasen modelliert:

1. Alle Test-Tools und Test-Stufen reporten ihre Ergebnisse in einer Test-Ergebnis-Datenbank (Elastic Search DB).
2. Eine umfangreiche Post-Processing Schicht, als Python-module implementiert, bietet Funktionalitäten an, um die Daten in der Datenbank zu sichten, analysieren, aggregieren und entsprechend der Fragestellung, zu reporten
3. Die nächtlichen Reports verstehen sich als Snapshots für die aktuellen Iterationen und als Berichtswesen für alle Stakeholder: Entwickler, Tester, Projektleiter, Teamleiter, Kundenbetreuer …

Neben der Test-Durchführung mussten auch beim Test-Design Vorkehrungen getroffen werden. So bekommen alle Test-Fälle system-weit eindeutige IDs, die auch mit den Anforderungen im Test referenziert werden. Die Test-Ergebnisse beinhalten auch Zweck, Erwartung und Einstellung für die jeweiligen Testfälle.

Der Vortrag wird die Stakeholder, die Interesse an die Qualitätsdaten haben, und ihre typischen Fragestellungen einzeln durchleuchten. Außerdem wird der Vortrag die Umsetzung von CI/CD aus der Software-Qualitätsperspektive betrachten. Dies wird die Herausforderungen sichtbar machen, die gemeistert werden sollen, wenn wir die Stakeholder-Fragen beantworten, kleinere Produktrisiken und kürzere Time-To-Market gewährleisten wollen. Anschließend wird der Vortrag analysieren, welche Antwortmöglichkeiten es für diese Herausforderungen gibt und sie mit unserer Implementation aus Rohde & Schwarz illustrieren.