Qualität ist die Fähigkeit eines Systems, Anforderungen zu erfüllen. Die Aufgabe vom Testen ist es u.a. , Abweichungen zwischen gegebenen Fähigkeiten eines Systems und Anforderungen festzustellen. Anforderungen sind also existentiell, es gibt sogar eigene Standards für Anforderungen. Wo ist also das Problem? Es gibt nicht-testbare Anforderungen! Ein (nicht 100% ernst gemeintes) Beispiel aus der Praxis!

Als Naturwissenschaftler ist man geneigt, die Welt rational in Fragmente zu zerlegen, sie zu analysieren, zu messen usw. . Anforderungen an IT-Systeme sind auch so aufgebaut: Sie sollten nicht einfach fordern “mach ein tolles System”, sondern möglichst feingranular und präzise sein: “Die Liste sollte nach der ID sortierbar sein” und “das Bild sollte gedruckt werden können”.

Aber die Welt besteht nicht nur aus Naturwissenschaftlern und harten Fakten, sondern eben auch aus emotionalen, weniger harten Anforderungen.

Ein (aus meiner Sicht) amüsantes Beispiel erreichte mich gestern: Eine Marketing-Firma schickte uns einen neuen Kugelschreiber zu. Aufwändig in der Verpackung und mit einem langen “Beipackzettel”, aber trotzdem ein ganz normaler Kugelschreiber. Auf dem Beipackzettel waren die Eigenschaften des Kugelschreibers formuliert, die sicher mal als Anforderungen an den Kugelschreiber begonnen haben….und als Tester versucht man dann ja natürlich sofort, diese zu prüfen…doch ohne Erfolg. Einige Zitate (wirklich!) aus der Beschreibung des Kugelschreibers, im Folgenden als Anforderungen formuliert:

• Der Kugelschreiber soll “einen mutigen, innovativen Look haben, der die ganze Dynamik offenbart” (wohlgemerkt: es handelt sich um einen Kugelschreiber, nicht etwa um einen Porsche!).
• Für den Kugelschreiber soll gelten: “Um seinen Charakter zu erfassen, genügt ein Blick auf seine Silhouette” (Nur als Hinweis: Auch dieser Kugelschreiber hat eine ganz normale Stiftform).
• Der Kugelschreiber soll “eine lebendige vielseitige Farbenwelt seines designten Körpers” besitzen (also zumindest der mir zugeschickte Kugelschreiber konnte nur langweiliges Blau).
• Der Kugelschreiber soll “geschaffen sein, um Visionen gestaltbar zu machen” (hab’s probiert, man kann aber auch einfache Einkaufszettel damit schreiben).
• Der Kugelschreiber soll “Sie an die Hand nehmen, um Sie an ihr Ziel zu begleiten – dorthin wo jeder seine Visionen mit Tinte zeichnen kann” (also in meinen Zielen und Visionen wenigstens spielt Tinte eine relativ untergeordnete Rolle)

Wie testet man so etwas, bzw. wie hat man den Kugelgeschreiber getestet, so dass diese Beschreibungen heute Gültigkeit haben? Man kann sich als Tester natürlich auf die IEEE830 zurückziehen und sagen: Das sind ganz schlechte Anforderungen; dies kann einfach entlang der IEEE830-Anforderungen an Requirements bewiesen werden. Demnach müssen Anforderungen sein: “Correct, Unambiguous, Complete, Consistent, Ranked for importance and/or stability, Verifiable, Modifiable, Traceable”. Und zumindest für einige dieser Charakteristika kann dies einfach widerlegt werden, da sie

• mehrdeutig sind (was ist eine Kugelschreiber-Dynamik?),
• nicht geranked sind (soll er mich “eher an die Hand nehmen” oder eher “in seiner Farbenwelt billieren”?),
• nicht testbar sind (wie erfasse ich einen Charakter?)

Was man machen könnte wäre, die Unschärfe der Requirements an den End-User weiterzureichen: 10 unterschiedliche Kugelschreiber einem End-User präsentieren und fragen, welcher am ehesten taugt, “Visionen gestaltbar zu machen”, oder wer den “mutigeren Look hat”.

Viele dieser Anforderungen gehören im weitesten Sinn zum Thema Usability, das auch den Bereich der Attraktivität kennt. Aber auch hier: Anforderungen wie “muss attraktiv sein” sind noch zu mehrdeutig und nicht testbar.

Doch während ich mir so Gedanken mache, wie solche marketinglastigen Requirements doch noch irgendwie testbar sind ist ein anderes Problem aufgetaucht: Mein Kugelschreiber funktioniert nicht mehr!!! Aus ist’s mit “an die Hand nehmen” und der “lebendigen vielseitigen Farbenwelt” ….ich kann nicht mehr klicken, um die Mine rein und rauszufahren. Von daher gilt auch hier (für mich): Erst mal die Basisfaktoren, dann die Leistungsfaktoren und am Ende – wenn dann wirklich noch Zeit bleibt  die Begeisterungsfaktoren (vgl. Kano-Diagramm). Aber vermutlich ist auch das eine sehr naturwissenschaftliche Gewichtung….aber es ist – entlang der IEEE830 – wenigstens eine Gewichtung!