Funktionale Sicherheit Automotive-Software: Vom Qualitätsmanagementsystem zum Testmanagement

Vom Software-Qualitätsmanagementsystem der ISO 9001-Zertifizierung zum Automotive-Software-Testmanagement nach ISO 26262: Der Artikel beleuchtet die wichtigsten Faktoren, um die Einhaltung und Überprüfung der Software-Qualität nach dem „Stand der Technik“ erfolgreich zu managen.

Jenseits der Luft- und Raumfahrt gibt es kaum einen Anwendungsbereich, in dem die zuverlässige und sichere Funktion aller Einzelanwendungen so entscheidend ist wie in der Automobilindustrie. Nicht zuletzt mit dem Trend zum Software-definierten Fahrzeug (Software-defined Vehicle, SDV) nimmt auch in diesem Sektor der Anteil der Software immer mehr zu – und damit steigen die Anforderungen an die Qualität der Automotive-Software. Die Durchführung von Automotive-Projekten setzt grundsätzlich schon mal voraus, dass das Entwicklungsunternehmen IATF 16949- und ISO 9001-zerifiziert ist. Bereits die ISO 9001 Zertifizierung fordert ein Software-Qualitätsmanagementsystem oder Software-Testmanagement nach ISO 29119.

Weiterhin stellt die sicherheitsrelevante Entwicklung von Automotive-Software hohe Anforderungen an ihre Verifikation, die nach den Vorgaben der ISO 26262 zu erfolgen hat. Aus den ASPICE-Prüfungsanforderungen ergeben sich weitere konkrete Vorgaben an das Software-Testmanagement. Zusätzlich fordern die Auftraggeber in der Regel den Nachweis des ASPICE-Reifegrad 2 durch ein ASPICE-Assessment.

Das ist eine Managementaufgabe, die von der Rolle des Software-Testmanagers mit den erforderlichen Skills umgesetzt werden muss. Dabei gilt es sicherzustellen, dass das bestehende Software-Qualitätsmanagementsystem die Anforderungen aus ISO 26262 und ASPICE stemmen kann, bevor das Automotive-Projekt unerwartete Kosten verursacht.

Software-Qualitätsmanagementsystem nach ISO 9001

Die ISO 26262 fordert im Absatz 5.4.5 der ISO 26262-2:2018 als Unterstützung für das „Overall safety management“ ein Software-Qualitätsmanagementsystem. Das ergibt sich aus der ISO 90003, einer direkten Ergänzung zur ISO 9001 zum Thema Software-Entwicklung.

Der Abschnitt 8.4.8.8 weist darauf hin, dass die Durchführung und Planung von spezifischen Software-Tests zu Verifikation- und Validierungsmaßnahmen gehören. Die Implementierung eigener Software-Testprozesse und einer Testorganisation sollte auf Basis der ISO 29119-Reihe erfolgen. Der Normen-Zusammenhang zum Software-Testmanagement ist schematisch in Bild 1 dargestellt.

Aufgabe des Software-Testmanagement

Die ISO 29119-1 beschreibt die Aufgabe des Software-Testmanagement, wie folgt: „Testmanagement ist die Planung, Terminierung, Schätzung, Überwachung, Berichterstattung, Kontrolle und der Abschluss von Testaktivitäten.“ Die Umsetzung in Form von Prozessen und Methoden steht im Software-Testmanagement-Handbuch. In seinem Einführungskapitel sollte in Abstimmung mit der „Test Policy“ des Unternehmens die Aufgabe formal beschrieben sein. Hier ein möglicher, sachlich korrekter Formulierungsvorschlag:

„Das Software-Testmanagement ist eine Säule der Qualitätssicherung. ASPICE formuliert: “Qualitätssicherung erfolgt unabhängig und objektiv ohne Interessenkonflikte”. Das bedeutet für das Software-Testmanagement, das es seine Ergebnisse ebenfalls unabhängig und objektiv ohne Interessenkonflikte liefert.

Sein primäres Ziel ist es, Nachweise und Beweise für eine korrekte Umsetzung der spezifizierten Konstruktion zu erbringen. Dies geschieht durch Verifikation und Validierung der Testobjekte gegen die Anforderungen und die Spezifikationen.

Das sekundäre Ziel, häufig als Ziel des Testens (Testdurchführung) bezeichnet, ist das Auffinden von Abweichungen und Fehlfunktionen hinsichtlich nicht korrekt umgesetzter Anforderungen bzw. Spezifikationen. Sie sichern die Qualität der Konstruktion (Produktqualität).“

Im Release-Audit ist der Software-Testmanager ein zwingend erforderliches Mitglied. Er hat das verbleibende Restrisiko in der Software (SW) zur Freigabe zu beurteilen. Eine verantwortungsvolle Entscheidungsfindung, die es zu einer anspruchsvollen und „echten“ Management-Aufgabe machen.

Software-Testmanagement in der Unternehmens- und Projektorganisation

Das Software-Testmanagement muss passend zu seiner Aufgabe in der Projekt- und Unternehmensorganisation aufgestellt sein und diese dürfen sich nicht gegenseitig ausschließen. Innerhalb der Projektorganisation zeigt Bild 2 links zulässige und rechts unzulässige Aufstellungen. Zulässig (grüner Haken) sind die Aufstellungen direkt neben dem Projektmanagement oder als Teil des Qualitätsmanagements. Unzulässig sind sie unter dem Projektmanagement oder Teil der Softwareentwicklung, wie im Bild dargestellt. Eine objektive SW-Testmanagement-Tätigkeit ohne Interessenkonflikte ist hier nicht möglich.

Eine zulässige Projektorganisation kann aufgrund einer unzulässigen Position der Rolle SW-Testmanager auf Unternehmensebene ausgehebelt werden. Eine solche inkorrekte Situation zeigt Bild 3. Sie basiert auf der nicht seltenen Meinung, dass zur Software-Entwicklung auch der Software-Test gehört. Die Weisungsbefugnis des SW-Leiters gegenüber dem SW-Testmanager erlaubt kein objektives Testmanagement und Interessenkonflikte sind absehbar.

Prinzipiell ist darauf zu achten, dass sich Projekt- und Unternehmensorganisation nicht widersprechen und die Unabhängigkeit des SW-Testmanagements gewahrt bleibt.

Software-Testmanagement-Handbuch

Eine zentrale Aufgabe des Testmanagers ist die Beschreibung der Methoden und Prozesse zur Umsetzung der Testmanagementaufgabe in einem Software-Testmanagement-Handbuch. Dieses sollte neben einer formalen Aufgabenbeschreibung (siehe Beispiel zuvor) folgende Inhalte behandeln:

• Die Testmanagement-Prozesse und -Methoden,

• die dynamischen Testprozesse und Methoden,

• die notwendigen Rollenbeschreibungen zur Umsetzung aller Testprozesse und

• die resultierenden Arbeitsprodukte aus den Prozessschritten.

Die ISO 29119 macht zu den Prozessen Vorschläge. Der Testmanager hat darauf zu achten, dass seine Prozesse und Methoden die Anforderungen der ISO 26262 und die ASPICE-Erwartungen erfüllt. Zum „Fundamentalen Testprozess“ des ISTQB (Bild 4) gibt es überaus starke Parallelen. Der ISTQB integriert auf kompakte und übersichtliche Art und Weise die „Testmanagement-Prozesse (blau)“ und „Dynamische Testprozesse (grau)“ in seinen Prozess.

Testplanungsprozess

Der Testplanungsprozess beschreibt neun Prozessschritte und -aktivitäten innerhalb eines „Projekt-Testplans“. Der Hinweis iterativ meint, dass diese Schritte wiederholt auszuführen sind, um zu einem verfeinerten, akzeptablen Ergebnis zu kommen:

• Schritt 1: Den Kontext verstehen

• Schritt 2: Organisieren Sie die Testplanentwicklung

• Schritt 3: Identifizieren und analysieren Sie Risiken (iterativ)

• Schritt 4: Ermitteln Sie Risikomigrationsansätze (iterativ)

• Schritt 5: Entwerfen Sie die Teststrategie (iterativ)

• Schritt 6: Bestimmen der Ressourcen und des Zeitplans (iterativ)

• Schritt 7: Testplan aufzeichnen/erstellen

• Schritt 8: Erzielen Sie einen Konsens über den Testplan

• Schritt 9: Kommunizieren Sie den Testplan und machen ihn verfügbar.

Üblicherweise wird ein erster vager Entwurf des Projekt-Testplans sofort nachdem Projekt-Kickoff des Projektmanagers im Rahmen der „Work Breakdown Structure“ vom Projektmanager gefordert. Dieser erste Plan beruht hauptsächlich auf Schätzungen basierend auf Erfahrung.

Das SW-Testmanagement sollte zu seinen Glaskugel-Aussagen hinsichtlich der Planung Eingangskriterien festgelegen, damit das Projektmanagement sie nicht als uneingeschränkt verbindlich betrachtet kann. Erst kurz vor dem ersten Software-Release wird die Planung ausreichend verfeinert sein.

Neben dem Projekttestplan ist ein eigenes Risikoregister empfehlenswert.

Testüberwachung und -steuerung

Im Prozess „Testüberwachung & -steuerung“ (ISO 29119-2) sind die nachstehenden Testprozessschritte vorgesehen:

• Schritt 1: Einrichten

• Schritt 2: Überwachen

• Schritt 3: Steuerung

• Schritt 4: Prüfbericht

Hier wird kontinuierlich der Fortschritt der Planung der „dynamischer Tests“ überprüft, überwacht und letztendlich abgeschlossen.

Die messbaren Faktoren der Überwachung werden im ersten Schritt identifiziert und im zweiten gesammelt, protokolliert und mit dem Soll-Zustand verglichen. Ebenfalls werden die Risiken aus dem Risikoregister überwacht und gegebenenfalls um neue ergänzt. Abweichungen in Hinsicht auf die erwarteten Testergebnisse und der Testdurchführung werden in Schritt 4 abgewickelt. Ein Test-Status-Report gibt Auskunft über den Teststatus und der erreichten Test-Metriken und informiert die Stakeholder über Stand der Tests. Der Zeitpunkt der „Test-Status-Reports“ sollte in der Planung enthalten sein.

Der Software-Testmanager ist ein entscheidender Teilnehmer am Release-Audit zur Freigabe der Software. Für die Entscheidung über die Freigabe ist der zeitlich passende „Test-Status-Report“ ein wichtiges Dokument zur Begründung der Entscheidung.

Testabschluss

Der „Testabschluss-Prozess“ wird in der ISO 29119-2 mit den folgenden 4 Prozessschritten beschrieben:

• Schritt 1: Testressourcen archivieren

• Schritt 2: Testumgebung aufräumen

• Schritt 3: Erkenntnisse gewinnen (Lessons Learned)

• Schritt 4: Testabschlussbericht

Er hat zur Aufgabe,

• die Testbasis für alle Tests,

• die verwendeten Tools,

• alle zum Projekt gehörenden Testprojekte inkl. Testfallspezifikationen,

• alle Testergebnisse und Test-Reports und

• alle Arbeitsprodukte (Testplan, Risikoregister),

• den Testabschlussbericht, mit Baseline versehen, verfolgbar zu archivieren.

Ein abschließendes „Lessons Learned“ schafft mögliche Verbesserungen für weitere Testprojekte.

Rollen im Software-Testmanagement

Ein wichtiges Personal-Thema sind die Rollenbeschreibungen des Software-Testmanagements. Sie sind ebenfalls Bestandteil des „Test-Handbuchs“. Sie sind eine wichtige Personaleinstellungsgrundlage und dienen dem Aufbau eines Test-Teams, das zur Umsetzung der Testprozesse in der Lage ist und die Testprozesse leben kann. Je nach Aufbau und Struktur einer Testorganisation sind verschiedene Rollen empfehlenswert oder ratsam.

Der ISTQB und die ISO 29119 kennen folgende bekannte Rollen:

• Leitender Testmanager (Test Director)

• Testmanager (Test Manager)

• Teststratege (Test Strategist)

• Tester

• Testarchitekt.

Arbeitsprodukte

Es ist empfehlenswert im Projekt-Testplan eine Matrix der Arbeitsprodukte darzustellen. Sie sollte für die jeweilige Teststufe Ablauf-orientiert die entstehenden Arbeitsprodukte aufzeigen. Dazu gehören Testpläne und -zeitpläne, Protokolle der Testpläne und den SW-Integrationstestpläne für den Review und weiterführend für das Reporting bis hin zu einem Testabschlussreport (Bild 5). (se)

* Wolfgang Rohé ist verantwortlich für die Themen Test Management & Test Prozesse bei Razorcat Development GmbH

(ID:50103027)