Automotive SPICE® SWE.6: Test zur Software-Qualifizierung

Was ist ein Software-Qualifizierungstest? Die Erwartung ist, dass Sie bereits Softwareanforderungen haben. Ziel ist es daher, diese Anforderungen zu überprüfen und festzustellen, ob sie vollständig erfüllt und korrekt implementiert sind.

Da der Prozess kurz vor Auslieferung der Software durchgeführt wird (entweder direkt an den Kunden oder als Basis für das System), besteht eine enge Verbindung zum Projektmanagement (MAN.3), dem Konfigurationsmanagement (SUP.8), der Produktfreigabe (SPL.2) und natürlich der Software-Anforderungsanalyse (SWE.1).

Wenn der Software-Qualifizierungstest nicht gut funktioniert, können Fehler unerkannt bleiben und die Kundenzufriedenheit sinkt. Die Testumgebung ist produktabhängig. Beispiele sind SIL, PIL oder HIL.

Im Folgenden sind die wichtigsten Aspekte des Software-Qualifizierungstests in Automotive SPICE® dargestellt.

• Sie benötigen eine klare Teststrategie. Wie alle Test- und Unterstützungsprozesse erfordert der Software-Qualifizierungstest die Entwicklung und Festlegung einer Teststrategie. Vielleicht haben Sie für jede Teststufe eine separate Teststrategie. Es ist jedoch besser, eine alle Teststufen umfassende Strategie zu entwickeln und zu koordinieren. So werden alle Anforderungen abgedeckt und Redundanzen vermieden.

  Die Teststrategie sollte folgende Themen abdecken:

  • Das betreffende Testobjekt

  • Die Methoden zur Entwicklung von Testfällen und Testdaten (z. B.Entwicklung von Positiv-/Negativtests, Äquivalenzpartitionierung).

  • Eine Regressionsteststrategie, was in der Automotive SPICE®-Terminologie bedeutet, dass Sie die Durchführung eines erneuten Tests nach einer Fehlerbehebung oder einem Änderungsantrag definieren.

  • Die Testumgebung

  • Die Testabdeckung in Bezug auf den Projektplan und den Freigabeplan

  • Ein- und Ausstiegskriterien sowie Testunterbrechungskriterien

  Natürlich ist dieser Prozess stark mit dem Problemlösungsmanagement (SUP.9) verbunden, sodass Sie entweder die Teststrategie oder die Fehlermanagementstrategie einsetzen können, um zu dokumentieren, wie mit fehlgeschlagenen Tests umgegangen wird.

• Die richtigen Testfälle auswählen. Der Prozess sieht eine Auswahl von Testfällen für die verschiedenen Tests vor. Diese hängen vom Ziel der Tests und der Abdeckung ab. Das Ziel und die Erwartung ist, dass die Software für die verschiedenen Auslieferungen auf Basis der oben genannten Teststrategie ordnungsgemäß getestet wird.

  Der Grundgedanke ist, dass für unterschiedliche Auslieferungen unterschiedliche Erwartungen gelten können. Für wichtige Auslieferungen könnten zum Beispiel alle implementierten Softwareanforderungen vollständig abgedeckt sein.

  Bei kleineren Auslieferungen wird nur das Delta der seit der letzten Auslieferung umgesetzten Anforderungen getestet.

  Natürlich müssen für diesen Ansatz die richtigen Testfälle gewählt werden.

  Eine andere mögliche Situation für die Auswahl von Testfällen wäre der Regressionstest, der Änderungsanträge und/oder Fehlerbehebungen abdeckt. Dazu werden Testfälle ausgewählt, die den Änderungsantrag oder den Fehler und die möglichen Auswirkungen abdecken. Das bedeutet, dass auch Abhängigkeiten von Anforderungen getestet werden, die von dem Änderungsantrag oder der Fehlerbehebung betroffen sein können.

• Traceability und Konsistenz sicherstellen. Zu diesem Prozess gehört auch die Nachverfolgbarkeit, die so genannte Traceability, zwischen Ihren Software-Testfällen und den Softwareanforderungen.

  Die Traceability kann durch Hyperlinks wie in DOORS, durch spezifische Traceability-Tools wie Rectify, durch Traceability-Matrizen oder durch andere verwaltbare Mittel hergestellt werden, die von Ihrer Toollandschaft unterstützt werden.

  Traceability dient folgenden Zwecken:

  • Konsistenzprüfungen, d. h.der Überprüfung auf Vollständigkeit und Korrektheit der Abdeckung der Softwareanforderungen

  • Auswirkungsanalyse (Impactanalyse) bei Änderungsanträgen oder Fehlern

  • Unterstützung der Berichterstattung über die Erwartungen der Stakeholder und Klärung, welche Anforderungen getestet wurden (Abdeckungsbericht)

  Das betrifft auch die Konsistenz, in diesem Fall zwischen den Softwareanforderungen und den Software-Testfällen. Konsistenzprüfungen dienen in der Regel dazu, die Vollständigkeit und Richtigkeit der Abdeckung zu überprüfen. Dies kann nur durch ein Review erfolgen.

  Wenn Sie nicht nachweisen können, dass Ihre Software vollständig und korrekt abgedeckt ist, veröffentlichen Sie möglicherweise eine unzureichend getestete Software. Es liegt daher in Ihrem Interesse, Konsistenz zu wahren und diesen Review ordnungsgemäß durchzuführen.

Tutorial für Fortgeschrittene zum Software-Qualifizierungstest 

Welchen Nutzen bietet der Software-Qualifizierungstest?

Diese Tests werden während der Entwicklung eines Systems durchgeführt, bevor die gesamte Software mit der Hardware und den mechanischen Komponenten verbunden wird. Damit soll sichergestellt werden, dass die Software wie erwartet funktioniert und die Softwareanforderungen erfüllt.

Was beinhaltet der Software-Qualifizierungstest?

• Die Softwareteststrategie für das Testen der gesamten Software wird festgelegt (BP1).
• So haben alle Beteiligten (Tester, Testmanager, Requirements Engineers, Projektmanager) ein gemeinsames Verständnis der durchzuführenden Arbeit (BP1).
• Änderungen an der Software dürfen keine negativen Nebeneffekte auf bereits erfolgreich getestete Anforderungen haben. Zu diesem Zweck muss eine Regressionsstrategie erstellt werden (BP1).
• Die Tests zum Nachweis der Umsetzung der Softwareanforderungen sind detailliert zu spezifizieren (BP2).
• Die Auswahl der auszuführenden Testfälle erfolgt in Übereinstimmung mit der Teststrategie, der Regressionsstrategie und dem Freigabeplan (BP3). Die Tests werden durchgeführt und die Ergebnisse protokolliert (BP4).
• Es muss eine bidirektionale Traceability zwischen Softwareanforderungen, Testfällen und Testergebnissen bestehen (BP5). Die Softwareanforderungen und die Testfälle müssen konsistent sein (BP6). Konsistenz setzt auch voraus, dass die Links der Traceability korrekt und vollständig sind. Das wird in der Regel durch ein Review sichergestellt.
• Ein Testergebnisbericht wird erstellt und den zuständigen Personen, etwa Projektleiter und Kunden, zur Verfügung gestellt (BP7).

Bidirektionale Traceability zwischen Softwareanforderungen und Software-Qualifizierungstests 

Erfahrungen, Probleme und Tipps 

• Es ist von Vorteil (aber nicht zwingend erforderlich), eine gemeinsame Teststrategie für alle Testprozesse zu haben, um Lücken zu vermeiden und Synergien zu schaffen. 
• Der Software-Qualifizierungstest ist eng mit der Software-Anforderungsanalyse verbunden (SWE.1). Die Requirements Engineers entwickeln die Verifizierungskriterien, die ihr Fachwissen und Hinweise darauf enthalten, was bei der Entwicklung der Tests zu beachten ist. 
• Die Traceability zwischen Anforderungen und Tests ist unerlässlich, um die Abdeckung der Anforderungen durch die Tests nachzuweisen und den Testfortschritt zu überwachen. Voraussetzung dafür ist eine toolgestützte Traceability durch eine gute Integration der Anforderungs- und Testtools. 
• Konsistenzprüfungen werden oft unterschätzt und schlecht umgesetzt. Hier sind Reviews erforderlich, mit denen überprüft wird, ob die Tests korrekt sind und die Anforderungen vollständig abgedeckt werden. 
• Software-Qualifizierungstest können mit jeder anderen Testart kombiniert werden, solange nachgewiesen werden kann, dass die Softwareanforderungen getestet wurden. Der Software-Qualifizierungstest wird auf der Zielhardware häufig in Verbindung mit dem System-Qualifizierungstest durchgeführt. 
• Bei Projekten mit Plattformsoftware sollten die Tests für Plattformanforderungen und die für projektspezifische Anforderungen nahtlos aufeinander abgestimmt werden. 

Vertiefen Sie Ihr Wissen über Automotive SPICE®  

Sie interessieren sich für Automotive SPICE®? Dann sind unsere Automotive SPICE® Schulungen genau das Richtige für Sie!  

Über den Autor 

Bhaskar Vanamali ist seit fast 20 Jahren im Bereich Prozessverbesserung tätig und ehemaliger Sekretär des Arbeitskreises 13 des VDA QMC. 

Er ist Principal Assessor und Trainer für Automotive SPICE® und hat bereits über 140 Assessments durchgeführt und mehr als 250 Assessoren ausgebildet. 

Das könnte Sie auch interessieren

Ressourcenleitfaden zur Automotive SPICE® Softwareverifizierung (SWE.6)

Dienstleistungen für Automotive SPICE und Erweiterungen