1) Voraussetzungen für das Gelingen von Softwaretest und -qualitätssicherungsmaßnahmen
Nun also ein weiterer kleiner Text über die Grundlagen der Softwarequalitätssicherung - mal von der Praxisseite aus beleuchtet.
“Ja, wir müssen testen!” ist die schon fast triviale Erkenntnis vieler Softwarehersteller. Und dann? Fange ich mit naivem “Geklicke” an? Oder lerne ich erstmal monatelang etwas über Methoden, Prozesse und Techniken?
Ganz anders: als aller erstes steht die Analyse der eigenen Vorgehensweise, denn ein Test ist immer nur so gut, wie der Reifegrad des Softwareentwicklungsmodelles, das dahinter liegt. Und als weiter wichtiger Punkt ist “persönliche Verantwortung” zu nennen. Was ich damit meine, kommt gleich. Aber eins nach dem anderen.
Wenn bisher Softwareentwicklung “auf Zuruf” betrieben wurde, können von dem Test keine Wunder erwartet werden. Dann ist vielleicht gerade mal ein wenig exploratives Testen möglich, mit sehr dünnem Erkenntnisgewinn.
Ein Prozess, in dem Softwarequalitätssicherung sinnvoll angwendet werden soll, muss ein paar Voraussetzungen erfüllen.
Es gibt einen definierten Softwareentwicklungsprozess - Minimum: Softwareentwicklung findet in Phasen statt
Zu jeder Phase gehört: es wird festgelegt, was entwickelt werden soll, es wird entwickelt und am Ende wird das Ergebnis mit einem “Stempel” versehen. Z.B. einer Version, einer Bezeichnung oder sonst einem eindeutigem Erkennungsmerkmal. Und das ganze in einer vorher festgelegten Zeit. Das ist Minimum!
Das können sie leisten? Prima, dann können wir mit Softwaretesten anfangen.
Wenn sie bereits einen definierten Softwareentwicklungsprozess leben und auch schon irgendwie testen, dann kann es vielleicht sinnvoll sein mal genauer hinzuschauen, wie weit sie mit ihrem Prozess sind und welche Entwicklungsmöglichkeiten sie dann bzgl. des Tests haben. Dazu gibt es eine feine und erschreckend und logische Vorgehensweise namens TPI (Test Process Improvement). Mit Hilfe dieses Modells wird ihr aktueller Testprozess anhand von 20 Kriterien analysiert und mit Hilfe des Ergebnisses eindeutige Anregungen für die Verbesserung des Tests gegeben. (TPI ist eine Entwicklung von sogeti. Unterstützung bekommen sie auch von meinem Arbeitgeber). Bei Gelegenheit mache ich mal einen Artikel zum Thema TPI …
persönliche Verantwortung
In der Praxis begegnet mir immer wieder die Situation, dass QS und Test in einer Firma, Abteilung, Projekt nicht ernst genommen wird. Softwaretest hat keine Lobby. “Ja, muss man ja auch noch machen! Hach, hätte man doch glatt vergessen … tststs!” Das Ergebnis einer solchen Einstellung ist eine unzureichende Qualitätssicherung. Formell wird dann ein vielleicht sogar unternehmensweit vorgeschriebener Testprozess erfüllt, tatsächlich ist das meiste davon Fake.
Meiner Erfahrung nach muss sich in solch einer Situation eine Person persönlich verantwortlich für den Test fühlen und mit seiner ganzen Persönlichkeit in die Bresche springen. Man braucht den Typen, der sich freiwillig die Pappnase aufsetzt und in jeder Besprechung immer und immer den Test-Narren macht. Und dabei hilft es nicht einfach jemanden auszugucken (per Flaschendrehen oder Pinchenziehen), denn der macht den Job nur halbherzig. Am besten scheint mir dann eigentlich ein externer Profi, der es sich leisten kann, losgelöst von den internen Abteilungsbefindlichkeiten zu handeln.
Natürlich ist sowas nicht akzeptabel: aber, hey, irgenwie muss man ja weiterkommen!
Hier mal ein paar Softskills, die solch ein Mensch haben sollte:
- Teamfähigkeit, diplomatisches Geschick
- Kommunikationsfähigkeiten, -geschick
- Kreativität beim Hinterfragen der Gegebenheiten
- Pingeligkeit in der eigenen Arbeit, Durchführung, Dokumentation usw.
- Fähigkeit, sich schnell in fremde Sachverhalte einarbeiten zu können
- Disziplin und strukturierte Arbeitsweise
- Leidensfähigkeit
Also, quasi ein Supermann .
Und jetzt bin ich auf die Kommentare gespannt …
