Startseite > Embedded > Entwicklungstools > Tipps für das Software-Testmanagement

Empfehlungen aus der Trickkiste der Softwaretechnolgie

Tipps für das Software-Testmanagement

12. Oktober 2011, 15:06 Uhr | Von Stephan Grünfelder

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 3

Testet die Tester

Das Beispiel mit dem Dienstleister aus Bangalore könnte gefährlicherweise so interpretiert werden, dass Automation eine schlechte Prozesslandschaft glatt zu bügeln vermag. Das ist nicht der Fall. Im Gegenteil: Automation kann einen effizienten Prozess optimieren, einen chaotischen aber noch verschlechtern [10].

Das heißt, Automation entbindet nicht von gut aufgesetzten Prozessen, sauberer Dokumentation, klarem Testdesign und von der Review des Testdesigns. Ich habe eine Firma kennengelernt, wo ein Mitarbeiter des Testteams drei Jahre lang Systemtests gemacht hat, ohne dass je ein anderer Mitarbeiter die Qualität seiner Arbeit im Rahmen einer Testreview beurteilt hätte. Ein Albtraum. So sah sein Testdesign auch aus: er hatte weder je einen Kurs über Testen besucht, noch je von Kollegen gelernt. Daher mein Appell:

Empfehlung 9: Etablieren Sie systematische Reviews von Testfällen. In einem Projekt mit nicht allzu großem Anspruch an die Integrität der Software wird eine Review des Systemtestdesigns auf Top-Level ausreichen. Je kritischer das Projekt, desto eher werden dann auch die auf diesem Design basierenden Skripte für die Testautomation einer Review unterzogen werden und/oder ein unabhängiger Modultest oder zumindest eine Review von Modultestfällen gefordert.

Damit die Review eines Software-Systemtestfalls Sinn hat, muss der Reviewer genau wissen, welche Anforderungen der Testfall abdecken soll. Umgekehrt möchte er auch nachvollziehen können, ob ein Set von Testfällen alle Anforderungen prüft oder ob eine Anforderung vergessen wurde.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Anforderung	Titel der Anforderung	Getestet in
R/SRD/INIT/10	Self Test	ST-IOPS-FT01
R/SRD/INIT/20	Self Test Fail Silence	ST-IOPS-FT01
R/SRD/PP/05	Ready Message	ST-IOPS-FT01
R/SRD/PP/20	PP-bus Performance	ST-IOPS-FT02
R/SRD/PP/30	Reply Message Format	ST-IOPS-FT02
R/SRD/PP/40	SetPosDebTime Cmd	ST-IOPS-FT03
R/SRD/PP/50	SetNegDebTime Cmd	ST-IOPS-FT03
R/SRD/PP/60	SetRepIntv Cmd	ST-IOPS-FT02
R/SRD/PP/70	Start Command	ST-IOPS-FT02
R/SRD/PP/80	Report Message Format	ST-IOPS-FT02
R/SRD/SI/10	Switch Position Sampling Rate	ST-IOPS-FT03
R/SRD/SI/30	Debouncing Algorithm	ST-IOPS-FT04 ST-IOPS-FT03
R/SRD/RA/10	Missing Parameters	ST-IOPS-FT05
R/SRD/RA/20	PP-bus Error	ST-IOPS-FT05
R/SRD/RA/30	Watchdog Kicking	ST-IOPS-FT05
R/SRD/SB/10	Maximum CPU Load	ST-IOPS-FT06
R/SRD/SB/20	CPU Idle Time	ST-IOPS-FT07
R/SRD/SB/30	Memory Footprint	ST-IOPS-FT08
R/SRD/SD/10	Software Coding Standard	Tested in code inspections
R/SRD/SD/20	Software Reuse	Tested in code inspections
R/SRD/SD/30-1	Programming Language	Tested in code inspections

Beispiel einer Traceability-Tabelle aus [1].

Damit diese Traceability klappt, kann man sich z.B. Traceability-Tabellen erstellen, wie in der beispielhaften Tabelle zu sehen. Für die drei Anforderungen in der gezeigten Tabelle, die nur im Rahmen von Code Inspections verifiziert werden können, könnte z.B. auf den Code-Inspection-Checklisten je ein Punkt aufscheinen, damit diese Belange bei den Inspektionen nicht vergessen werden. Meine Empfehlung also:

Empfehlung 10: Establieren Sie Traceability von den Anforderungen zu den Tests und umgekehrt. Ich persönlich rufe mir immer vor der Review eines Testfalls mit Hilfe der Traceability-Tabelle und der Spezifikation die zu testenden Anforderungen ins Gedächtnis und prüfe dann erst das Testdesign. So eine Verfolgbarkeit vom Test zu den Anforderungen und umgekehrt muss nicht in Tabellenform passieren. Auch Hyperlinks etc. sind denkbar. Ohne Traceability wird eine größere Testsuite zunehmend unwartbar. Welche Tests müssen aktualisiert werden, wenn sich eine Anforderung ändert? Welche Anforderungen müssen ggf. mit dem Kunden neu verhandelt werden, wenn ein Test fehlschlägt? Anworten auf diese Fragen sind schnell gefunden, wenn man Tabellen, wie gezeigt, regelmäßig wartet.

„Hygienefaktoren“ und Synergien rund um den Systemtest

Die Dokumentation der Traceability, die Testdokumentation und die Testskripts müssen natürlich einem Konfigurationsmanagement (CM) unterzogen werden, wie der Code selbst. Das heißt, aus dem CM-Werkzeug muss klar hervorgehen, welche Testversion welche Code-Version testet.

Gute Testdokumentation und Dokumentation der Reviews ist alleine schon aus Haftungsgründen wichtig [11, 12]. Wenn Sie - mit oder ohne Angst vor einer Produkthaftung - alle bisherigen Empfehlungen befolgen, dann sind Tests so solide dokumentiert, dass Sie sich auch mit anderen Abteilungen oder dem Kunden darüber austauschen können. Eine „andere Abteilung“, an die ich als Software-Tester besonders denke, sind die Leute vom Hardware-Test. Warum Software-Tests mit funktionalen Hardware-Tests nicht kombinieren? Wenn die Software während eines ESD-Tests läuft, dann sehe ich z.B. nicht nur, ob die Hardware die Bitkipper der Sensorwerte am Bus erkennt, sondern auch, ob die Software eine solide Ersatzreaktion anbietet. Ich denke, es gibt in so manchen Firmen ungenutztes Potential, weil die Testdokumentation zu wenig zwischen verschiedenen Interessensgruppen ausgetauscht wird.

Anregungen zum Weiterlesen

Die eingangs erwähnte Artikelserie zum Thema Test hat trotz einiger Jahre am Buckel nur wenig an Aktualität eingebüßt. Die Nomenklatur folgt schon dem ISTQB-Glossar. Ergänzt mit Information über automatische Code-Analyse [7] und das Erkennen von Race Conditions [9] haben Sie viel Stoff zum Lesen und eine Übersicht über die wichtigsten Testtechniken.

In nächster Zeit ist damit zu rechnen, dass zu den wichtigen Testtechniken auch der modellbasierte Test hinzukommt, der den Sprung in die Industrie längst geschafft hat, aber noch geringe Verbreitung erfährt. Auch wenn Artikel [12] noch Gültigkeit hat, so ist seine Liste der Normen auf dem Gebiet des Testens nicht mehr aktuell. Da hat sich in den letzten Jahren viel getan. Der IEEE-Standard 829 ist 2008 gründlich überarbeitet worden und speziell im Automotive-Bereich gibt es eine Reihe von branchenspezifischen Neuerungen.

Auch die früher einmal korrekte Behauptung, dass es wenig Literatur zum Thema Software-Test gibt, stimmt nicht mehr. Eine große Zahl von Büchern ist nun erhältlich. Auch Bücher mit dem Titel „Testen von Embedded Software“ habe ich schon durchblättert. Leider sind viele dieser Bücher so voll von bla-bla, dass ich mich weigere, hier eine Empfehlung abzugeben. Glücklicherweise gibt es nun aber auch Bücher neueren Datums, die ich guten Gewissens für Embedded-Software-Tester empfehlen kann.

Zum einen wäre da Peter Liggesmeyers Buch [14]. Das Buch erhebt nicht den Anspruch, Spezialliteratur für hardwarenahe Software zu sein. Der Autor kommt aber aus der Embedded-Ecke und das tut beim Lesen sehr gut. Ich schätze an seinem Buch die Bewertung der vorgestellten Techniken. Liggesmeyer stellt auch Techniken vor, die (noch) nicht etabliert sind, und gibt Gründe dafür an. Dem Leser werden damit nicht nur Techniken vor die Füße geworfen, sondern er bekommt ein gutes Gefühl dafür, welche Testtechniken er in einem Projekt welcher Integritätsanforderung auch tatsächlich einsetzen sollte.

Was mir ein wenig in seinem Buch fehlt, ist ein Ideenkatalog für ungewöhnliche (nicht-funktionale) Tests. Solche Testideen werden im Buch von Graham Bath und Judy McKay [6] zur Genüge vorgestellt. Dieses Buch ist für Personen mit Grundlagenwissen gedacht, das durch das Lesen von entweder [14] oder [15] erworben werden kann. Ich halte es für eines der wenigen Bücher zum Thema Software-Test, die spannend zu lesen sind. Zumindest die erste Hälfte. Ich muss zugeben: die zweite Buchhälfte hätte man in geraffterer Form bringen können. Die Praxisbeispiele des Buchs kommen leider großteils aus der kommerziellen Datenverarbeitung und haben für hardwarenahe Programmierung daher geringen Wert.

Zu guter Letzt möchte ich Sie noch ermuntern, sich mit mir über Software-Testing per E-Mail oder bei Tagungen auszutauschen. Gerne unterstütze ich Sie bei kniffligen Problemstellungen, ebenso wie ich gerne von Ihnen Neues lerne.