Bei langlebiger Software lauern die meisten Fehler in dem Code, der kürzlich verändert wurde. Das belegen Forschungsarbeiten genauso wie unser Bauchgefühl. Viele Teams setzen deshalb Test-Gap-Analyse ein, ein Verfahren, das ungetestete Änderungen automatisiert aufdeckt. Unsere Erfahrung zeigt jedoch, dass oft mehr Test-Gaps aufgedeckt werden, als wir testen können. Daher möchten wir Test-Gaps nach ihrem Risiko priorisieren. Im Vortrag stelle ich Forschungsergebnisse vor, die hierfür verschiedene Eigenschaften der Codeänderungen berücksichtigt, und berichte, wie gut dieser auf Softwaresystemen der Munich Re und der LV 1871 funktioniert.

Zielgruppe: Tester, Test Manager, Testautomatisierer, Entwickler, Architekten
Voraussetzung: Interesse an Software-Qualität und Testen
Level: Basic

Extended Abstract:

Bei langlebiger Software lauern die meisten Fehler in dem Code, der kürzlich verändert wurde. Das belegen empirische Forschungsarbeiten seit langem und unser Bauchgefühl vermutlich seit noch viel Längerem. Deshalb legen wir im Softwaretest üblicherweise besonderes Augenmerk auf Funktionalität, die wir seit dem letzten Test geändert haben. Viele Teams setzen dafür heute Test-Gap-Analyse ein, ein Verfahren, das Test-Gaps (ungetestete Änderungen) automatisiert aufdeckt und uns damit ermöglicht, unsere Testaufwände präzise zu steuern.

Unsere Erfahrung zeigt jedoch, dass oft mehr Test-Gaps aufgedeckt werden, als (rechtzeitig) getestet werden können. Daher möchten wir die Test-Gaps nach dem mit der Änderung verbundenen Risiko priorisieren. Dabei berücksichtigen wir verschiedene Eigenschaften der Codeänderung, wie beispielsweise die Zentralität der Funktionalität, die Komplexität der Änderungen und Veränderungen der Codequalität.

Im Vortrag stelle ich diesen Ansatz vor und berichte, wie gut er in verschiedenen Forschungsstudien auf Softwaresystemen der Munich Re und der LV 1871 funktioniert hat.