Im ersten Teil des Blogs habe ich den Begriff „Implizites Testen“ definiert und Ursachen dafür diskutiert.
Im zweiten Teil geht es nun um die Nachteile solcher Tests und um Lösungsansätze um möglichst diese Nachteile gar nicht erst entstehen zu lassen.

Nachteile von implizitem bzw. indirektem Testen?

Wenn man Projekte im Nachhinein analysiert, dann stellt man fest, dass es einen Zusammenhang gibt, zwischen impliziten Tests und der Anzahl NICHT gefundener Fehler. Durch implizites Testen verliert man eine wesentliche Stärke des Requirements basierten Testens, nämlich dass man die Funktionalitäten eines Systems in kleinen Häppchen in Requirements definiert und diese dann alle vollständig in Tests nachweist. Implizites Testen macht das gerade nicht mehr. Es werden oft ganze Requirements gar nicht mehr explizit nachgewiesen. Das kann man auch an dem Beispiel Requirement aus dem ersten Teil des Blogs gut sehen:
Req. A: Wenn Weight on Wheels = TRUE am Discreten Input DS 1 anliegt dann sollen die Software Flags SWW1 = TRUE und SWW2 = FALSE gesetzt werden.
Req B: Wenn SWW1 = TRUE und SWW2 = FALSE sind dann soll die AFDX Msg „ON_GROUND gesendet werden.

Ob die interne Software Variable wirklich so stehen wie im Req. beschireben ist, wenn die Bedingungen aus Req. A erfüllt sind wird nicht gezeigt. Ebenso wird nicht explizit durch einen Test bewiesen, dass die Variablen entsprechend gesetzt sein müssen um die Reaktion gemäß Req. B auszulösen.
Bei steigender Systemkomplexität steigt nun die Gefahr, dass man Fehler im System durch den Test nicht mehr findet.
Neben einer nicht adäquaten Testumgebung kann die Ursache für implizites Testen auch der Versuch sein die Architektur eines Systems per Tests nachzuweisen. Statt die Architektur grafisch zu definieren, werden oft textuelle Requirements erstellt, die dann eben nur implizit testbar sind. Aus Kosten/Nutzen Gesichtspunkten kann man klar sagen, dass diese Art von textuellen Requirements überwiegend nutzlos sind. Ohne diese Art von Requirements hätte man die gleiche Produktqualität erreicht, aber zu günstigeren Kosten.
Technisch gesehen, hat man den Vorteil, wenn solche Requirements nicht vorhanden sind, dass die Dokumentation deutlich verständlicher, übersichtlicher und transparenter wird.
Generell leiden viele Projekte heutzutage eher unter zu vielen, als unter zu wenigen Requirements. Architekturbeschreibungen in Form von Requirements, sowie die Definition von Requirements auf der falschen Ebene sind die wesentlichen Ursachen dafür.

Lösungsansätze:

Nachfolgend einer grober Überblick über erfolgsversprechende Lösungsansätze um implizites Testen zu minimieren und dadurch die Effizienz und den Kosten/Nutzenfaktor im Projekt deutlich zu steigern:

• Bewusste Strategie für die Erstellung von Requirements von Anbeginn des Projektes
  • Umgang mit unterschiedlichen Kategorien von Requirements
  • Definition der Requirements auf der angemessenen Ebene
  • Für 90% oder mehr aller Embedded Systeme Definition von höchstens 2 Ebenen von Requirements
  • Individuelle Festlegung der Testebene bzw. Testumgebung für jedes Requirement
• Definition einer effizienten Teststrategie von Anbeginn des Projektes
  • Definition und bewusste Anwendung einer Systemtestumgebung
  • Definition und bewusste Anwendung einer HW/SW Integrationstestumgebung
  • Bei Projekten mit hohem Softwareumfang oder bei sicherheits-relevanten Projekten Definition und bewusste Anwendung einer SW/SW Integrationstestumgebung

Weitere HEICON Blog Beiträge zum Thema

• Implizites Testen – Eine gute Idee (Teil 1)?
• Testen von Plattformen: Eine spannende Herausforderung!
• Managementaspekte des Testens
• Psychologie des Testers

Wenn Sie weitere Fragen zum Thema haben, dann unterstützt Sie HEICON gerne. Senden Sie eine Mail an: info[at]heicon-ulm.de.