T
@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.
