Testen im ALM

Mit den steigenden Ansprüchen an Softwaresysteme hinsichtlich Funktionalität, Zuverlässigkeit und Sicherheit, steigt auch deren Komplexität. Um die Funktionsweise und eine hohe Qualität dieser Softwaresysteme sicherzustellen, ist es notwendig diese ausführlich zu testen. Das Testen nimmt damit einen nicht zu unterschätzenden Faktor im ALM ein.

In diesem Blog werden zwei bekannte Testverfahren betrachten, die in der Entwicklungsphase des ALM Prozesses zur Anwendung kommen können.

Die beiden Testverfahren, die in diesem Blog gegenübergestellt werden, sind Blackboxtest und Whiteboxtest.

Blackboxtest       

Bei dieser Art von Testen ist der innere Aufbau bzw. die genaue Funktionsweise des entwickelten Softwaresystems nicht bekannt. Die Tests werden auf Basis von Anforderungen aus Spezifikationen abgeleitet und definiert. Diese Art von Tests wird z.B. im Rahmen der Abnahme durchgeführt. Hierbei ist es das Ziel, das Übereinstimmen des Systems mit der Anforderungsspezifikation, welche die Kundenanforderungen enthält, sicherzustellen.

Whiteboxtest

Bei dieser Art von Testen hingegen sind der innere Aufbau, wie die Systemarchitektur und die Funktionsweise des Systems bekannt. Auch der Quellcode ist bekannt und kann für die Testerstellung verwendet werden. Sie werden häufig in Form von automatisierten Tests realisiert. Da die Implementierung beim Whiteboxtest bekannt ist, kann dadurch beispielsweise auch die Branch Coverage oder Path Coverage in ihren unterschiedlichen Ausprägungen geprüft werden.

Zusammenfassend ist zu sagen, dass es nicht ausreicht nur eine der o.g. Testarten bei einer Softwareentwicklung zu verwenden. So können z.B. alle Tests bei einem Whiteboxtest erfolgreich bestanden werden, aber dennoch das System nicht das leistet, was in den Kundenanforderungen beschrieben ist. Umgekehrt ist bei erfolgreichen Blackboxtests die Korrektheit des Systems nicht sichergestellt, da bei den Tests evtl. nicht alle möglichen Programmpfade durchlaufen werden. Aus diesen Gründen ist es notwendig beide Arten zu verwenden und so zu kombinieren, damit die Funktionsweise eines Systems sichergestellt wird. Hierbei spielen auch der Kosten-Nutzen Faktor eine Rolle in welchem Umfang und in welcher Art getestet wird.

Wenn Sie mehr über das Testverfahren, die Anwendung und die Integration im ALM erfahren möchten, dann werfen Sie doch einen Blick auf unser Schulungsangebot.

http://www.hood-group.com/no_cache/schulungen/details/show-seminar/application-lifecycle-management-alm-fuer-software-engineering-professionals-fundierte-methode/

Karsten Krennrich

Kontaktieren Sie Karsten Krennrich

Herr Karsten Krennrich ist als Consultant der HOOD Group tätig. Seine Schwerpunkte liegen in der Beratung von Requirements Engineering (RE) orientierten Entwicklungsprozessen. Er ist als Projektleiter bei der HOOD Software Division verantwortlich für die Realisierung von Softwarelösungen im Bereich der Entwicklungsprozess unterstützenden Werkzeuge. Für diese Anpassungen und Erweiterung von Standard Werkzeugen erarbeitet Herr Krennrich auch die zur Realisierung notwendigen Konzepte. Bei deren Implementierung arbeitet Herr Krennrich unter anderem auch mit den Konfigurationsmanagement Werkzeugen CMSynergy und Subversion. Neben dem RM-Werkzeug DOORS® von IBM hat Herr Krennrich auch Praxiserfahrungen mit den Werkzeugen CaliberRM® von Borland und RequisitePro® von IBM. Er verfügt außerdem über Erfahrungen im Bereich Datenbanken und Informationssysteme, im Software Engineering und im Themenbereich Produktlinien.