Checkliste: Wie hoch ist die Qualität Ihrer Software?

Symbolbild von Gerd Altmann via Pixabay

Checkliste zur Qualität Ihre Business Software

1. Wann hat es ein kritischer Fehler zum letzten Mal in die Produktionsumgebung geschafft bzw. wann hat ein Benutzer zum letzten Mal einen kritischen Fehler in Ihrer Applikation entdeckt?

1. Letzte Woche
2. Letzten Monat
3. Irgendwann in den letzten sechs Monaten
4. Das ist mehr als sechs Monate her

2. Gibt es einen ‘Smoke Test’ und wie einfach kann er ausgeführt werden?

1. Wir haben keinen Smoke Test. Was ist ein Smoke Test überhaupt?
2. Wir haben einen definierten Smoke Test und er kann schnell (in weniger als 30 Min.) z. B. manuell ausgeführt werden.
3. Unser Smoke Test ist vollständig automatisiert, läuft in weniger als fünf Minuten durch und kann von jedem jederzeit gestartet werden.
4. Unser Smoke Test ist voll automatisiert, dauert weniger als fünf Minuten und wird immer ausgeführt, bevor eine Änderung am Code in die Baseline eingecheckt wird (z. B. auf dem Laptop des Entwicklers oder in einer Entwicklungsumgebung).

3. Ist in Ihrer Firma eine einheitliche Teststrategie definiert?

1. Wir haben keine Teststrategie. Wieso sollte ich eine haben?
2. Es gibt keine einheitliche Teststrategie. Aber wir schreiben für jedes Projekt eine Teststrategie, bevor wir mit einem neuen Projekt beginnen.
3. Wir haben eine einheitliche Teststrategie, die für alle Projekte gilt.
4. Wir haben eine einheitliche Teststrategie und sie wird in allen Projekten angewendet. Alle Mitarbeitenden kennen die Strategie und lassen sich bei Entscheidungen, die den Test betreffen, davon leiten.

4. Testdaten

1. Testdaten müssen jeweils manuell erfasst, kontrolliert oder modifiziert werden, bevor ein Test ausgeführt werden kann
2. Es gibt eine zentrale Datenbank, in der alle Testdaten verwaltet werden. Testdaten können einfach in alle Umgebungen kopiert werden.
3. Alle Tests laufen gegen eindeutig definierte Testdaten. Testdaten sind immer ‘sauber’, d.h. Testdaten sind nicht davon abhängig, ob in der Umgebung bereits andere Test ausgeführt wurden.
4. Nach der Testausführung werden die Testdaten (automatisch) analysiert und mit den erwarteten Resultaten verglichen. Diese Analyse fliest auch in das Testresultat ein.

5. Testplan

1. Was ist ein Testplan?
2. Für jeden wichtigen Release wird ein Testplan erstellt (z. B. durch den Testmanager) und es werden die Ressourcen, der Zeitplan und die auszuführenden Tests definiert.
3. Der Testplan wird regelmässig (mindestens täglich) automatisch oder durch einen Testmanager oder das Testteam aktualisiert und bildet den aktuellen Stand der Testausführung zuverlässig ab.
4. Testpläne werden erstellt und sind so genau, dass sie normalerweise (in min. 90 % der Fälle) eingehalten werden.

6. Risikobasiertes Testen

1. Es gibt kein umfassendes Verständnis, mit welchem Risiko einzelne Änderungen am Code oder am System verbunden sind.
2. Für jede Testausführung wird eine Risikoanalyse gemacht.
3. Testfälle werden gestützt auf eine Risikoanalyse ausgewählt und priorisiert. Die Risikoanalyse ist mindestens teilweise automatisiert.
4. Es gibt ein automatisiertes System, das schnell und zuverlässig feststellen kann, welche Tests ausgeführt werden müssen, um die wichtigsten Risiken abzudecken.

7. Testautomatisierung

1. Bei uns wird nur manuell getestet. Aber wir planen seit vielen Jahren, bald mit der Testautomatisierung zu beginnen.
2. Wir haben automatisierte Unit Tests.
3. Wir haben automatisierte Tests auf allen Abstraktionsebenen (Unit Tests, Integrations- und Systemtests).
4. Wir haben automatisierte Tests auf allen Abstraktionsebenen und die Test werden regelmässig (min. einmal pro Tag) ausgeführt. Falls ein Testfall nicht mehr funktioniert (z. B. weil sich der Code oder das System geändert hat), so wird der Testfall vor dem nächsten Testlauf (also spätestens in einem Tag) korrigiert.

8. Regressionstest

1. Wir haben keinen Regressionstest. 
2. Wir haben einen Regressionstest und er wird regelmässig manuell ausgeführt.
3. Alle unsere Regressionstests sind automatisiert. Wir testen nur neue Funktionalität manuell.
4. Alle unsere Regressionstests sind automatisiert. Und für jeden kritischen Fehler (P0 oder P1) haben wir einen automatisierten Test geschrieben, der verhindert, dass sich derselbe Fehler jemals wieder einschleichen kann.

9. Exploratives Testen

1. Wir testen nicht explorativ. Was ist das überhaupt?
2. Wir testen manchmal explorativ. Aber wir haben keinen klar definierten Prozess dafür. 
3. Exploratives Testen ist gut verankert und Teil des Testprozesses. Die benötigte Infrastruktur und Werkzeuge (z. B. detaillierte Logfiles) sind vorhanden.
4. Exploratives Testen findet mindestens 90 % aller kritischen Fehler (P0 oder P1). 

10. Performancetesting

1. Wir machen keine Performancetests
2. Wir machen keine Performancetest. Aber wir überwachen die Performance unserer Systeme während dem Release (z.B. mit canary testing).
3. Wir testen die Performance der einzelnen Module und des Systems regelmässig und wir erkennen Veränderungen in der Performance, bevor die Software produktiv gesetzt wird.
4. Wir überwachen Veränderungen in der Performance konstant und wir können diese einzelnen Aenderungen am Code oder am System schnell (spätestens nach einem Tag) zuordnen. 

11. Verteilung des Testaufwand

1. Mehr als 80 % des Testaufwand fällt in einer Kategorie an (z. B. manueller Systemtest oder automatisierte Unit Tests).
2. Mehr als 60 % des Testaufwand fällt im funktionalen Test an und weniger als 40 % im nicht funktionalen Test wie z. B. Performance, Usability, Security etc.
3. Mehr als 50 % des Aufwandes für die Testautomatisierung konzentriert sich auf eine Abstraktionsebene (z. B. Unit Test).
4. Der Testaufwand ist gleichmässig verteilt über unterschiedliche Tests (Functional, Performance, Usability …) und Abstraktionsebenen (Unit, Integration, System).

12. Qualitätskultur

1. Es ist schon vorgekommen, dass Mitarbeiter (Entwickler, Sysadmins …), die einen Fehler gemacht oder entdeckt haben, diesen nicht offen und für alle sichtbar kommuniziert haben.
2. Alle Mitarbeiter übernehmen die Verantwortung für Fehler und Probleme, die sie verursachen oder entdecken und kommunizieren diese sofort und offen (z. B durch einen Eintrag in der Fehlerdatenbank).
3. Fehler werden als unvermeidlich angesehen und die Verantwortlichen werden nicht sanktioniert. Für jeden kritischen Fehler wird aber zeitnah (max. 30 Tage) ein Post Mortem gemacht: Wie ist es zu dem Fehler gekommen? Wie hätte er verhindert werden können? Welche Prozesse etc. müssen angepasst werden?
4. Der Softwaretest wird in der Organisation als wichtig angesehen. Alle (nicht nur die Tester) fühlen sich für den Test und die Softwarequalität verantwortlich. Testerinnen und Tester geniessen ein hohes Ansehen, sie haben sich das Ansehen verdient und übernehmen eine Vorbildfunktion.
   

Auswertung

Der Beitrag dazu erschien im topsoft Fachmagazin 23-3

Das Schweizer Fachmagazin für Digitales Business kostenlos abonnieren

Abonnieren Sie das topsoft Fachmagazin kostenlos. 4 x im Jahr in Ihrem Briefkasten.