Rechtliche Belange des Software-Tests bei eingebetteten Systemen – Teil 2

Testpersonen – darf der Entwickler seine eigene Software testen?

Je nach SIL fordert die EN 61508 für bestimmte Verifikationsaufgaben Personen aus dem Umfeld des Projekts, die aber nicht gleichzeitig die zu verifizierende Funktion entwickeln, bis zu Teams von Fremdfirmen. Bei der Frage, wer die Modultests durchführen soll, der Entwickler selbst oder ein Kollege, bleibt sie aber Antworten schuldig. Auch zeitgenössische Literatur [4] stellt für diese Frage zwar Für und Wider der beiden Optionen dar, gibt aber keine klare Empfehlung. In vielen Firmen ist es gängige Praxis, dass Modultests vom Entwickler selbst durchgeführt werden. Nach unserer Ansicht ist es daher auch bei der Software- Entwicklung von sicherheitsrelevanten Systemen zulässig, wenn der Entwickler den Modultest für seinen eigenen Code entwirft. Zumindest für Module, die direkt Sicherheitsfunktionen implementieren, ist aber zumindest eine Review der Modultests durch einen sachkundigen Kollegen ratsam. Die EN 61508 formuliert zur Verifikation des Entwurfs eines Software-Moduls kryptisch:

Nachdem der Entwurf jedes Software- Moduls spezifiziert wurde, muss die Verifikation berücksichtigen, ob die spezifizierten Tests für jedes Software- Modul den spezifizierten Entwurf der Software-Module angemessen erfüllen.

Ob die „angemessene Erfüllung“ eine unabhängige Inspektion oder die Erfüllung einer Testabdeckung ist, wird in der EN 61508 nicht weiter erläutert. jk

Literatur

Teil 1 dieses Beitrags ist in Elektronik 2009, H. 3, Seite 39ff. erschienen.
[1] Erben, M.; Günther, W.; Sedlmeier, T.; Lederer, D.; Amsler, K.: Legal Aspects of Safety Designed Software Development, Especially under European Law. ERTS 2006, 25. – 27. Jan. 2006. Text abzurufen unter www.kanzlei-dr-erben.de/Texte/ERTS2006.pdf.
[2] Grünfelder, S.: Anforderungen im Griff. Elektronik 2007, H. 15, S. 42 bis 46.
[3] Wolf, G.: Embedded Rechtsstreit. Elektronikjournal 2006, H. 11, S. 96 bis 97.
[4] Liggesmeyer, P.: Software-Qualität. Spektrum Akademischer Verlag, 2002.
[5] Grünfelder, S.: Den Fehlern auf der Spur. Teil 1: Das Handwerk des Testens will gelernt sein. Elektronik 2004, H. 22, S. 60 bis 72.
[6] Grünfelder, S. Langmead, N.: Den Fehlern auf der Spur. Teil 2: Modultests, Isolationstests, Testdesign und die Frage der Testumgebung. Elektronik 2004, H. 23, S. 66 bis 75.
[7] Grünfelder, S.: Den Fehlern auf der Spur. Teil 3: Der Integrationstest, das ungeliebte Stiefkind des Testprozesses. Elektronik 2005, H. 13, S. 48 bis 53.
[8] Grünfelder, S.: Den Fehlern auf der Spur. Teil 4: Systemtests – die letzte Teststufe ist alles andere als eine exakte Wissenschaft. Elektronik 2006, H. 14, S. 45 bis 51.
[9] Grünfelder, S.: Automatische statische Code-Analyse. Elektronik 2005, H. 9, S. 48 bis 53.
[10] Grünfelder, S.; Griesauer, F.: Guter Code braucht Ordnung. Teil 1: Universelle Regeln zur Namensgebung und zu Zahlenformaten in Programmiersprachen. Elektronik 2001, H. 18, S. 52 bis 59.
[11] Grünfelder, S.; Griesauer, F.: Guter Code braucht Ordnung. Teil 2: Das Code-Layout. Elektronik 2002, H. 8, S. 74 bis 81.
[12] Grünfelder, S.: Guter Code braucht Ordnung. Teil 3: Fehlervermeidung bei der Erstellung von C-Programmen. Elektronik 2002, H. 14, S. 66 bis 71.
[13] Hayhurst, K.; Veerhusen, D.; Chilenski, J.; Rierson, L.: A Practical Tutorial on Modified Condition/Decision Coverage. NASA/TM-2001–210876.
[14] Schuppenhauer, R.: Grundsätze für eine ordnungsgemäße Datenverarbeitung. S. 335 bis 343, IDW-Verlag 1998, ISBN 3-8021-0752-7.
[15] Bergsmann, J.: Sachverständigenverfahren vor dem Landesgericht Linz, 3/2000. [16] Bergsmann, J.: Sachverständigenverfahren vor dem Bezirksgericht Eferding, 5/2007.