Archiv für Mai, 2007
Wenn wir ein Programm testen, stoßen wir auf Fehler. Bevor wir aber wissen, dass es sich um einen Fehler handelt, merken wir nur, dass wir als Tester auf etwas Unerwartetes stoßen. Etwas passiert nicht so, wie wir es erwarten.
Dies trifft auch auf automatische Testdurchführung zu. Das Ergebnis des Testdurchlaufes stimmt nicht mit einem vorgegebenen Resultat überein.
Jetzt stellt sich heraus, dass ein beobachteter Effekt zwei verschiedene Kriterien erfüllen muss, um als Fehler klassifiziert zu werden.
- Er überrascht uns. Wir selbst glauben, dass etwas falsch ist.
- Es herrscht Konsens von mehreren Seiten, dass hier etwas unrichtig ist.
Liegt nur die erste Bedingung vor, so verwenden wir besser einen anderen Begriff. In mehreren Firmen wird der Begriff PROBLEM bevorzugt.
Ein PROBLEM ist eine Unstimmigkeit, die aufgelöst gehört.
Die zweite Bedingung spricht von mehreren Seiten. Damit ist der Tester (T), der Entwickler (E) und der Anforderer (A, der Vertreter des Auftraggebers, welcher die Funktionalität des Programmes beschrieben hat) gemeint. Es ergeben sich jetzt folgende Möglichkeiten:
(In untenstehender Notation bedeutet 0, dass kein PROBLEM festgestellt wurde, 1 hingegen, dass die jeweilige Person einen Fehler konstatiert.)
- T=0 E=0 A=0 Es wird kein PROBLEM und auch kein Fehler konstatiert.
- T=0 E=0 A=1 Eine unangenehme Situation, die aber nicht im Zuge des Testens erkannt wird. Hier handelt es sich um eine Entwicklung auf ein „moving target“, dieser Umstand verteuert jede Software-Entwicklung.
- T=0 E=1 A=0 In dieser Situation freut sich der Entwickler, der selbst irgendwann seinen eigenen Implementierungsfehler festgestellt hat, dass sonst noch niemand seinen Fehler entdeckt hat. Er wird versuchen, die Nachbesserung in die nächste Version einfließen zu lassen.
- T=0 E=1 A=1 Das ist eine Testsituation, bei der nicht das Programm sondern die Testdurchführung getestet wurde. Bewusst eingebaute Fehler sollen die Zuverlässigkeit des Software-Tests überprüfen. Ich habe diesen Fall in der Realität noch nie vorgefunden, doch wird er in manchen Vorträgen über Software-Test erwähnt. Die Vorgangsweise der bewussten Fehlereinstreuung ist bei Hardwaretests immer dann notwendig, wenn es um sensible und lebensbedrohende Apparaturen geht.
- T=1 E=0 A=0 Ein Streitfall. Hier steht der Tester gegen den Rest der Welt. Solche PROBLEME bleiben ungelöst, wenn der Tester nicht überzeugt werden kann, dass seine Beanstandung falsch gewesen ist.
- T=1 E=0 A=1 Ein Entwicklungsfehler. Etwas ist in der Implementierung falsch. Nun kann das Problem als ERROR klassifiziert werden. Der Anforderer muss oft gar nicht konsultiert werden, wenn der Entwickler bereits selbst mit der ERROR-Klassifikation übereinstimmt.
- T=1 E=1 A=0 Ein Fehler in der Anforderung. Der ursprüngliche Wunsch des Anforderers war sachlich unrichtig. Aus Gründen der Unterscheidbarkeit und auch wegen der unterschiedlichen Behandlung bei der Korrektur wird hier nicht von ERROR gesprochen sondern von einer Anforderungsänderung – CHANGE REQUEST
- T=1 E=1 A=1 Auch hier tritt der Fall der Anforderungsänderung ein. Es wird aber in der Regel keine langatmige Diskussion mit dem Anforderer notwendig sein.
(Über CHANGE-REQUEST wird später noch gesprochen.)
Wenn wir nun die unterschiedlichen Fälle betrachten, so stellen wir fest, dass in einigen Fällen die Zusammenarbeit von Entwicklern und Testern in eine Streiterei ausarten kann. Der Entwickler gibt ungern einen Fehler zu, der Tester wird an der Anzahl der gefundenen Fehler gemessen und „freut sich“, wenn er wieder etwas gefunden hat. Der Entwickler kann allenfalls auf CHANGE-REQUEST plädieren, womit der schwarze Peter dem Anforderer zugespielt wird. Dieser hat an sich eine Grundverantwortung über die Richtigkeit eines Programmes. Er kann sich also höchstens aufregen, warum man diesen Fehler nicht schon viel früher entdeckt hat.
Hier muss zur Verteidigung des Anforderers festgestellt werden, dass manche Effekte erst dann wirklich sichtbar werden, wenn man sie mit eigenen Augen am Bildschirm sieht. Man kann auch sagen, wenn die Vorstellung Gestalt angenommen hat, werden Fehler erst sichtbar.
Wenn wir bei komplexeren Programmen mit mehreren Tausend PROBLEMEN zu tun haben, wird es notwendig sein, dass die Vorgangsweise im Fall 5 und 7 reglementiert wird. Es darf nicht zu mehreren Tausend Streitigkeiten kommen.
Hier bestimmt die Kultur eines Software-Hauses die Effizienz des gesamten Teams. Wird das Gesamtziel in den Vordergrund gestellt, so darf die Produktivität des Testvorganges nicht an der Anzahl der gefundenen Fehler gemessen werden.
Viel mehr ist derjenige Tester der erfolgreichste, welcher die meisten Fehler behoben bekommt.
Damit wird dem Tester aber auch die Aufgabe zugeteilt, das aufgetretene PROBLEM so umfassend wie möglich zu beschreiben, damit die Reproduzierung des PROBLEMs und die Behebung für den Entwickler erleichtert werden.
Darüber hinaus führt diese Überlegung zum Begriff des Schweregrads eines Fehlers. Dieser wird später behandelt.
——————————————–
Vor 22 Jahren arbeitete ich für ein renommiertes deutsches Unternehmen, welches über eine österreichische Tochterfirma in die Sovjetunion verkaufte. Der Verkauf lief über zentralistische Außenhandelsunternehmungen. Diese benötigten eine Proforma, die dann entsprechend „getuned“ wurde, um den preislichen und gleichzeitig technischen Anforderungen zu entsprechen.
Die Auftragsbestätigung und das Rechnungswesen lief über die österreichischen bzw. deutschen Zentralcomputer. In Wien war das eine Nixdorf-Anlage.
Zum Schreiben der Proformas (bzw. Spezifikationen, ein dem Techniker genehmerer Ausdruck) wurden seit jeher Schreibmaschinen verwendet. Tippex war ein Problem, da es in den Proformas keine Korrekturen geben sollte. Trotzdem kannte ich einen Kollegen einer anderen Firma, der seine Proformas mit Papier, Schere und Uhu-Stick zusammenbastelte.
Als große Errungenschaft hatte die Chefin der EDV in Wien ein Programm „gebastelt“, welches die Schreibmaschine durch einen PC ersetzen ließ. Von der Nixdorf-Anlage gab es einen Abzug der Stammdatei-Artikel. Artikelnummer, Kurzbezeichnung, Preis.
Jetzt konnte man sich die Artikel durch Eingabe der Artikelnummer zusammensuchen und musste nicht mehr im Prospekt nachschlagen. Für meinen damaligen Chef war das eine große Verbesserung, ich schlug die Hände über dem Kopf zusammen und bastelte aus lauter Verzweiflung mein eigenes System.
Warum war ich verzweifelt? Das Programm wies drei hauptsächliche Fehler auf. Zwei davon waren Analyse-Fehler, einer bestand in der Nichterfüllung von nicht-funktionalen Anforderungen.
Die Analysefehler waren folgende:
Die Anwendungsfälle (use cases) des Programmes waren nur oberflächlich untersucht worden. Es fehlte der Anwendungsfall „Proforma überarbeiten“. Das führte dazu, dass man
- eine einmal geschriebene Spezifikation nicht verwenden konnte, um eine ähnliche Spezifikation mit zwei Teilen mehr oder weniger zu erstellen.
- nichts aus einer Spezifikation löschen konnte, es sei denn die gerade eben zuletzt eingegebene Zeile.
Die Spezifikationen wiesen in der Regel zwischen 30 und 50 Positionen auf und es kam schon einmal vor, dass man das gleiche Objektiv auf zwei verschiedenen Seiten fand.
Das Performance-Problem war einfach, dass der Suchvorgang pro Artikel 20 oder mehr Sekunden dauerte. Das klingt nicht so lange, vor allem dann nicht, wenn es sich um eine Web-Anwendung handelte. Aber das gab es damals noch nicht. Das war eine Standalone-Lösung. Mich trieb das jeweilige Warten in den Wahnsinn.
Auf meinem privaten Computer, den ich in die Firma gebracht hatte, – damals gab es noch keine PCs als Standardausrüstung – programmierte ich nach Dienstschluss mein eigenes Proforma-Programm. Ich hatte gerade Turbo-Pascal gelernt und wer diese Programmumgebung noch kennt, weiß, dass man damit teuflich schnell sein kann. Ich hatte das Glück, dass die Stammdatei-Artikel auf einer Diskette (170kB) untergebracht werden konnte. Und diese Stammdatei gab es auch immer, weil sie auf den Computer im Moskauer Büro überspielt werden mußte.
Ich wusste, was ich brauchte und konnte es mir im Notfall auch dazuprogrammieren. Mein Artikelsuchvorgang dauerte weniger als eine Sekunde, Bearbeitung, Nachbearbeitung, Aufsplittung einer Messe-Proforma in mehrere Angebote war kein Problem. Programm und Daten fanden auf zwei Disketten Platz. Ich wusste normalerweise nicht, auf welchem Rechner ich es laufen lassen musste. Manchmal war es ein Olivetti, dann wieder ein IBM-PC. (Die Rechner gehörten zu den ausgestellten Bildanalysegeräten.) Egal, das Programm lief überall.
Später lief es auch auf dem Moskauer PC. Es half mir, Spezifikationen innerhalb einer Nacht zu überarbeiten. Der Umsatz in meinem Geschäftsgebiet hatte sich in drei Jahren verdreifacht.
Ein Tester, den man auf das Programm angesetzt hätte, hätte feststellen können, dass das Programm langsam ist. Er hätte auch moniert, dass es fehlerintolerant war. Eine kleine Nachlässigkeit – und schon waren 30 Minuten Arbeit beim Teufel.
Doch in Wirklichkeit hätte man das alles bereits in der Analyse- und Designphase feststellen können. Damals zog das Argument: der Computer kann das nicht anders. Ich habe mir daher mit dem Gegenbeweis nicht nur Freunde gemacht. Aber ich sage: – und das besonders heute – Der Computer kann das, was wir von ihm fordern.
———————————————————————–
Der Titel dieses Blogs kann genau so sehr in die Irre führen wie der Gegenstand dieses Blogs. Ohne es genau zu hinterfragen, könnte man implizieren, dass der Autor 37 Jahre alt ist und damit rechnet, bis zu seinem 74 Lebensjahr arbeiten zu müssen. Wahr ist vielmehr, dass der Autor vor 37 Jahren das erste Mal mit einem Software-Fehler konfrontiert war. Irgendwo hat das dann in meinem Leben Niederschlag gefunden.
Das Thema dieses Blogs ist Software-Test.
Zum Einstieg möchte ich meine erste Begegnung mit einem Softwarefehler vor 37 Jahren berichten.
Als neunzehnjähriger Werkstudent arbeitete ich bei einem großen Elektronikkonzern in der EDV als Operator. Das war für mich die beste Gelegenheit, einem Computer nahe zu kommen.
Jeden Monat musste ein Programm laufen, dass sich „offene-Posten-Buchhaltung“ nannte. Es lief im Durchschnitt acht Stunden und war für den Operator ein angenehmes Programm. Zu Beginn musste man ungefähr einen Drittelmeter Lochkarten in die Zuführungsrinne platzieren. Danach lief das Programm von selbst mit Ausnahme der halbstündigen Bandwechsel im klimatisierten Bandraum.
Dann gab es noch einen notwendigen Eingriff. Nach einigen Stunden lief das Programm auf einen absoluten Halt. Die Daten mussten sortiert werden und der Sortiergenerator lief mit den vier Bandlaufwerken einfach nicht fehlerfrei. Es gab damals nur eine gleichartige Anlage, die sechs Laufwerke hatte. Dort war der Sort-und-Merge-Algorithmus entwickelt worden und hatte funktioniert. Ich erfuhr davon erst Jahre später.
Um das Programm fortzuführen, musste ich auf der Konsole einige Register neu laden. Die eingestellten Ziffern wurden mit kleinen Lämpchen im Excess-3-Code dargestellt. Danach wurde noch ein Sprungbefehl auf eine fixe Adresse eingegeben und auf RUN gedrückt. Nach einiger Zeit beherrschte man die Abfolge im Schlaf. Ich kann mich aber erinnern, dass ich ungläubig staunte, als ich meine Kollegen das erste Mal bei dieser Tätigkeit beobachtete.
Ich habe damals nicht verstanden, warum die Firma diesen Fehler nicht beheben ließ. Mir erschien es als sehr großes Sicherheitsrisiko, Menschen in den Ablauf eingreifen zu lassen. Weiß Gott, was man damals hätte hacken können:)
Heute darf ich behaupten, dass ich verstehe, warum man nichts unternommen hat. Das Leben mit Fehlern ist im Softwarebereich notwendig. Vernünftiger Software-Test sorgt aber dafür, dass wir unter den Fehlern nicht zu sehr leiden müssen und dass ihre Auswirkungen erträglich bleiben.
In diesem Blog möchte ich einige Gedanken darstellen, welche dieser Sorge Rechnung tragen.
Jänner 2018
Letzte Kommentare
Das 37. Jahr 