© best_vector/Shutterstock.com
Windows Developer
Testmanagement als Bindeglied zwischen Entwicklung und Qualitätssicherung

Brückenschlag mit ALM

Tester werden bei vielen Entwicklungsteams gerne als Buglieferant anstatt als Helfer gesehen. Bugreports werden dabei oft einfach über eine virtuelle E-Mail-Mauer geworfen. Die Folge ist, dass Testmanagement einen schlechten Ruf genießt. Testmanagement als Teilbereich von Application Lifecycle Management kann aber eine wertvolle Unterstützung in allen Projektphasen sein. Wie einfaches und nützliches Testmanagement mit der Visual-Studio-2013-Plattform erreicht werden kann, wird im Artikel vorgestellt. Das Ziel ist es, auf Basis des TFS einen Brückenschlag zwischen Entwicklung, Test und Projektmanagement zu erzielen.

Nico Orschel


Application Lifecycle Management (ALM) als Ganzes beschäftigt sich mit der Organisation und Optimierung von Entwicklungsprozessen aus einer ganzheitlichen Perspektive. Dabei gibt ALM keinen Entwicklungsprozess vor, sondern beschreibt Rollen und Verantwortlichkeiten für den Lebenszyklus einer Applikation – egal ob iterativ, agil, formal oder anderen Herangehensweisen.

An dieser Stelle ist jetzt eine grundlegende Frage angebracht: Was hat Testmanagement mit ALM zu tun? Wird jetzt das zuvor genannte Modell als Ausgangspunkt verwendet, dann kann man voreilig zu der Schlussfolgerung kommen, dass Testen immer erst nach der Entwicklung und isoliert von dieser stattfindet. Dieses veraltete Muster wird teilweise auch noch heute in vielen Teams gelebt. In diesen meist nicht agilen Teams gibt es sehr oft eine „virtuelle“ Mauer zwischen den Teams aus Test und Entwicklung. Kommunikation erfolgt hier oft über Fehlermeldungen, die über ein Ticketsystem ausgetauscht werden. Diese werden auch mal gerne ohne Vorwarnung „über die virtuelle Mauer geworfen“. Das sorgt aber leider für ein Gegeneinander anstatt ein Miteinander. Eine etwas andere Situation ist auch in agilen Projekten zu beobachten. Testen wird hier oft auf Unit Testing durch Entwickler reduziert.

Beide Richtungen sind jedoch zu kurz gegriffen. Testmanagement im ALM-Kontext ist vielmehr als eine übergreifende Aktivität zu verstehen, d. h. sie ist nicht nur eine Phase der Entwicklung, sondern sollte als Unterstützung für alle Projektphasen verstanden werden. Es beginnt schon ganz am Anfang, denn auch das Review von Anforderungen, Lasten und Designs ist Aufgabe des Testmanagements [1]. Dann ist Testmanagement in der Entwicklungsphase involviert, denn die Automatisierung von Tests ist eine Softwareentwicklung in der Softwareentwicklung („Code testet Code“). Aber auch in Betrieb und Auslieferung ist Testmanagement direkt involviert, denn Kundenfehlermeldungen müssen geprüft werden und Testfälle für Regressionstests von neuen Versionen und Updates definiert und ausgeführt werden.

Reviews in früheren Phasen

Die wichtigste und erste Phase für den Start oder die Weiterentwicklung eines Produkts ist ausschlaggebend für spätere Aufwände. Fehler lassen sich in frühen Phasen erfahrungsgemäß leichter und günstiger korrigieren als zu einem späteren Projektzeitpunkt. Wird auf Basis einer falsch oder ungenau formulierten Anforderung ein bestimmtes Design gewählt, so lässt sich ein solches Design nach einer Implementierung und Au...

Windows Developer
Testmanagement als Bindeglied zwischen Entwicklung und Qualitätssicherung

Brückenschlag mit ALM

Tester werden bei vielen Entwicklungsteams gerne als Buglieferant anstatt als Helfer gesehen. Bugreports werden dabei oft einfach über eine virtuelle E-Mail-Mauer geworfen. Die Folge ist, dass Testmanagement einen schlechten Ruf genießt. Testmanagement als Teilbereich von Application Lifecycle Management kann aber eine wertvolle Unterstützung in allen Projektphasen sein. Wie einfaches und nützliches Testmanagement mit der Visual-Studio-2013-Plattform erreicht werden kann, wird im Artikel vorgestellt. Das Ziel ist es, auf Basis des TFS einen Brückenschlag zwischen Entwicklung, Test und Projektmanagement zu erzielen.

Nico Orschel


Application Lifecycle Management (ALM) als Ganzes beschäftigt sich mit der Organisation und Optimierung von Entwicklungsprozessen aus einer ganzheitlichen Perspektive. Dabei gibt ALM keinen Entwicklungsprozess vor, sondern beschreibt Rollen und Verantwortlichkeiten für den Lebenszyklus einer Applikation – egal ob iterativ, agil, formal oder anderen Herangehensweisen.

An dieser Stelle ist jetzt eine grundlegende Frage angebracht: Was hat Testmanagement mit ALM zu tun? Wird jetzt das zuvor genannte Modell als Ausgangspunkt verwendet, dann kann man voreilig zu der Schlussfolgerung kommen, dass Testen immer erst nach der Entwicklung und isoliert von dieser stattfindet. Dieses veraltete Muster wird teilweise auch noch heute in vielen Teams gelebt. In diesen meist nicht agilen Teams gibt es sehr oft eine „virtuelle“ Mauer zwischen den Teams aus Test und Entwicklung. Kommunikation erfolgt hier oft über Fehlermeldungen, die über ein Ticketsystem ausgetauscht werden. Diese werden auch mal gerne ohne Vorwarnung „über die virtuelle Mauer geworfen“. Das sorgt aber leider für ein Gegeneinander anstatt ein Miteinander. Eine etwas andere Situation ist auch in agilen Projekten zu beobachten. Testen wird hier oft auf Unit Testing durch Entwickler reduziert.

Beide Richtungen sind jedoch zu kurz gegriffen. Testmanagement im ALM-Kontext ist vielmehr als eine übergreifende Aktivität zu verstehen, d. h. sie ist nicht nur eine Phase der Entwicklung, sondern sollte als Unterstützung für alle Projektphasen verstanden werden. Es beginnt schon ganz am Anfang, denn auch das Review von Anforderungen, Lasten und Designs ist Aufgabe des Testmanagements [1]. Dann ist Testmanagement in der Entwicklungsphase involviert, denn die Automatisierung von Tests ist eine Softwareentwicklung in der Softwareentwicklung („Code testet Code“). Aber auch in Betrieb und Auslieferung ist Testmanagement direkt involviert, denn Kundenfehlermeldungen müssen geprüft werden und Testfälle für Regressionstests von neuen Versionen und Updates definiert und ausgeführt werden.

Reviews in früheren Phasen

Die wichtigste und erste Phase für den Start oder die Weiterentwicklung eines Produkts ist ausschlaggebend für spätere Aufwände. Fehler lassen sich in frühen Phasen erfahrungsgemäß leichter und günstiger korrigieren als zu einem späteren Projektzeitpunkt. Wird auf Basis einer falsch oder ungenau formulierten Anforderung ein bestimmtes Design gewählt, so lässt sich ein solches Design nach einer Implementierung und Au...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang