Suche Buch zum Thema Testing im agilen Softwareentwicklung-Umfeld

Plose

Hallo,

kennt jemand zufällig Literatur, in der ein bisschen darüber diskutiert bzw. erläutert wird, wie in einem agilen Softwareentwicklung-Umfeld (kann aber muss nicht Scrum sein) der Prozess für das Definieren und Managen von Testdaten aussehen sollte/könnte?
Gerade bei Regressions- oder Smoketests kommen die Anforderungen ja gerne mal von der fachlichen Seite - anders als bei beispielsweise Unit-Tests, bei denen in der Regel der Entwickler selber die Anforderungen an seine Testcases definiert.
Erstere Testart hat ja dann oft auch irgendeine Art von Grammatik/Syntax, in der die Fälle beschrieben werden, z.B. im User-Story Stil, given-when-then oder wie auch immer. Da gibt es dann Frameworks wie Cucumber, die eine einheitlichen Aufbau der Beschreibungen und eine Übersetzung in Code ermöglichen sollen.
Dann ergibt sich die Problematik, dass ja irgendwie eine gute Übersicht behalten werden sollte, welche fachliche Logik bereits durch vorhandene Tests abgedeckt ist, welche noch nicht, welche eventuell bei Änderungen angepasst werden müssen und so weiter und so fort.
Dabei dann halt immer die Frage, ob das alles ein Product Owner managen muss/soll, oder ob man dafür dedizierte Tester hat (so Richtung ISTQB Zertifitzierung; AFAIK ist so eine Rolle ja beispielsweise in Scrum nicht vorgesehen).
Solche Thematiken würden mich interessieren, tue mir aber gerade schwer dafür was wirklich passendes zu finden - werde zunächst in einige Scrum Bücher rein lesen und schauen, ob ich dort schon genug Informationen zu der Fragestellung finde, bezweifle es aber.

Falls hier jemand also zufällig ein Werk kennt, in dem solche Thematiken behandelt werden, würde mir das bei meiner Suche sehr helfen! Danke!

Plose

Kurz als Ergänzung, was ich jetzt bereits habe:

"Basiswissen Softwaretest : Aus- und Weiterbildung zum Certified Tester" - Spillner, Andreas
"Praxiswissen Softwaretest - Test Analyst und Technical Test Analyst" - Bath, Graham
"Basiswissen Testautomatisierung" - Bucsics, Thomas
"Testen in Scrum-Projekten : Leitfaden für Softwarequalität in der agilen Welt" - Linz, Tilo

Diese Bücher scheinen sich bisher alle sehr auf ISTQB zu beziehen (habe sie auch über das Stichwort gefunden). Demnach vertreten sie die Meinung, dass es ein oder mehrere "qualifizierte Tester" innerhalb des Entwicklungsteams ( in Scrum) geben sollte, welche für die Tests verantwortlich sind.
Eventuell gibt es dazu aber noch andere Meinungen, ich hab immer nur gehört in dem Entwicklungsteam soll es keine weiteren "Rollen" geben, cross-functional und so. Die Autoren erklären schon, dass es in ihren Augen nicht bedeutet, dass es keine unterschiedliche Spezialisierungen, wie beispielsweise einen Tester eben, geben darf. Aber wie gesagt, eventuell gibt es da noch andere Meinungen, in anderer Lektüre.
Würde mich weiterhin freuen, falls eventuell irgendwer etwas gutes in der Richtung kennt!

Tobiking2

@Plose sagte in Suche Buch zum Thema Testing im agilen Softwareentwicklung-Umfeld:

Eventuell gibt es dazu aber noch andere Meinungen, ich hab immer nur gehört in dem Entwicklungsteam soll es keine weiteren "Rollen" geben, cross-functional und so. Die Autoren erklären schon, dass es in ihren Augen nicht bedeutet, dass es keine unterschiedliche Spezialisierungen, wie beispielsweise einen Tester eben, geben darf.

Wenn die Spezialisten ihr Wissen im Team teilen bleibt das Team cross-functional. Wenn hingegen durch das Fehlen von Spezialisten das nötige Wissen im Team fehlt ist das Team gar nicht mehr funktional oder zumindest sehr ineffizient, weil sich das Wissen angeeignet werden muss oder Fehler gemacht werden. Man spricht in dem Zusammenhang auch von T-skilled persons als ideal für agile Teams. Diese sind spezialisiert in einige wenige Themen, besitzen aber ein breites Wissen um auch andere Aufgaben übernehmen zu können.

@Plose sagte in Suche Buch zum Thema Testing im agilen Softwareentwicklung-Umfeld:

Kurz als Ergänzung, was ich jetzt bereits habe:

"Basiswissen Softwaretest : Aus- und Weiterbildung zum Certified Tester" - Spillner, Andreas

Bei meinem Arbeitgeber ist der Certified Tester eine der Standardfortbildungen die jeder Entwickler irgendwann bekommt. Das Buch gibt es bei der Fortbildung dazu. Ich persönlich fand es vom Inhalt ziemlich mager. Es ist ein reines Grundlagen Buch (wovon ich das meiste aus dem Studium bereits kannte) und geht weder auf die konkrete Umsetzung noch auf mögliche Probleme ein.

Plose

Hallo Tobiking2, vielen Dank erstmal für deinen Input!

@Tobiking2 sagte in Suche Buch zum Thema Testing im agilen Softwareentwicklung-Umfeld:

Wenn die Spezialisten ihr Wissen im Team teilen bleibt das Team cross-functional. Wenn hingegen durch das Fehlen von Spezialisten das nötige Wissen im Team fehlt ist das Team gar nicht mehr funktional oder zumindest sehr ineffizient, weil sich das Wissen angeeignet werden muss oder Fehler gemacht werden. Man spricht in dem Zusammenhang auch von T-skilled persons als ideal für agile Teams. Diese sind spezialisiert in einige wenige Themen, besitzen aber ein breites Wissen um auch andere Aufgaben übernehmen zu können.

Ich finde das klingt sehr sinnvoll und wird auch so in der Lektüre, die ich bisher gelesen habe, vertreten. Scheint also auf jeden Fall so dann auch richtig zu sein.

@Tobiking2 sagte in Suche Buch zum Thema Testing im agilen Softwareentwicklung-Umfeld:

Bei meinem Arbeitgeber ist der Certified Tester eine der Standardfortbildungen die jeder Entwickler irgendwann bekommt. Das Buch gibt es bei der Fortbildung dazu. Ich persönlich fand es vom Inhalt ziemlich mager. Es ist ein reines Grundlagen Buch (wovon ich das meiste aus dem Studium bereits kannte) und geht weder auf die konkrete Umsetzung noch auf mögliche Probleme ein.

Der Teil hier klingt jetzt aber dann doch wieder ein bisschen so, als gäbe es bei euch doch keinen "Testspezialisten" im Team, sondern jeder Entwickler wird halt entsprechend fortgebildet, so dass alle auf einem Stand sind. Oder ist das nur zusätzlich, sodass jeder einfach ein gutes Basiswissen hat und dann gibt es trotzdem noch 1-2 Personen, die tiefer drin sind?
Vielen Dank auch für den Hinweis zu dem Buch, dann weiß ich schonmal, dass ich das eher hinten anstellen werden und meine Zeit auf Alternativen anwende.

Generell zu dem Testing-Thema: Relativ gut funktioniert das ganze System ja für die Unit- und Integrationstests, weil das einfach Tests sind, die jeder Entwickler dann auch selber definiert. Die kann man auch gut aus den Akzeptanzkriterien der Stories/Tasks ableiten, sodass man hier nichts weiteres benötigt. Die Akzeptanzkriterien definiert der PO, eventuell schaut ein testkundiger Mensch noch mal drüber und hilft, sie zu refinen.
Somit hat man was diese Testart angeht bereits einen funktionierenden und wohl definierten Workflow mit klaren Zuständigkeiten.

Anders ist das Thema aber wenn man jetzt sowas wie Selenium-Tests betrachtet. Damit versucht man in der Regel Regressions/Akzeptanz/Smoke/Systemtests (oder wie auch immer man sie jetzt nennt) abzudecken. Also Tests, mit denen grundlegende Funktionen der Anwendung getestet werden sollen - beispielsweise der Bestellprozess in einem Online-Shop.
Für solche Tests werden die Akzeptanzkriterien nicht reichen als Grundlage für die Tests. Irgendwer muss festlegen, welche Funktionalitäten durch diese Art von Tests getestet werden sollen und die entsprechende Szenarien dafür beschreiben. Dann muss sich auch jemand darum kümmern, dass die angepasst werden bei Änderungen und auftretenden Fehlern, jemand muss den Überblick darüber behalten, welche fachliche Logik bereits abgedeckt ist, welche sich gerade überhaupt eignet durch einen Test abgedeckt zu werden (abhängig vom Entwicklungsstand des Produkts), was genau getestet werden soll etc pp.
Und da stellt sich mir dann die Frage, wer das machen sollte. Wenn das nicht klar definiert ist, dann wird das imho schnell zum Chaos und dann macht es niemand mehr. Dann hat man nen paar solcher Tests rumfliegen, die wahrscheinlich dann auch immer öfter fehlschlagen und dann schnell irgendwann rausfliegen, weil sie nur nerven.
Theoretisch ist das ja auch sehr behaftet davon, wem das Produkt letztendlich gehört. In den meisten Firmen gibt es ja eine fachliche Abteilung, der das Produkt eigentlich gehört und die definiert, was sie haben will - der Kunde im Endeffekt. In den seltensten Fällen gehört der Entwicklungsabteilung das Produkt selber. Abnahme von Produkt-Inkrementen erfolgt ja am Ende ultimativ dann auch von dieser fachlichen Seite, die dann das OK gibt, nachdem sie auf der Integrations-Umgebung getestet hat. So kenne ich das zumindest.
Vermutlich würde es dann sogar Sinn machen, dass Personen aus dieser Abteilung festlegen, was sie getestet haben möchten - die werden aber kaum gute/genaue Formulierungen abgeben, die sich als Grundlage für die Tests eignen. Eventuell wollen sie auch überhaupt nicht Aufwand in der Richtung betreiben. Das hängt am Ende vermutlich vom Unternehmen bzw. Kunden dann ab.

Tobiking2

@Plose sagte in Suche Buch zum Thema Testing im agilen Softwareentwicklung-Umfeld:

Der Teil hier klingt jetzt aber dann doch wieder ein bisschen so, als gäbe es bei euch doch keinen "Testspezialisten" im Team, sondern jeder Entwickler wird halt entsprechend fortgebildet, so dass alle auf einem Stand sind. Oder ist das nur zusätzlich, sodass jeder einfach ein gutes Basiswissen hat und dann gibt es trotzdem noch 1-2 Personen, die tiefer drin sind?

Es kommt etwas auf das Projekt an. Als mittelgroßer Softwaredienstleister hat man viele sehr unterschiedliche Projekte. Bei kleineren Projekten (3-4 Personen, 6-12 Monate) ohne speziellen Anforderungen kommt es durchaus vor das ein Entwickler die kompletten Tests übernimmt. Wenn das Projekt größer ist oder in Richtung Funktionale Sicherheit und/oder Medizintechnik geht, werden spezialisierte Tester eingesetzt oder den Entwicklern angeboten sich weiter in diese Richtung zu spezialisieren.

Die kann man auch gut aus den Akzeptanzkriterien der Stories/Tasks ableiten, sodass man hier nichts weiteres benötigt. Die Akzeptanzkriterien definiert der PO, eventuell schaut ein testkundiger Mensch noch mal drüber und hilft, sie zu refinen.
Somit hat man was diese Testart angeht bereits einen funktionierenden und wohl definierten Workflow mit klaren Zuständigkeiten.

Unterschätz das Thema nicht. Gute Akzeptanzkriterien sind auch eine Kunst. Sind sie zu vage schießt man am Ziel vorbei. Sind sie zu spezifisch, fallen mögliche bessere Lösungen raus. Nicht funktionale Anforderungen und Sonderfälle werden auch häufig nicht beachtet.

Für solche Tests werden die Akzeptanzkriterien nicht reichen als Grundlage für die Tests. Irgendwer muss festlegen, welche Funktionalitäten durch diese Art von Tests getestet werden sollen und die entsprechende Szenarien dafür beschreiben. Dann muss sich auch jemand darum kümmern, dass die angepasst werden bei Änderungen und auftretenden Fehlern, jemand muss den Überblick darüber behalten, welche fachliche Logik bereits abgedeckt ist, welche sich gerade überhaupt eignet durch einen Test abgedeckt zu werden (abhängig vom Entwicklungsstand des Produkts), was genau getestet werden soll etc pp.
Und da stellt sich mir dann die Frage, wer das machen sollte. Wenn das nicht klar definiert ist, dann wird das imho schnell zum Chaos und dann macht es niemand mehr. Dann hat man nen paar solcher Tests rumfliegen, die wahrscheinlich dann auch immer öfter fehlschlagen und dann schnell irgendwann rausfliegen, weil sie nur nerven.

Vieles davon wird mit Prozessen und Tools zusammengehalten. User Stories werden Requirements zugeordnet. Gibt es offene User Stories zu einem Requirement, ist das Requirement nicht erfüllt. Ändert sich ein Requirement, müssen neue User Stories angelegt werden. Das kann jeder jederzeit nach verfolgen. Wenn du in dem Bereich weitere Informationen suchst, findest du das eher unter dem Begriff Requirements Engineering als beim Test.

Bei User Stories gibt es in Scrum eine Definition of Done. Diese legt fest was für eine User Story alles erfüllt sein muss, damit diese als abgeschlossen gilt. In der Regel sind das Sachen wie das Vorhandensein von Tests und Dokumentation. Außerdem gibt es bei Scrum eine maximale Anzahl von User Stories die in Arbeit sein dürfen. Ist die Entwicklung schneller als der Test, ist die Zahl schnell erreicht und der Entwickler darf keine neue Story beginnen, sondern muss die vorhandenen zum Abschluss bringen. Damit sind Entwicklung und Test in der Regel nicht mehr als die Zeit innerhalb des Sprints auseinander. Eher weniger, da nicht abgeschlossene Stories am Ende des Sprints als schlechtes Zeichen gelten.