Der CTO von EMBIQ über Qualitätssicherung

Kann es sich lohnen, die Qualitätssicherung auszulassen? Das haben wir Bartek gefragt, den CTO von EMBIQ.

• Stimmt es, dass Qualität Geld kosten muss?

Bartek: Wenn wir wirklich wollen, können wir die Qualitätssicherung weglassen. Aber genau das kann uns teuer zu stehen kommen. In die Produktqualität investiertes Geld kommt doppelt zurück: erstens, weil es deutlich weniger Rückschläge gibt, und zweitens, weil das fertige Produkt viel zuverlässiger ist.

• Ist Geld das Einzige, was wir durch mangelnde Qualität verlieren können?

Bartek: Schlimmer noch: Unser Kunde kann seine eigenen Kunden verlieren. Wer nicht auf Qualität achtet, riskiert die Offenlegung oder den Verlust von Daten – mit der Folge, dass das Produkt nicht einsatzfähig ist und die Kunden es nicht richtig nutzen können. Wenn wir etwas für Endnutzer entwickeln, kostet das immer Geld. Oft ist ein solches Produkt ohne Qualitätssicherung nicht einmal veröffentlichungsreif. Kunden ist nicht immer bewusst, was Qualität ausmacht. Es zeigt sich, dass nicht nur die Entwicklungsphase selbst wichtig ist, sondern auch das, was danach kommt.

• Lohnt es sich, in Qualität zu investieren? Kann man diese Phase überspringen? Zahlt man später mehr?

Bartek: Das hängt davon ab, was wir erreichen wollen. Viele unserer Produkte basieren auf einer F&E-Phase mit wenigen oder gar keinen Tests. Bei Endprodukten, die in Produktion gehen oder veröffentlicht werden sollen, sollte man diesen Schritt aber nicht auslassen. Am Anfang sieht man es nicht, doch am Ende können Mängel auftauchen. Dann zeigt sich, dass das Produkt nicht stabil genug für die Veröffentlichung ist. Auf die Qualitätsphase kann man verzichten, wenn man zum Beispiel einen Prototyp bauen möchte.

• Welche Phasen hat die Qualitätssicherung von Software?

Bartek: Qualitätssicherung beginnt schon vor der Softwareentwicklung – mit einem gut ausgearbeiteten Produktkonzept, Funktionen, Architektur und Testfällen. Während der Entwicklung folgen dann Unit-Tests, automatisierte Tests, Integrationstests, manuelle Tests nach Szenarien und Monkey-Tests. Qualitätssicherung darf man aber nicht mit Testen verwechseln, denn zur Qualität gehört auch ein gut eingerichteter Entwicklungsprozess mit automatischer, kontinuierlicher Integration.

Der erste Schritt ist das Testdesign. Natürlich ist der Testumfang endlich – unsere Kapazitäten sind begrenzt. Wir müssen ein Konzept für die Tests entwickeln, so wie wir ein Konzept für Design oder Architektur entwickeln. Genauso muss in dieser Phase das Konzept für die Testdurchführung entstehen. Danach beginnen die ersten Tests. Wir nennen sie die „Use Cases“ eines Produkts – sie beschreiben, wie ein Nutzer die Anwendung verwendet. Das ist der erste Schritt zum Beispiel bei Webanwendungen, aber auch bei mobilen Apps, Geräten und in jedem anderen Bereich.

Nach diesem ersten Schritt folgt die zweite Phase der Produktentstehung, die Entwicklungsphase. Hier werden mehrere Arten von Tests durchgeführt. Je nach Art des Produkts oder Projekts versuchen wir meist, ein möglichst breites Spektrum an Tests aufzubauen. Wir beginnen mit Unit-Tests für einzelne Funktionen und ergänzen dann Integrationstests. Auch die Tester spielen in dieser Phase eine wichtige Rolle. Sobald eine Funktion fertig ist und in den Hauptzweig des Produkts einfließt, prüfen sie die Funktion in ihrer eigenen Umgebung, führen ihre Tests aus und testen manuell.

In der dritten Phase automatisieren und dokumentieren die Tester ihre Arbeit: automatisierte Tests, End-to-End-Tests und Tests der möglichen Benutzeroberfläche der Anwendung. Sie entstehen auf Basis detaillierter Testszenarien – was der Endpunkt des Produkts ist, wird automatisiert, damit sich diese Tests so früh wie möglich wiederholen lassen.

Bei Webanwendungen automatisieren wir zum Beispiel neben der Grundfunktion auch Tests der Programmierschnittstelle selbst (API).

• Wie sollte der Softwareentwicklungsprozess aussehen, um die beste Qualität zu sichern?

Bartek: Jede Änderung durchläuft eine statische Codeanalyse, Kennzahlen wie die Codeabdeckung durch Unit-Tests werden geprüft, der Code muss korrekt und ohne Beanstandungen kompilieren und dann einen vollständigen Zyklus automatisierter Tests bestehen. Erst danach prüft mindestens ein weiteres Mitglied des Entwicklungsteams die Änderung und nimmt sie an oder gibt sie zur Korrektur zurück, wenn ihm etwas Bedenkliches auffällt.

Der Prozess beginnt mit der Entwicklung selbst. Jeder neu geschriebene Codeabschnitt wird auf Qualität und Sicherheit geprüft. Die Prüfung erfolgt in 2 Stufen: Zuerst prüfen Teammitglieder den Code (eine in der jeweiligen Technologie führende Person bewertet die Codequalität). Dabei versuchen wir, den Prüfumfang möglichst breit zu halten – je mehr Personen beteiligt sind, desto leichter findet man einen Fehler. Die zweite Stufe ist die statische Analyse, die den Code auf Sicherheit, Stil und Format prüft. Für jedes Projekt richten wir eine lokale Umgebung ein, um mögliche Fehler so schnell und so früh wie möglich zu erkennen.

Zwischen diesen Prozessen laufen automatisierte Tests und API-Tests. Die automatisierten Tests starten, sobald eine Aufgabe abgeschlossen ist. Bevor die Tester Zeit in die Prüfung des Codes investieren, führen andere Teammitglieder automatisierte Integrationstests aus.

Das sind Standardschritte, mit denen wir die Qualität der Software, des erstellten Codes und seine Sicherheit sicherstellen.

Natürlich vergessen wir dabei nie den Kunden. Während der Testumsetzung bauen wir eine interne Umgebung und eine Zwischenumgebung für Abnahmetests auf – der Kunde hat Einblick in diese Phase, bevor die finale Version der Anwendung ausgerollt wird.

• Das klingt, als würde es ewig dauern.

Bartek: Nicht unbedingt. Ein gut eingerichteter und integrierter Prozess erledigt den Großteil der Arbeit auf Servern, auf denen diese Aufgaben parallel laufen. Selbst wenn es sich um Firmware für IoT-Geräte handelt, lässt sich der gesamte Prozess nach Bedarf anpassen. Außerdem wird jede Änderung so gründlich geprüft, dass sich alle umso mehr bemühen, den Prozess schon im ersten Durchlauf zu bestehen.

• Durchläuft jedes unserer Projekte ein so gründliches QA-Verfahren?

Bartek: Wir empfehlen es für jedes Projekt, wissen aber auch, dass es nicht immer sinnvoll ist. Wenn ein Projekt zum Beispiel in einer ersten Finanzierungsrunde entsteht und die technologischen Möglichkeiten für die weitere Softwareentwicklung ausloten soll, verfehlen langfristige QA-Prozesse ihren Zweck – das Projekt selbst dauert womöglich kürzer, als einen Testplan und eine Testumgebung zu erstellen. Bei jedem Produkt, das den Endkunden erreichen soll, bestehen wir jedoch sehr auf den Standards des QA-Verfahrens.

Jedes unserer Projekte durchläuft ein so gründliches Verfahren.

Oft betrachten wir Tests als letzte Phase, doch bis ein Projekt so weit ist, ist es ein langer Weg. Paralleles Testen von Software ist besser, weil man keine zusätzliche Zeit für Qualitätssicherung aufwenden muss – alles geschieht gleichzeitig. In der Praxis bemerken Entwickler das Testen kaum. Weil es auf Servern läuft, ist es außerdem sehr gut skalierbar.

• Kann man Qualität kaufen? Also nur die Qualitätssicherung als Leistung beauftragen?

Bartek: Ja, das geht. Wir übernehmen auch Projekte, in denen wir nicht die Software selbst liefern, sondern beraten und die gesamte zugehörige Infrastruktur aufbauen. Wir helfen, funktionale Anforderungen zu erarbeiten, erstellen Testszenarien, richten Umgebungen ein, integrieren CI und entwickeln Hilfswerkzeuge für automatisierte Tests. Schließlich sind wir seit fast 12 Jahren in der Softwareentwicklung tätig und teilen diese Erfahrung gern.