Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Regressionstest: Ihre Software-Versicherung

Freitag 22. April 2016

Unter einem Regressionstest verstehen Software-Tester meist die Wiederholung eines bestehenden Tests. Damit möchten sie prüfen, ob dieser Test nach einer Software-Änderung noch immer erfolgreich durchläuft.

Lesen Sie in diesem Beitrag, was Sie bei einem Regressionstest bei medizinscher Software beachten sollten.

Ziele von Regressionstests

1. Ziel: „Alter Code funktioniert noch“

Die IEC 62304 fordert eine Regressionsprüfung, die notwendig ist, um festzustellen, dass eine Änderung einer SYSTEM-Komponente deren Funktionalität, Zuverlässigkeit und Leistungsfähigkeit nicht beeinträchtigt und keine zusätzlichen Defekte verursacht hat.

Damit wird das Ziel eines Regressionstests aus Sicht der IEC 62304 klar: Durch eine Software-Änderung verursachte Fehler in bereits getestetem Code finden.

Die FDA formuliert das im Software Validation Guide fast identisch: Regression testing is the rerunning of test cases that a program has previously executed correctly and comparing the current result to the previous result in order to detect unintended effects of a software change.

2. Ziel: „Code funktioniert zuverlässig“

Ein zweites Ziel erwähnt die IEC 62304 nicht: Ein Regressionstest kann auch prüfen, ob sich eine Software dauerhaft gleich verhält, ohne dass man sie ändert. Solche Prüfungen empfehlen sich, wenn sich die Software nicht streng deterministisch verhält, z.B.

  • bei Race-Conditions
  • bei Änderungen an der Laufzeitumgebung, beispielsweise der Hardware oder dem Betriebssystem
  • oder bei der Abhängigkeit von (sich ändernden) Daten.

Regressionstest: Regulatorische Anforderungen

Anforderungen der IEC 62304

Regressionstest während der Integrationsprüfung

Die IEC 62304 fordert, Regressionsprüfungen / Regressionstests im Rahmen der Integrationsprüfung / Integrationstests. Damit soll sichergestellt werden, dass bei der Integration von Komponenten in einen bereits integrierten Teil von Komponenten keine Fehler eingeführt werden. Welche Fehler das sein könnten, beschreibt die Norm nicht.

Regressionstest bei Änderungen am Software-System

Erwartungsgemäß fordert die Norm eine Regressionsprüfung bei Änderungen am Software-System. Auch bei kleinen Änderungen, wie sie betont.

Die Hersteller müssen zudem begründen, wenn sie nach einer Änderung nicht alle Regressionstests erneut durchführen. Zu diesem Punkt lesen Sie weiter unten mehr.

Anforderungen der FDA

Regressionstest bei Änderungen an der Software

Die FDA betont, dass 79% aller Software-Fehler bei der Änderung einer bereits freigegebenen Software eingeführt werden. Entsprechend betont sie die Notwendigkeit von Regressionstests im Software Validation Guide:

Whenever software is changed, a validation analysis should be conducted not just for validation of the individual change, but also to determine the extent and impact of that change on the entire software system. Based on this analysis, the software developer should then conduct an appropriate level of software regression testing to show that unchanged but vulnerable portions of the system have not been adversely affected. Design controls and appropriate regression testing provide the confidence that the software is validated after a software change.

Ähnlich wie die IEC 62304 verlangt die FDA die Regressionstests und eine Analyse, welche Teile der Software nochmals zu prüfen sind.

Regressionstest während der Integrationsprüfung

Analog zur IEC 62304 findet sich auch die Forderung bezüglich der Integration:

Regression analysis and regression testing should also be employed when using integration methods to build a software product to ensure that newly integrated modules do not adversely impact the operation of previously integrated modules.

Möglichst jeden Test als Regressionstest durchführen

Ein besonderes Augenmerk hat die FDA auf dem Konfigurationsmanagement und der Fähigkeit von (allen) Tests, im Rahmen des Regressions-Testings wiederholt werden zu können:

Test procedures, test data, and test results should be documented in a manner permitting objective pass/fail decisions to be reached. They should also be suitable for review and objective decision making subsequent to running the test, and they should be suitable for use in any subsequent regression testing.

Welcher Teil der Software muss Regressions-getestet werden?

Die kurze Antwort auf diese Frage lautet: Das gesamte Software-System mit allen Tests, es sei denn, Sie können einen kleineren Testumfang begründen.

Es gibt somit zwei Stellschrauben, über die Sie den Testumfang reduzieren können:

  1. Die Größe des Testobjekts (sprich ganzes Software-System oder nur Teile)
  2. Die Testziele, also auf welche Qualitätseigenschaften Sie eine Software hin überprüfen. Einen Überblick über mögliche Qualitätseigenschaften verschafft Ihnen die ISO 25010.

Ad 1. Beschränkung der Größe des Testobjekts

Wenn Sie bei einer Änderung an einem Teil eines Software-Systems nur eben diesen Teil einer Regressionsprüfung unterwerfen wollen, dann müssen Sie darlegen, weshalb sich diese Änderung nicht auf andere Teile des Software-Systems auswirken kann.

Diese Begründung wird Ihnen am besten anhand einer dokumentierten Software-Architektur gelingen. Diese sollte nämlich aufzeigen:

  1. die Abhängigkeiten anderer Komponenten von der geänderten Komponente,
  2. die Schnittstellen, über die diese Abhängigkeiten realisiert sind.

Ad 2. Beschränkung der Testziele

Besonders bei „nicht-funktionalen Anforderungen“ wie der Performanz oder der Portierbarkeit gelingt eine ausschließliche Argumentation über die (statische) Software-Architektur oft nicht. Allerdings sind die Begründungen offensichtlich. Beispiele:

  • Durch die Änderung eines Algorithmus wird sich die Portierbarkeit der Software wahrscheinlich nicht beeinflusst.
  • Wenn im Rahmen eines Unit-Tests nachgewiesen werden kann, dass die Performanz einer Komponente unverändert ist, ist eine Änderung der Performanz des gesamten Systems unwahrscheinlich.

Diese Möglichkeit, Regressionstests nach Art des Testziels auszuwählen bedingt jedoch, dass die Tests auch danach klassifiziert und aufgeteilt sind.

Regressionstest: Best Practices

Regressionstests sind Kennzeichen einer professionellen Software-Entwicklung. Sie sind Ihre „Versicherung“, Ihre Leitplanken bei v.a. bei Software-Änderungen.

Regressionstest: Anteil kontinuierliche erhöhen

Abb. 1: Erhöhung der Testabdeckung durch Testen von neuem und geändertem Code

Falls Sie noch keine umfassenden Regressionstests durchführen, wären das meine Tipps:

  • Automatisieren Sie, was automatisiert werden kann.
    Das ist eine anfängliche Investition, die sich rechnet. Wenn Sie Kapazitätsprobleme haben, dann denken Sie über einen Bachelor- oder Master-Studenten/Studentin nach, der/die im Rahmen seiner/ihrer Arbeit eine Testinfrastruktur aufbaut. Wer nicht in einen Regressionstest investiert, gleich demjenigen, der sagt, er habe keine Zeit, seine Säge zu schärfen, weil er mühsam so viel Holz sägen muss.
  • Erhöhen Sie den Anteil der Regressionstests
    Für bestehenden Code werden die meisten keine Tests mehr „nach-schreiben“ wollen. Dann legen Sie fest, dass alle geänderten und alle neuen Code-Teile in einer Regressions-Suite eingehängt werden müssen. So erhöhen Sie im Lauf der Zeit kontinuierlich den Anteil des automatisiert getesteten Codes (s. Abb. 1).
  • Verbessern Sie Ihre Software-Architektur
    Die Aussage, dass sich ein Code nur schwer (z.B. nur mit Hardware) testen ließe, ist ein deutliches Indiz, dass der Code suboptimal strukturiert ist. Ein Hardware-Abstraction-Layer, ein Architektur-Refactoring und mehr Ausbildung im Bereich des Software-Testings können Wunder bewirken.
  • Lassen Sie die Tests möglichst häufig laufen
    Ein automatisierter Build mit einem Tool wie Jenkins oder TestAF hilft Ihnen, Fehler früh zu finden und zu eliminieren und so einen unerwarteten Projektverzug kurz vor dem Release zu vermeiden.

 


Kategorien: Software & IEC 62304
Tags:

Kommentar schreiben