- Advertisement -spot_img
HomeAgilAgil oder doch nicht (komplett) agil? Umfragen zum Status-Quo von »Softwaretest in...

Agil oder doch nicht (komplett) agil? Umfragen zum Status-Quo von »Softwaretest in Praxis und Forschung«

- Advertisement -spot_img

Ausgewählte Ergebnisse der Umfrage von Andreas Spillner, ASQF, GTB; Karin Vosseberg, HS Bremerhaven, ASQF; Mario WInter, TH Köln, GTB

AGIL ODER DOCH NICHT
AGIL ODER DOCH NICHTPNG05

Das German Testing Board (GTB e. V.) hat zusammen mit der Technischen Hochschule Köln und der Hochschule Bremerhaven sowie dem Austrian Testing Board (ATB) eine Neuauflage der 2011 und 2015/16 erfolgreich durchgeführten Umfragen zum Status-Quo und der Entwicklung von »Softwaretest in Praxis und Forschung« durchgeführt. Unterstützt wurde die Umfrage u. a. vom ASQF e. V. Bei der aktuellen Befragung haben über 1.200 Personen teilgenommen und 70 % davon haben vollständig die Fragen aus Sicht des Managements, der operativen Umsetzung und der Forschung beantwortet. Die Ergebnisse stehen allen Interessierten im Internet unter www.softwaretest-umfrage.de zur freien Verfügung.

2/3 DER PROJEKTE WERDEN AGIL DURCHGEFÜHRT

In den letzten zehn Jahren hat das agile Vorgehen immer mehr an Bedeutung gewonnen. In 2020 werden bereits 2/3 der Projekte agil durchgeführt. Die Verwendung eines phasenorientierten Prozesses ist weiter rückläufig, nur jedes 5. Projekt wird nach diesem Vorgehen abgewickelt. 2011 wurden noch mehr als die Hälfte (54 %) phasenorientiert und nur knapp ein Drittel (29 %) der Projekte agil durchgeführt (s. Abb. 1). Das Verhältnis hat sich somit innerhalb der letzten 10 Jahre mehr als gedreht. Abbildung 1: Prozentualer Anteil der Vorgehensmodelle ROLLENBILDER SIND EHER UNVERÄNDERT Obwohl Agilität so verbreitet ist, sehen sich viele noch den alten Rollenbildern der Softwareentwicklung zugehörig. Nach der Frage an die operativ Tätigen „Welcher Rolle ordnen Sie sich mit Ihren Hauptaufgabe zu“, sind es 3 % die sich als Mitglied im agilen Team sehen, 2 % nehmen die Rolle des Product Owners an und 1 % sehen sich als Scrum Master. Im Vergleich dazu verstehen sich 32 % als Entwickler*innen, 21 % als Tester*innen, 19 % als Testmanager*innen und 11 % als Projektleiter*in/Teamleiter* in. Die alten Aufgabenfelder sind anscheinend noch nicht aufgehoben.

TESTVERFAHREN NOCH ANGESAGT?

Wenn sich keine Verschiebungen bei den Rollen abzeichnet, wie sieht es bei den Kompetenzen aus? Agilität unterstützt eine hohe Autonomie der einzelnen Teams. Dies kann dazu führen, dass etablierte Methoden hinterfragt und ggfs. auch nicht (mehr) angewendet werden. Betrachten wir einen Aspekt: Den Einsatz von Testverfahren. Sie werden zur Erstellung von Testfällen und zur Definition von Kriterien zur Beendigung des Testens genutzt. Welche werden wie intensiv eingesetzt und hat es Veränderungen gegeben? Im Folgenden betrachten wir die häufige (Antwortoptionen: immer/meist) Nutzung der Testverfahren von Tester* innen (inkl. Testmanager*innen) und Entwickler*innen. Die Nutzung Abbildung 2: Nutzung der klassischen Testverfahren über alle Rollen ist auf der Internetseite der Umfrage (s. o.) zu finden. Das meistgenannte Testverfahren ist der anwendungsfallbasierte Test. 79,5 % der Tester*innen und 57,4 % der Entwickler*innen nutzen ihn häufig. Die »klassischen Testverfahren« wie Äquivalenzklassenbildung, Grenzwertanalyse und zustandsbasierter Test werden von den Tester*innen deutlich öfter eingesetzt als von den Entwickler*innen – zu etwa einem Drittel bzw. etwas weniger (s. Abb. 2). Wird die Antwortoption „teils/teils“ hinzugenommen, erhöht sich der Wert bei den Tester*innen auf 2/3 bei den beiden erstgenannten Verfahren und auf 54,7 % beim zustandsbasierten Test. Bei den Entwickler*innen sind es dann: Äquivalenzklassen 28,7 %, Grenzwertanalyse 38,9 %, zustandsbasierter Test 42,7 %.

EXPLORATIVES TESTEN

Einhergehend mit der Agilität hat exploratives Testen, ob mit oder ohne Charta, an Bedeutung gewonnen. Wie sieht dessen häufige Nutzung bei den beiden untersuchten Gruppen aus? Bei den Tester*innen liegt exploratives Testen ohne Charta deutlich höher in der Nutzung als die Äquivalenzklasssenbildung (s. Abb. 3). Wird die Antwortoption „teils/teils“ wieder hinzugerechnet, nutzen Tester*innen zu 74 % das explorative Testen ohne Charta, bei den Entwickler*innen sind es 46,1 %. Pairwise-Testing, ein Ansatz um die Kombinationsvielfalt von Parametern in den Griff zu bekommen, wird kaum genutzt. 11 % der Tester*innen und 32 % der Entwickler*innen kennen das Verfahren nicht. (Mehr zum Pairwise-Testing bzw. n-weisem Testen unter http:// leantesting.de/Openbook_Testen.pdf).

STRUKTURBASIERTES TESTEN

Die strukturbasierten oder auch White-Box-Testverfahren sind eher entwicklungsnah, da es um die Überdeckung von Anweisungen oder Entscheidungen geht. Da der Unit-Test oft von Entwickler*innen durchgeführt wird, werden die Verfahren bekannt sein und genutzt werden, oder? Die Differenzen zwischen Test und Entwicklung beim Einsatz der Verfahren ist geringer, jedoch liegen die Zahlen meist unter 20 % (s. Abb. 3). Wie wurden die Verfahren von allen Befragten heute und vor 5 Jahren genutzt? Gib es Veränderungen? Alle der Verfahren werden heute weniger eingesetzt, dies betrifft besonders die klassischen Verfahren (s. Tab. 1). Exploratives Testen, ob mit oder ohne Charta, ist auf dem gleichen Niveau geblieben, obwohl die Agilität zugelegt hat. AUSBLICK Die Zahlen können dahin gehend interpretiert werden, dass Testen – besonders das systematische – »out« ist. Spielt damit auch die Qualität der entwickelten Software keine Rolle mehr? Dies können nur – wenn überhaupt – die kommenden Jahre belegen, ob eine Veränderung der Softwarequalität sich abzeichnet. Da das agile Team für die Qualität verantwortlich ist, kann es ebenso zu einer Verbesserung der Qualität kommen. Bedeutend für die Qualität im Hinblick auf die Qualitätssicherung sehen in 2020 78,6 % aller Befragten im operativen Bereich das Code Review und 73 % nennen Clean Code. Bei den Entwickler*innen liegen beide Praktiken bei 85 %. Eine Interpretation der Zahlen wäre, dass die Qualität (auch) in den Händen der Entwickler*innen liegt – keine so schlechte Aussicht für die Zukunft.

 

Artikel teilen
- Advertisement -Certified DevOps Portfolio
Neueste Artikel
Weitere interessante Artikel
- Advertisement -spot_img