Fitch bietet hohe Codeabdeckung und Qualität für Microservices-Anwendungen

Sehen Sie sich eine Vorschau der Fitch-Präsentation auf dem kürzlich stattgefundenen Automated Software Testing & Quality Summit an. Erfahren Sie, wie sie Abhängigkeiten für >200 Microservices verwaltet und die Codeabdeckung mit Komponententests erhöht hat.

VOLLSTÄNDIGE PRÄSENTATION HIER VERFÜGBAR >>

Die Herausforderungen

Fitch hatte drei Hauptprobleme zu lösen:

• Ungeplante Ausfallzeiten
• Fehlendes Feedback für Entwickler
• Starre zweiwöchige Release-Zyklen

Ungeplante Ausfallzeiten

Im Jahr 2019 hatte Fitch 18 Vorfälle, die dazu führten, dass ihre Website aufgrund von Störungen in der Produktionsumgebung ausfiel. Diese ungeplanten Ausfälle bezogen sich entweder auf ihre eigenen APIs oder andere Produkte, die sie hosten. Achtzehn Vorfälle durchschnittlich mehr als einmal im Monat. Das sind schlechte Nachrichten für die Service Level Agreements (SLA) und ihre Kunden.

Fehlendes Feedback für Entwickler

Das Softwareentwicklungsteam bei Fitch Solutions ist fließend. Entwickler wechseln von Projekt zu Projekt, daher ist es üblich, dass sie an ihnen unbekannten Microservices arbeiten und dafür verantwortlich sind. Das Hinzufügen von Funktionen zu unbekanntem Code war schwierig, da es nur eine geringe Anzahl von Tests gab, um Ergebnisse zu liefern und Entwicklern zu helfen, das erwartete Verhalten zu verstehen. Darüber hinaus standen Fachexperten (KMU) häufig nicht zur Verfügung.

All diese Faktoren zusammengenommen – Entwickler wechselten häufig das Team, hatten keinen Zugang zu KMU und hatten eine geringe Testabdeckung von etwa 20 % – führten zu einem Mangel an Feedback. Die fehlenden Informationen behinderten die Fähigkeit des Teams, die Dienste am Laufen zu halten und neue Funktionen hinzuzufügen. Aus diesem Grund hat Fitch Maßnahmen ergriffen, um eine höhere Testabdeckung zu erreichen.

Starre zweiwöchige Veröffentlichungszyklen

Zwei Wochen Release-Zyklen sind der Standard-Entwicklungsprozess bei Fitch. Entwickler konnten nicht nach ihrem eigenen Zeitplan veröffentlichen. Wenn die Entwicklung eines neuen Features also vor dem Ende des Bereitstellungszyklus abgeschlossen war, musste es bis zum Ende des Sprints warten, um zur QA überzugehen. Im Idealfall mussten sie in der Lage sein, ein Feature zu entwickeln und bereitzustellen, wenn es implementiert und getestet wurde. Dies würde es ihnen ermöglichen, häufiger neue Funktionen zu veröffentlichen und ihre Markteinführungszeit zu verkürzen.

Die Vorgehensweise

Fitch Solutions betrachtete diese drei großen Herausforderungen und suchte nach einem gemeinsamen Nenner für alle drei. Es stellte sich heraus, dass alle drei mit fehlenden Tests zusammenhingen, was zu einer schlechten Codeabdeckung führte. Sie beschlossen, die Codeabdeckung zu erhöhen, um sicherzustellen, dass sie ihre Microservices vollständig testen und ihren Entwicklern dabei helfen, besseren Code schneller bereitzustellen.

Eine gute Codeabdeckung auf einem Microservice bedeutet, dass die meisten, wenn nicht alle Pfade durch den Code ausgeführt werden. Das Erstellen einer Testsuite für jeden Microservice, die alle verschiedenen Funktionen abdeckt, bedeutet, dass Clients keinen ungetesteten Code offenlegen. Bei zukünftigen Änderungen geben automatisierte Regressionstests Entwicklern sofortiges Feedback, ob etwas im Code defekt ist.

Dieser Ansatz reduziert schließlich Ausfälle. Es ist effektiver und effizienter, aktuelle und neue Funktionen zu testen, bevor sie in die Produktion gehen. Dieser Ansatz half Fitch Solutions, die Abhängigkeit von ihrer QA-Gruppe zu reduzieren, um neue Funktionen bereitzustellen und zu testen und die Funktionsentwicklung vom zweiwöchigen Release-Zyklus zu entkoppeln.

Ein zweigleisiger Ansatz zur Erhöhung der Codeabdeckung

Der von Fitch Solutions entwickelte Plan bestand darin, eine 90%ige Unit-Test-Abdeckung (insbesondere Line-Abdeckung) zu erreichen. Dies war eine große Aufgabe, da sie über 200 Microservices haben! Das Team war der Herausforderung gewachsen und ging zweigleisig vor.

Erstellen Sie viele neue Tests

Der erste Ansatzpunkt des Ansatzes bestand darin, die Testabdeckung des gesamten vorhandenen Codes rückwirkend zu erhöhen. Um das Ziel der Codeabdeckung von 90 % zu erreichen, mussten viele neue Tests erstellt werden. Dafür haben sie ein engagiertes Team zusammengestellt. Das Team war dafür verantwortlich, Unit-Tests ausschließlich zu schreiben, um die Codeabdeckung aufzubauen und die bestehenden Microservices von Fitch Solutions vollständig zu testen.

Befolgen Sie die Richtlinien für Unit-Tests

Der zweite Aspekt dieses Ansatzes bestand darin, sicherzustellen, dass Entwickler, die neue Funktionen schreiben, die Richtlinien für Komponententests befolgen und die Ziele der Codeabdeckung erreichen, wenn neuer Code geschrieben wird. Diese Richtlinien wurden im gesamten Unternehmen angewendet, damit alle Entwickler sie in die Praxis umsetzen können. Das Team führte Quality Gates ein, um die Qualität des Codes sicherzustellen, der mit dem Hauptproduktionszweig zusammengeführt wurde.

Einführung eines integrierten Java-Testtools zur Erreichung der Ziele

Um ihre Test-, Abdeckungs- und Qualitätsziele zu erreichen, hat Fitch Solutions eingeführt Parasoft Jtest. Sie fanden es besonders nützlich, sowohl die Code-Coverage-Funktionen als auch die Unit Test Assistent in Parasoft Jtest. Wenn die Entwickler neue Funktionen schrieben oder Legacy-Dienste erneut testeten, maßen sie zuerst die Codeabdeckung, um zu beurteilen, wie umfangreich die bestehenden Tests waren. Sie verwendeten die Code-Coverage-Berichte von Jtest auf allen verschiedenen Ebenen, um herauszufinden, wo ihre Tests mangelhaft waren, einschließlich der Untersuchung fehlender Coverage auf Datei- und Codezeilenebene.

Der Unit Test Assistant half Fitch Solutions, die Lücke bei Unit-Tests zu schließen. Entwickler erstellten neue Komponententests mit einem Klick auf eine Schaltfläche, während sie den Mauszeiger über eine Methode im Code bewegten. Der Unit Test Assistant erstellt nach Bedarf eine Testdatei, einen Kabelbaum und Stubs/Mocks. Entwickler fügen einfach Assertionen hinzu, um das Verhalten zu überprüfen und Mocks anzupassen, und ein neuer Komponententest ist fertig.

Das gesamte Team beschleunigte die Erstellung und Durchführung von Tests mit Parasoft Jtest. Es war besonders hilfreich für ihre Junior-Entwickler, die eine Anleitung zur Erstellung von Komponententests benötigten.

Lösungsvorteile

Fitch Solutions ist immer noch auf dem Weg, ihre Softwaretests zu verbessern. Sie profitieren bereits von ihrer Parasoft-Lösung.

• Eine zuverlässige Methode zum Messen und Verbessern der Codeabdeckung.
• Beschleunigte Erstellung und Wartung von Komponententests.
• Reduzierte Ausfallzeiten.
• Erhöhte Entwicklerproduktivität.

Die Ergebnisse

Bis zum dritten Quartal 3 verbesserte Fitch Solutions das Testen von 2020 % der Microservices auf das Ziel einer Codeabdeckung von 10 %. Obwohl sie noch auf dem Weg sind, ihre Abdeckungsziele zu erreichen, haben sie 90 Tage ohne Ausfallzeiten in ihrem Produktionssystem verbracht. Es ist ihre längste Serie seit der Einführung ihres neuen Unit-Testing-Ansatzes. Vince Recupito, Senior Software Engineer bei Fitch Solutions, sagte: „Das Spannende daran ist, dass wir 100 Tage ohne Ausfallzeiten in unserem Produktionssystem verbracht haben. Etwas, das mehr als monatlich passierte.“

Fitch Solutions hat mit einem Drittanbieter zusammengearbeitet, der sich auf die Messung der Entwicklerproduktivität spezialisiert hat. Die eingehende Analyse verwendet direkten Zugriff auf Code-Repositorys, um den Commit-Verlauf zu messen und Trends und Metriken basierend auf Entwickleraktivitäten zu finden.

Das obige Diagramm wurde aus den gesammelten Produktivitätsdaten erstellt, die die monatliche durchschnittliche Zeit zeigen, die Entwickler pro Tag mit dem Schreiben von Code verbringen.

Die Daten zeigen, dass Fitchs Team etwa zwei Stunden pro Tag damit verbrachte, nur auf einer Tastatur zu tippen und Code zu schreiben. Der Einbruch im Januar wird voraussichtlich auf Feiertage zurückzuführen sein. Der interessante Teil ist der Beginn ihrer neuen Testbemühungen im Juli.

Zu diesem Zeitpunkt ging das Team seine Legacy-Microservices durch, evaluierte und erhöhte die Codeabdeckung. Es ist auch der Punkt, an dem das Team darauf bestand, dass alle neuen Funktionen ordnungsgemäß getestet werden.

Nach diesem ersten Einbruch war das Team wieder mit der Codeentwicklung beschäftigt, und zwar mit einer um 12 % höheren Rate als im gleichen Zeitraum im Jahr 2019. Dies war ein gutes Zeichen, da die Entwickler mehr Zeit mit dem Programmieren und weniger Zeit mit Meetings verbrachten. Die Hauptursache für diese Produktivitätssteigerung war jedoch die deutliche Verringerung der Ausfallzeiten der Produktionssysteme.

„Eine der Schlussfolgerungen, die wir ziehen, ist, dass unsere Entwickler weniger Zeit damit verbringen, Produktionsprobleme zu beheben und mehr Zeit mit dem Schreiben von Code verbringen. Darüber hinaus finden die Entwickler, während die Entwickler immer mehr Tests schreiben, hoffentlich früher Fehler, bevor sie mit der QA beginnen.“

—Vince Recupito, Senior Software Engineer bei Fitch Solutions

Fitch Solutions verzeichnete nicht nur eine Reduzierung der Ausfallzeiten von Produktionssystemen, sondern auch eine Reduzierung der „Brandbekämpfung“ der Entwickler, um Produktionsprobleme zu lösen. Darüber hinaus hatte das neue Testregime mit einer beobachteten Produktivitätssteigerung von 12% nur geringe Auswirkungen auf die Entwicklerproduktivität.

Zusätzlich zu diesen Gewinnen schreiben die Entwickler von Fitch Solutions weitere Tests und finden Fehler früher, bevor sie mit der QA beginnen. Fehler früher zu finden bedeutet auch weniger Hin und Her bei der QA und insgesamt weniger Zeit im QA-Prozess.