DevOps / Software-Entwicklung / Software-Test / Test Center / Testautomatisierung / Testmanagement

Continuous Quality – Schärfen der Softwarequalität

Ein Softwareentwicklungsprozess ist mehr als Continuous Integration und Deployment, denn auch die Qualitätssicherung muss als kontinuierlicher Bestandteil darin integriert werden. Testmaßnahmen müssen häufiger und gezielter gesetzt werden. Das führt zu Herausforderungen, welche durch ein entsprechendes Konzept gelöst werden können. Dabei kommen neben Continuous Integration und Deployment noch weitere Werkzeuge zum Einsatz. Der Beitrag erklärt die Grundidee, das Vorgehen und das daraus resultierende Grundkonzept von Continuous Quality um die Softwarequalität zu schärfen.

Softwareentwicklungsabteilungen werden oft als Softwareschmieden bezeichnet. Nehmen wir an, dass eine solche Schmiede ein edles Schwert herstellt, so liegt es nahe, die Qualitätssicherung als das „Schärfen“ jenes Schwertes zu sehen.

Wir wissen, dass ein Schwert nur durch viele, kontinuierlich wiederholte Arbeitsgänge rasiermesserscharf gemacht werden kann. Doch wir übersehen häufig, dass dies auch für die Qualität der Software gilt, analog zu unserm Beispiel des Schwertes. Wollen wir also die Qualität schärfen wie ein edles Schwert, so müssen wir an mehr als nur einen Arbeitsschritt und somit auch mehr als nur eine Testphase denken.

Bildlich gesprochen bedeutet das, dass wir ein Vorgehen vom groben Schliff bis hin zur feinen Politur unserer Software benötigen. Dazu müssen wir alle Werkzeuge gekonnt in den Softwareentwicklungsprozess einbinden, so dass die Software durch kontinuierliches Testen und weitere qualitätssichernde Mechanismen, immer wieder über den Schleifstein gezogen und somit verbessert wird. Und dadurch, wie ein Schwert, wertvoller und besser wird.

 

Kontinuierliches Wiederholen – Das Schleifen

Continuous Integration, Delivery und Deployment sind fixe Bestandteile von modernen Softwareentwicklungspraktiken, wie auch in der Form von zentralen Elementen in DevOps. Sie ermöglichen erst das schnelle und effektive Arbeiten der Entwickler. Darum ist es wichtig, dass die Qualitätssicherung ebenso agiert und durch kontinuierliches Testen die Qualität immer weiter schärft. Also sprechen wir, analog zu Continuous Integration, Deployment und Delivery von einem Continuous Quality Ansatz.

Testmaßnahmen werden dabei in mehreren Ebenen des Softwareentwicklungsprozesses festgelegt und verankert, um mit den Ansprüchen moderner Softwareentwicklung mithalten zu können.

Testen muss gezielt und vor allem kontinuierlich durchgeführt werden, wobei neben Tests neuer Features, häufige Regressionstests über bereits getestete Softwareteile durchzuführen sind, um Regressionen und ungewollte Veränderungen aufzudecken.

Dies ist in schnellen und inkrementellen Umfeldern, wie DevOps oder auch bei agiler Softwareentwicklung, manuell nicht realisierbar und Testautomatisierung kommt zum Einsatz. Solche automatischen Qualitätssicherungsmechanismen können in unterschiedlichen Ausprägungen an verschiedenen Stellen im Prozess eingesetzt werden.

 

Das Vorgehen – vom groben Schliff bis zur Politur

Continuous Quality ist nicht nur das Erstellen eines automatisierten nächtlichen Testlaufs, sondern auch das Einrichten weiterer automatisierter Qualitätssicherungsmaßnahmen durch den gesamten Softwareentwicklungsprozess hindurch. Denn auch beim Schärfen eines Schwertes wird nicht nur ein einzelner Schleifstein verwendet.

So beginnt der grobe Schliff schon mit den Unittests und Komponentenintegrationstests. Diese werden von den Entwicklern erstellt und sollten schon am Anfang des Prozesses kontinuierlich durchgeführt werden. Am besten werden diese also bei jedem Check-In bzw. Push des Codes in das zentrale Repository als Teil des Continuous Integration Ablaufs ausgeführt.

Somit wird in der CI nicht nur die Software gebaut, sondern auch schon grob in ihren Komponenten durch die Entwicklertests getestet. Oft macht es Sinn, ein Check-In oder Push in das zentrale Repository erst nach bestandenen Unittests zuzulassen, um die Qualität im Repository zu sichern.

Nun haben wir eine paketierbare und in den Komponenten getestete Software, die in verschiedenen Testumgebungen eingespielt werden kann. Hier kommen weitere Werkzeuge zum Einsatz:

Provisioning

Ist das Vorgehen zur Erstellung bzw. zum Einrichten einer Umgebung. Dies kann bereits automatisiert und in der jeweilig benötigten Konfiguration der Teststufe ausgeführt werden. Ebenso ist es möglich Testumgebungen “on demand” in Form von Containern zu erstellen, so dass diese nach dem erfolgreichen Build der Software automatisch erstellt und hochgefahren werden. Danach wird das System im Test eingespielt sowie getestet. Schlussendlich wird der Container wieder heruntergefahren.

Test-Environment-Management

Ist die übergeordnete Verwaltung der Testumgebungen in ihrem Umfang und Nutzen in der gesamten Prozesskette. Ein Beispiel einer typischen Struktur, die sich an den jeweiligen Teststufen orientiert, ist:

  • 1.Ebene – Development: Software wird mit den neuesten Änderungen am Code eingespielt und in den Komponenten, Schnittstellen, sowie wichtigsten fachlichen Anforderungen getestet.
  • 2.Ebene – Test: Hier eingespielte Software wird durch Tester und vor allem automatisierten Tests funktionell genauestens gegen die Anforderungen geprüft.
  • 3.Ebene – Pre-Production: Diese Testumgebung entspricht so gut wie möglich der echten Produktionsumgebung und dient den Abnahmetests durch den Betrieb bzw. Fachbereich.

Wir haben nun einen durch Continuous Integration erstellten Build inklusive durchgeführter Unittests und ein automatisches Deployment in einer ebenso automatisch erstellten Testumgebung. Damit wir nun die Testebenen schnell durchlaufen und Tests mit jedem Build immer wieder in selber Qualität durchgeführt werden können, benötigen wir in den Ebenen eine Testautomatisierung von Schnittstellen und UI Tests.

Damit dies auch schon in Ebenen wie zum Beispiel Development möglich ist, wo noch nicht alle Komponenten, Daten sowie benötigten Services zur Verfügung stehen, werden zusätzlich folgende Werkzeuge verwendet:

Testdatenmanagement

Dieses wird eingesetzt, um Testdaten in der jeweiligen Testebene bereitzustellen. Dies kann durch einen Abzug und Anonymisierung von Produktivdaten geschehen oder durch synthetische Erstellung. Auch Mischformen beider Varianten sind möglich.

Service Virtualisierung

Durch Simulation von Services, sind Tests dieser Serviceschnittstellen schon in Testebenen möglich, in denen die betroffenen Services selbst noch nicht zur Verfügung stehen. Dies minimiert die Fehler in späteren Testebenen, wo das reale Service integriert wird und reduziert somit die Probleme und Kosten spät entdeckter Fehler in der Software.

Da nun in jeder Ebene automatisiert getestet wird, benötigen wir eine Möglichkeit den gesamten Prozess auch zu überwachen. Das funktioniert über Monitoring-Tools, welche alle Systeme sowie Build- und Deployment-Ergebnisse abgreifen und überwachen.

Darüber hinaus ist es meist notwendig eine weitere Testebene für Last und Performanz-Tests einzuplanen und entsprechende Tests der nicht-funktionalen Anforderungen an Lastbeständigkeit und Performanz durchzuführen.

Mit all diesen Werkzeugen ist es nun möglich ein Konzept umzusetzen, welches die Qualität der Software vom Build über die Testebenen, bis in die Produktion schärft und sicherstellt.

 

Das Konzept – Schärfen durch Continuous Quality

Wie die zuvor beschriebenen Werkzeuge im Detail eingesetzt werden hängt von mehreren Faktoren ab. Darunter die Art des Softwareentwicklungsprozesses, die Architektur der Software und das Testkonzept an sich. Wichtig dabei ist, dass das Schärfen der Qualität, durch mehrere Stufen kontinuierlich durchgeführter Testmaßnahmen, fest in den Softwareentwicklungsprozess integriert und zum überwiegenden Teil automatisiert wird.

Damit ist es möglich eine voll automatisierte Softwareentwicklungsprozesskette zu erschaffen, welche in der Grundidee wie folgt verläuft:

  1. Der Entwickler stellt seine Änderung am Code fertig und checkt sie ein bzw. pusht diese in das zentrale Repository
  2. Der Build-Prozess wird durch das Check-In bzw. den Push automatisch gestartet, baut die Software und führt alle Unit-Tests und Entwickler-Integrations-Tests aus.
  3. Nach bestandenen Tests wird die Software in der Development-Umgebung eingespielt und mit automatisierten Schnittstellen- und Smoke-Tests in ihren Komponenten getestet.
  4. Sind auch diese Tests fehlerfrei, so wird das Softwarepaket automatisch auf die Test-Umgebung eingespielt, wo alle automatisierten Schnittstellen, Integrationstests und UI-Tests aller Features durchgeführt werden.
  5. Waren alle Tests der Vorstufen erfolgreich, so wird die Software auf der Pre-Production-Umgebung ausgerollt und steht somit für die (potentiell ebenfalls automatisierten) Abnahmetests durch den Betrieb bzw. Fachbereich zur Verfügung.
  6. Sind auch diese Abnahmetests abgeschlossen, wird die Änderung auch im Produktionssystem eingespielt und ist somit produktiv.

 

In allen Testebenen kommen dabei Provisionierung, Testdatenmanagement und Service Virtualisierung zum Einsatz. Zusätzlich können noch Last- und Performanz-Tests automatisiert ausgeführt werden.

Mit dieser Konzeptidee kann jeder Prozess durch Continuous Quality erweitert und verbessert werden. Im Falle von DevOps, wird erst durch Continuous Quality das Optimum der DevOps-Idee erreicht: Eine schnelle, effiziente und dabei qualitativ hochwertige Entwicklung von Software.

DevOps ist also mehr als Continuous Integration und Deployment. Es besteht zusätzlich aus Provisioning, Test-Environment-Management, Testautomatisierung, Service Virtualisierung, Testdatenmanagement, Last- und Performanz-Tests, sowie Monitoring.

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*