Es war einmal die Idee, dass der eine den Code schreibt und der andere den Code testet. Schöne Welt des V-Modells. Ich habe in vielen Projekten mal die eine und mal die andere Seite erlebt. Meistens hat man als Tester den Frust, dass man zwar viele oder zumindest einige Fehler findet, der Programmierer aber schon längst an einer anderen Ecke arbeitet und gerade gar keine Zeit für alte Bugs hat. Im modernen Fachjargon nennt man das auch technical dept. Dafür brauchen wir dann Jira und mindestens 10 Minuten, wenn nicht sogar länger, um diese Bugs unvergesslich zu machen.
Die agile Welt verspricht da Abhilfe. Aber:
Interessanterweise haben es viele Projekte in unseren Regionen geschafft, sich agil zu nennen, obwohl sie immer noch nach dem V-Modell arbeiten. Im ersten Sprint werden Requirements gemacht, dann gibt es vielleicht ein Konglomerat von Design und Entwicklung. Und wenn die Entwickler ihren Sprint fertig haben, dann können die Tester einen Testsprint auf das entwickelte Zeug hinlegen.
Da besteht wohl ein heftiges Missverständnis. Dieses Vorgehen verletzt eines der grundlegendsten Prinzipien der agilen Software-Entwicklung und die Beteiligten sind sogar noch stolz darauf. Es geht um das Prinzip, dass am Ende jedes Sprints ein lieferbares Produkt steht. Und ein Produkt ist auch gemäß V-Modell erst lieferbar, wenn der Test erledigt ist. Andere Projekte führen dafür irgendwann die „Null-Bug-Policy“ ein. Komisch eigentlich, denn das sollte doch in meinen Augen selbstverständlich sein. Denn ist fertig fertig, oder wollen wir unseren Test beim Kunden machen?
Vor allem entgeht allen Mitarbeitern eine echt tolle Erfahrung, die ich in (mindestens) einem unserer Projekte machen konnte – und das obwohl wir uns nicht „agil“ schimpften (denn das waren wir noch lange nicht). Wir haben unsere Arbeit auch in kleine Pakete aufgeteilt, dynamisch entschieden, welche Pakete wir zuerst bearbeiten und die Rollen aufgeteilt. Ein Kollege hat die Integrationstests übernommen und die Entwickler konnten ihre Modultests jeder nach seinem Geschmack selber gestalten. Der Tester entwickelte gleichzeitig mit uns die Integrationstests. Er wusste ja auch, was am Ende rauskommen sollte. So hatten wir eigentlich immer zur gleichen Zeit die Tests und den Code fertig. Wenn wir beide soweit waren, haben wir uns gleich zusammengesetzt, die Tests laufen gelassen und gemeinsam nach den Fehlern gesucht. Und zwar sowohl in den Tests als auch im Code. Denn jeder schreibt Bugs. (Frei nach James Grenning)
Es gab mehrere Dinge, die daran toll waren. Erstens war es unsere gemeinsame Arbeit. In der klassischen Rollenaufteilung gerät man oft in ein Gegeneinander. Zweitens war ich gerade bei meinem Code im Saft und wenn der Test einen Fehler geliefert hat, war es sehr leicht, die Ursache zu finden. Drittens haben wir dabei nebenbei Code- und Testreviews gemacht.
Bekanntermaßen finden man neben einem Fehler gleich noch ein oder zwei andere. Das liegt daran, dass es Phasen gibt, in denen man nicht so konzentriert arbeiten kann und dann macht man eben mehr Fehler auf einmal. So konnten wir gleich noch ein kleines Refactoring machen und uns sind dabei noch fehlende Testfälle eingefallen. Wichtig für Regressionstest. Wir hatten ein gutes Gefühl, dass der Code so passt, weil wir auch an einige Sonderfälle gedacht haben.
Und es hat einfach tierisch Spaß gemacht. Wir beide haben gemerkt, wie wichtig die Aufgabe des anderen ist. Wir konnten uns direkt gegenseitig unsere Anerkennung und Wertschätzung zum Ausdruck bringen. Und das haben wir uns doch auf unsere Fahnen geschrieben, oder?