Eine gemeinsame Sprache finden

An dieser Stelle muss ich gestehen das ich kein großer Freund von Zertifizierungen bin. Eine Zertifizierung heißt nicht zwangsläufig das derjenige, der die Zertifizierung gemacht hat, auch verstanden hat, worum es eigentlich gehen sollte. Man hat ein gewisses Regelwerk beigebracht bekommen aber auch eine ISTQB-Zertifizierung sagt nichts darüber aus wie gut jemand testet. Prüfungen für Zertifizierungen sind immer Laborprüfungen, wie ein Tester unter echten, und meist chaotischeren, Bedingungen reagiert, ist damit nicht gesichert. Außerdem sind Zertifizierungen immer ausgesprochen teuer.

 

Aber Zertifizierungen haben auch ihr Gutes. Im Rahmen von ISTQB wurde z. B. eine Art „Lexikon der Testerfachsprache“ entwickelt. Gerade wenn man in größeren Teams zusammenarbeitet ist es wichtig, das alle unter bestimmten Begriffen auch das Gleiche verstehen. Und das gilt nicht nur für Tester, auch für den Programmierer kann es sehr hilfreich sein zu wissen, was ein Tester mit bestimmten Vokabeln ausdrücken möchte.

 

Für den weiteren Verlauf meines Blogs möchte ich ebenfalls auf diese „Fachsprache“ zurückgreifen möchte, werde ich die wichtigsten Begriffe hier einmal aufführen. Die Einträge sind eher als eine Gedächtnisstütze und entsprechend eher wie ein Glossar zu lesen.

 

Anforderung (requirement)

- Eigenschaft und / oder Fähigkeit, die zur Lösung eines Problems und / oder zur Erreichen eines Ziels benötigt wird.

- Eigenschaft und / oder Fähigkeit, die benötigt wird um einen Vertrag, eine Norm oder eine andere formelle Spezifikation zu erfüllen.

- Aussage über eine qualitative oder quantitative Eigenschaft eines Produkts

 

Fehler

- Oberbegriff für Fehlhandlung (error), Fehlzustand und Fehlerwirkung (failure)

- Nichterfüllen einer festgelegten Anforderung (Abweichung zwischen Ist- und Soll-Verhalten)

 

Fehlermaskierung

- Eine Fehlermaskierung tritt dann ein, wenn bestimmte Umstände, wie z. B. ein anderer Fehler, einen Fehler überdecken.

 

Fehlerwirkung (failure)

- Die Fehlerwirkung ist das für den Anwender offensichtliche falsche Verhalten des Testobjekts.

 

Fehlzustand (fault, bug)

- Der Fehlerzustand ist der Zustand, indem sich das Testobjekt befindet, während ein Fehler auftritt. Dieser Fehler bezieht sich auf den inneren, nicht zwangsläufig sichtbaren, Zustand des Systems.

 

Funktionalität (nach ISO 9126)

- Angemessenheit

- Richtigkeit

- Interoperabilität (Zusammenarbeit unterschiedlicher, getrennter Systeme)

- Ordnungsmäßigkeit

- Sicherheit

 

Mangel

- Eine Anforderung oder Erwartung wurde nicht angemessen erfüllt, z. B. Beeinträchtigung der Verwendbarkeit bei Erfüllung der Funktionalität.

 

Prüfung (Validierung)

- Messen, Untersuchen, Ausmessen um ein Merkmale oder mehrere Merkmale mit festgelegten Forderungen zu vergleichen. (Konformität des Merkmals)

- Oberbegriff: Alle analytischen Qualitätssicherungsmaßnahmen (unabhängig von Methode und Prüfobjekt)

- Beispiel: Stylecheck: Der Code wird gegen Richtlinien geprüft, die für eine bessere Lesbarkeit und Wartbarkeit des Codes sorgen soll.

 

Qualität

- Gesamtheit der Merkmale und Merkmalswerte eines Produkts oder einer Dienstleistung, die geeignet sind festgelegte und / oder vorausgesetzte Erfordernisse zu erfüllen

- Grad, in dem System, Komponente, Prozess die Kundenerwartung und Kundenbedürfnisse erfüllt

- Grad, in dem eine Menge innewohnender und abhängiger Merkmale die Anforderungen erfüllen

 

Rückverfolgung (traceability)

- Um einen Test auch zu einem späteren Zeitpunkt nachvollziehen zu können (z. B. um die Behebung der Fehlerwirkung zu überprüfen) muss der Testfall rückverfolgbar sein.

 

Softwarequalität

- Funktionalität

- Zuverlässigkeit

- Benutzbarkeit

- Effizienz

- Änderbarkeit

- Übertragbarkeit

- Diese Qualitätsmerkmale müssen in den Anforderungen priorisiert werden, da sie einander teilweise widersprechen (z. B. macht eine perfekte Hardwareanpassung ein System sehr Effizient aber sehr schlecht übertragbar auf andere Systeme).

 

Testaufwand

- Risiko bewerten (Lebensgefahr, monetärer Verlust, Rufschädigung, etc.)

- Entsprechende Gewichtung setzen

- Testaufwand schätzen (Verhältnismäßigkeit beachten)

- Testverfahren (Mehrere Testverfahren mischen)

 

Testdurchführung

- Ablauf der Testfälle festlegen

- Gruppierung in Testsequenzen, Testszenarien

- Testrahmen

- Prüfung auf Vollständigkeit

- Prüfung der Hauptfunktionen (Smoke-Test)

- Testprotokollierung

- Testobjekt, Testrahmen, Eingabedaten, etc.

 

Im Falle einer Fehlerwirkung

- Prüfen ob es wirklich eine Fehlerwirkung ist

- Fehlerwirkung dokumentieren (s. Protokollierung)

- Erste Prüfung wo die Ursache liegen könnte

- Ggf. neue Testfälle für diesen Fehler hinzufügen

 

Priorisierung von Testfällen

- Bestes „Risiko/Abdeckung-Verhältnis“ zu erst testen

 

Testen (Verifizierung)

- Alle statischen und dynamischen Aktivitäten die sich mit Planung, Vorbereitung und Bewertung eines Softwareprodukts befasst. Dazu gehören ebenfalls alle Arbeitsergebnisse dieser Aktivitäten.

- Nachweis, das alle festgelegten Anforderungen erfüllt werden

- Nachweis, das der Zweck erfüllt wird

- Aufdecken etwaiger Fehlerzustände

 

Testfall

- Der Testfall umfasst:

- Notwendige Vorbedingungen

- Menge der Eingabewerte

- Menge der vorausgesagten Sollwerte

- Die Prüfanweisung

- Erwartete Nachbedingungen

- Ein Testfall ist für ein bestimmtes Ziel und / oder bestimmte Testbedingungen definiert (z. B. Ausführung eines bestimmten Programmpfades).

 

Testlauf

- Ein Testlauf ist die Summe der Testfälle einer Version.

 

Testmanagement

- Planung

- Aufwandsschätzung

- Steuerung

- Auswertung

 

Testmittel

- Testmittel sind alle Dokumente und Werkzeuge, die im Rahmen eines Testprozesses erstellt und / oder benutzt werden, z. B. Skripte, Testdaten, Dateien, Datenbanken, Umgebungen, etc.

 

Testobjekt

- Das Testobjekt ist das “System under test” (SUT) oder auch “Application under test” (AUT).

 

Testplanung

- Testbasis prüfen

- Testbarkeit feststellen

- Risiko berücksichtigen

- Traceability sichern

- Logische und konkrete Testfälle

- Verfahren berücksichtigen (Blackbox, Whitebox)

- Vorbedingung, Randbedingungen, Testdurchführung, erwartetes Verhalten beschreiben

- Testorakel befragen (z. B. ein Spezialist, der das Verhalten des Systems voraussagen kann )

- Testfälle für erwartete und unerwartet Eingaben

 

Testprozess

- Planung

- Steuerung

- Analyse

- Design

- Realisierung

- Durchführung

- Auswertung

- Bericht

 

Testsequenz

- Eine Testsequenz ist eine Menge von voneinander abhängigen Testfällen.

 

Testszenario

- Ein Testszenario ist eine Menge von Testsequenzen.

 

Das sind natürlich nicht alle Begriffe, die im ISTQB definiert werden. So habe ich z. B. Fehlhandlung rausgelassen, weil ich nicht glaube das man diese Definition im täglichen Leben braucht. Auch mit der Unterscheidung von Prüfen und Testen tue ich mich etwas schwer, weil ich nicht glaube das irgendjemand das in der täglichen Arbeit derart feingranular unterscheidet. Da aber die Defintion vom Testen bzw. Prüfen (für mich eher als Ganzes unter Testen verstanden) durchaus wichtig ist, habe ich hier beide noch mal hingeschrieben.

 

Was mir ausserdem sehr gefallen hat sind die Prinzipien des Softwaretests aus dem Buch “Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester – Foundation Level nach ISTQB-Standard” von Andreas Spillner und Tilo Linz:

 

Prinzipien des Softwaretests

- Testen zeigt die Anwesenheit von Fehlern

- Vollständiges Testen ist nicht möglich

- Mit dem Testen frühzeitig beginnen

- Häufung von Fehlern

- Zunehmende Testresistenz

- Testen ist abhängig vom Umfeld

- Trugschluss: Kein Fehler bedeutet ein brauchbares System

 

Was bedeutet Software Testing?

Eine Menge sehr kluger Menschen haben dazu eine Menge sehr kluger Sachen gesagt und geschrieben.

Für diesen Beitrag würde ich mich gerne an die Definition von James Bach halten:

Testing is the infinite process of comparing the invisible to the ambiguous so as to avoid the unthinkable happening to the anonymous. [1]

Frei übersetzt: Testen ist der unendliche Vergleich des Unsichtbaren mit dem Unklaren, damit das Undenkbare nicht dem Unbekannten passiert.

Als ich das gelesen habe, habe ich einen Moment gegrübelt und dann sehr gelacht, denn es trifft den Nagel auf den Kopf, auch wenn es sich erst mal wie ein philosophisches Problem liest.

Testen ist ein unendlicher Prozess, muss nach jeder Änderung im System wieder durchgeführt werden. Dabei werden auch bereits durchlaufende Testfälle wiederholt, um sicherzustellen das sich nicht an einer ganz anderen Stelle im Programm ein unerwartetes Verhalten eingeschlichen hat. Denn das ist meistens das weit größere Problem. Die meisten Programmierer testen ihren Code durchaus selbst oder machen sogar Test-Meetings, bei denen die Kollegen ihren Code durchtesten. Entsprechend werden die Fehler, die beim Tester ankommen meistens im Zusammenhang mit der ganzen Software stehen.

Testen bedeutet das Unsichtbare mit dem Unklaren, zu vergleichen. Das Unsichtbare ist noch recht einfach, das ist die Software. Man kann sie nicht anfassen und man sieht ein Update anhand einer Versionierungsnummer aber nicht zwangsläufig, weil es anders aussieht oder sich für den Anwender anders verhält. Tatsächlich beheben die meisten Patches Bugs, die den meisten Anwendern nie aufgefallen sind.

Unklar sind hingegen die Anforderung an die Software. Die Vorstellungen, die ein zukünftiger ein Mensch von seiner Software hat, zu Papier zu bringen ist eine Kunst an sich. Das für eine ganze Gruppe zu schaffen ist schon sehr schwierig. Hinzu kommt, dass die Welt sich sehr schnell ändert und Prozesse müssen sich anpassen. So mag ein Anwender im Januar über bestimmte Abläufe ganz anders denken, als er es im Dezember tun wird. Aber selbst wenn die Anforderungen perfekt erfasst sind, müssen die Entwickler sie immer noch genau so verstehen, wie die Anwender es gemeint haben. Da beide Seiten vermutlich sehr eigene Vorstellungen haben und entsprechend eigene Termini benutzen. Somit können die gleichen Worte im Team doppelt belegt werden, ohne das es zwangsläufig jemandem auffällt. Entsprechend muss regelmäßig überprüft werden was die Beteiligten unter den Anforderungen verstehen und was genau damit gemeint ist. Da hilft nur Nachfragen bis das Unklare, als Teil des Testprozesses, klar geworden ist.

Das Undenkbare vermeiden: Meiner Erfahrung nach wird in den operativen Bereichen sehr klar über mögliche Risiken gesprochen. Interessanterweise schienen die höheren Führungsebenen darüber nicht oder nur in Teilen informiert, zu werden. Dabei kann ich nicht beurteilen ob sie es nicht hören wollten oder ob es ihnen nicht vermittelt wurde. Auch hier besteht immer eine gute Möglichkeit der fehlerhaften Kommunikation. Führungskräfte sind per Definition nicht so tief in den jeweiligen Prozess eingebunden wie die entsprechende Fachabteilung. Doch egal ob es nicht gehört werden soll oder will, ein Tester muss schwere Fehler im Auge haben und entsprechend testen. Datenschutzverletzungen werden mit Sicherheit finanzielle, können aber auch rechtliche, Auswirkungen haben. Um nur ein Beispiel zu nennen.

Was auch immer Schlimmes passieren mag, wenn ein Fehler in der Software seinen Lauf nimmt, es wird mit ziemlicher Sicherheit jemandem passieren den man nicht kennt, der kein Verständnis für die Komplexität von Software hat oder der einem erklären kann oder will, wie es zu diesem Fehler kam. Sei es ein Hacker, der einen Fehler benutzt um sich der Nutzerdatenbank eines Online-Spieleanbieters zu bedienen oder sei es ein einfacherer Anwender, der schlicht und ergreifend nie wieder Software dieser Marke kaufen wird und außerdem allen seinen Freunden davon abraten wird. Womit wir auch schon bei der zweiten Frage wären:

 

Warum sollte man Software testen?

Nehmen wir an unsere Software, wird nicht im medizinischen Bereich eingesetzt und es hängen keine Leben daran. Und nehmen wir weiter an das unsere Software in keiner Weise mit dem Internet verbunden ist, was heute wohl schon eher zur Ausnahme gehören dürfte, und uns somit Datenschutz, Serversicherheit und Ähnliches nicht betreffen. Warum sollte man z. B. ein Offline-Spiel testen? In erster Linie weil man es gut verkaufen will. Ein Übermaß an Bugs wird den Spielern das Spielen schnell verleiden. Wer sich über das Spiel erkundigt, sei es nun in Foren oder in der Fachpresse, wird entsprechende Kommentare lesen und sich den Kauf zwei Mal überlegen. Das Produkt floppt, bevor es überhaupt auf dem Markt ist. Alles was bleibt ist die Reputation das man fehlerhafte Software produziert. Die Märkte sind heute so überfüllt mit guten und relativ fehlerfreien Produkten, das sich ein solches Produkt nicht durchsetzen sehr wahrscheinlich nicht durchsetzen könnte.

James Bach Vortrag wie man ein Testing Experte wird (Englisch)