Q283: Are you a CAT?

So könnte in Zukunft eine Frage beim Bewerbungsgespräch zum Softwaretester lauten. Die Frage hat aber nichts mit dem besten Freund des Menschen zu tun. Vielmehr geht es dabei um ein neues Zertifikat im Bereich Softwaretests (Syllabus derzeit im Review).

Nachdem die ISTQB-Reihe nichts mit agile Testing am Hut hat, war es Zeit dieser Anforderung gerecht zu werden. Aus diesem Grund gibt es seit kurzem die Ausbildung zum CAT (Certified Agile Tester).

Anders als bei der ISTQB-Prüfung, die nur auf einem schriftlichen Teil mit Multiple Choice Fragen beruht, besteht die CAT-Prüfung aus drei Teilen:

• In Teil 1 werden in einem Assessment die sozialen Fähigkeiten im Bereich Teamwork überprüft. 
• In Teil 2 muss der zukünftige CAT in einer offenen Fragenrunde seine theoretischen Kenntnisse zum Thema Softwaretests beweisen. 
• Teil 3 besteht aus einer praktischen Übung zum Thema.

In dem 5 Tage dauernden Training wird den Teilnehmern das Verständnis für methodisches Testen innerhalb von agilen Projekten und Organisationen zu vermittelt.

Mit dem Zertifikat wird bestätigt dass der Inhaber :

• Die Prinzipien der agilen Software Entwicklung versteht. 
• Zwischen der Rolle des Testers in agilen Projekten und nicht-agilen Projekten differenzieren kann. 
• Einen positiven Beitrag als agiles Team Member im Bereich Softwaretest beitragen kann. 
• Eine breite Basis, an in agilen Teams notwendigen, Soft Skills besitzt.

Das 5 tägige Training ist wie folgt aufgebaut: 

• Jeden Tag Daily Scrum and Skills Assessment 
• Tag 1: Geschichte und Begriffe: Agile Manifesto, Prínzipien und Methoden 
• Tag 2: Planung, Anforderungen, Schätzung und Strategie 
• Tag 3: Entwicklungs Context, Testen und Retrospektiven 
• Tag 4: Test Driven Development, Test Automation und Testen von Nicht funktionalen Anforderungen 
• Tag 5: Praktische und theoretische Prüfung

 Alles in allem eine runde Sache und ein weiterer Beitrag zum Rollenbild des Softwaretesters.

Q281: Agile Testing = Chaos! Stimmt die Gleichung?

Nein, da weder der Explorative noch der Session Based Test eine agile Erfindung sind. Das sagt zumindest DI. Manfred Baumgartner (Bild links), Leiter Geschäftsfeld Software-Test, ANECON Software Design und Beratung G.m.b.H.

Für die ATB-Insider Interviewreihe "Auf einen Kaffee mit..." traf ihn zum Frage&Antwort-Spiel und stellte dabei die eine oder andere ketzerische Frage zum Thema „Agile Testing“.

Q: Herr Baumgartner, gleich eine ketzerische Frage zum Einstieg. Stirbt der traditionelle Tester, also der nicht agile Tester, aus?

MB: Für die Beantwortung dieser Frage ist es von Bedeutung, was man unter einem traditionellen Tester versteht: Wenn „traditionell“ bedeutet, dass der Tester im Anschluss an lange Analyse- und Entwicklungsphasen wochen- oder gar monatelange Tests durchführt und es vielleicht – auf Grund der Größe des Vorhabens – gar nicht auffällt, wenn der individuelle Fortschritt einmal nicht so gegeben ist, dann wird der traditionelle Tester wohl aussterben.

Besagt „traditionell“ jedoch die Beherrschung von bewährten und effizienten Testmethodiken, dann ist der agile Tester eine spezifische Ausprägung des traditionellen, professionellen Testers unter sehr herausfordernden Rahmenbedingungen.

Q: Agiles Testen hört sich für manche an nach „Chaos“ und „Jeder macht was er will“. Was sagen sie dazu? Wie definieren sie „Agile Testing“?

MB: Agile Testing ist ganz das Gegenteil von „Jeder macht was er will“. Stärker als in traditionellen Vorgehensweisen ist er gleichberechtigtes Mitglied des Entwicklungsteams und dem konstruktiven Entwicklungsprozess „committed“. Es geht also weniger um das „destruktive“, nachgelagerte Fehlerfinden, wozu jedes Mittel legitim ist, sondern um die aktive Mitgestaltung in der Erarbeitung und regelmäßiger Bereitstellung von Business Value in Form eines funktionstüchtigen Release der geplanten Applikation. Um dieses zu erreichen, muss sich auch der Tester dem übergeordneten Ziel des agilen Teams unterordnen und ein Testverfahren und Testmethodiken wählen, die die bestmögliche Qualität und somit die Absicherung des Geschäftsnutzen sicherstellen.

Q: Was zeichnet einen agilen Tester aus.

MB: Den agilen Tester zeichnen insbesondere drei Fähigkeiten aus. 

Erstens: die Fähigkeit, den für die konkrete Aufgabenstellung richtigen Testansatz und die richtigen Testmethoden und –techniken zu wählen. Dies bedingt einerseits die Kenntnis dieser Methoden und andererseits die Erfahrung, Kreativität und Flexibilität in deren Anwendung.

Zweitens: Konsequenz und Ausdauer, um unter dem Druck des oft engen zeitlichen Korsetts in Agilen Projekten (kurze Iterationen, „working software“ am Ende jedes Sprints) nicht auf erlerntes und bewährtes Wissen zu vergessen und in ein Chaos-Vorgehen zu verfallen und

Drittens: Kommunikationsfähigkeit, da nur über eine sehr gut funktionierende direkte Kommunikation mit allen Teammitgliedern, sei es Entwickler, Product Owner, Endanwender oder sonstige Stakeholder, die Synergien eines Agilen Teams realisiert werden können.

Insider: In SCRUM gibt es die Rolle des Testers nicht, da gibt es keine Spezialisten. Wie würden sie das Thema Test dort verankern?

MB: Dies ist im Wesentlichen dem Umstand zu verdanken, dass die „Erfinder“ von SCRUM und die einschlägigen Autoren Entwickler und keine Tester waren. Aber es sei ihnen verziehen, denn würde ich als Tester ein Vorgehensmodell entwickeln, dann würde dies darauf beruhen, dass der Endanwender Business-Modelle formuliert, aus denen der Code direkt generiert wird und die Ergebnisse durch Tester validiert werden. Der klassische Entwickler wäre nur mehr in Ausnahmefällen von Nöten.

Aber Scherz beiseite: SCRUM geht hier an den Notwendigkeiten und der Realität vorbei. Ein gutes SCRUM-Team besteht aus Requirements-Engineers, eine Rolle, die manchmal durch den Product Owner eingenommen werden kann; es hat einen exzellenten Architekten im Team, der unter Umständen auch mit entwickelt und dafür sorgt dass die Architektur trotz vieler kommenden Änderungen stabil und flexibel zugleich ist; es besteht aus hervorragenden Entwicklern, die im kurzen Sprints sowohl neue Features entwickeln, Fehler beseitigen und ein laufendes Refactoring durchführen; und es umfasst ein Team von ausgezeichneten Testern, denen es in optimaler Weise gelingt eine hohe, nachvollziehbare Testabdeckung zu erreichen, die neuen Features zu testen und gleichzeitig – unter Einsatz von funktionaler Testautomatisierung – die notwendigen und mit jedem Sprint umfangreicher werdenden Regressionstests durchzuführen. Wenn man sich dies vor Augen führt wird deutlich, dass die SCRUM-Interpretation „Jeder kann und macht alles“ eine Illusion ist.

Q: Das ISTQB geht nicht näher auf Agile Testing ein. Wie passt die ISTQB-Zertifizierung als Ausbildung dann mit Agile Testing zusammen?

MB: Wie bereits erwähnt steht Agile Testing nicht im Widerspruch zu den ISTQB-Zertifizierungen, in denen insbesondere viele Grundlagen, Techniken und Methoden des Software Tests vermittelt werden, die ganz besonders in Agilen Projekten zum Einsatz gelangen. Mittlerweile wurde auch der Certified Agile Tester® CAT ins Leben gerufen (www.agile-tester.org). ANECON bietet seit Anfang des Jahres ein Seminar „Agile Testing“ an und ist ebenfalls CAT – Training Provider und gleichzeitig ISTQB-akkreditiertes Unternehmen – und wir betrachten diese Ansätze in einer synergetischen Ergänzung.

Q: Exploratives Testen = Session Based Testing = Agil. Stimmt die Gleichung?

MB: Die Gleichung stimmt insofern nicht, als dass weder der Explorative noch der Session Based Test eine agile Erfindung sind und man einen schweren Fehler begeht, wenn man „Agil“ auf diese Testtechniken reduziert. Der Einsatz dieser Techniken muss auf den jeweiligen Einsatzzweck und auf die angestrebten Qualitätsziele abgestimmt sein. Wichtiger in Agilen Projekten erscheinen mir jedoch die Optimierungsmöglichkeiten eines Risikobasierten Tests bzw. von Value Driven Testing sowie der konsequente Einsatz von Testautomatisierung.

Q: Brauche ich im Zeitalter von agile Testing noch einen Testmanager?

MB: Obwohl z.B. in SCRUM der Testmanager vorerst im wahrsten Sinn des Wortes keine Rolle spielt, prägt sich in fast allen Agilen und auch SCRUM-Projekten dies Rolle „natürlich“ aus – weil Erfahrung und Kenntnis in Testansätzen, -methoden und –techniken und in Aufwandsschätzungen immer benötigt werden. Der Testmanger ist dabei aber nicht mehr der Manager eines Teams von Testern sondern Manager des Tests in einem gleichberechtigten Team.

Q: Danke für das Gespräch.

Q276: What does agile mean? Teil II

Ich habe am Mittwoch in der Früh ganze 45 Minuten benötigt um den Begriff „agile“ zu erklären (Q275). FRAFU, eines unserer Development-Pigs hat am Nachmittag beim Daily Scrum dazu gerade mal 20 Sekunden gebraucht.

Also, what does agile mean?

Ich schieb in Sachen Software-Tests zur Zeit ja eine ruhige Kugel. Ruhige Kugel da ich zu 100% im SAS70-Projekt unterwegs bin. Bis zur Prüfung nächste Woche ist noch jede Menge zu tun und daher bin ich von allen Testaktivitäten entbunden. Also bin ich zur Zeit quasi ein Chicken. Aber nur quasi.

Trotz meiner Abstinenz nehme ich täglich am Daily Scrum teil. Denn sobald das SAS70-Projekt fertig ist, muss ich schon den System Qualification Test für die nächste Release vorbereiten. Aus dem Grund muss ich einfach am Ball bleiben was die Ferkel-Bande macht.

Der guten Ordnung halber, stellt TheBoss mir auch die 3 berühmten Fragen. Meistens beantwortet er sie auch gleich selbst, weil es eh immer die gleichen Antworten sind: SAS70 / SAS70 / SAS70.

Also: Seit dem letzten mal habe ich SAS70 gemacht, bis zum nächsten mal werde ich SAS70 machen, und im Weg steht mir: SAS70.

Doch halt. Ich verplappere mich schon wieder. Es geht um die Definition von „agile“.

Also FRAFU verkündet voller Stolz dass seine Story fertig ist und somit DONE ist. Ein Blick auf die Tafel sagt mir: Das kann nicht sein. Rechts in der Spalte DONE hängt zwar ein Berg gelber Zettel, doch ein einsamer gelber Zettel in der linken Spalte (aka noch zu erledigen Spalte) beweist das Gegenteil. 

Was drauf steht?

„Review Spec“, steht drauf. Gemeint ist der Review durch den Product-Owner. Nachdem ketzerisch mein dritter Vorname ist – goschat ist der 2. - kommt auch schon die Frage: „Tschuldigung FRAFU, wie kann die Story auf DONE sein, wenn die Dokumentation nicht abgenommen wurde?“

Während FRAFU voller Ehrfurcht den gelben Zettel nimmt und in die DONE-Spalte ablegt interpretiert er den 2. Grundsatz des agile Manifestos wie folgt: „Doku brauch ma nimma, is eh scho fertig!“

Na, hab ich zuviel versprochen? Agile Softwaredevelopment auf den Punkt gebracht. Ich hab dafür 45 Minuten gebraucht.

Q275: What does agile mean?

Gestern in der Früh war Englischkurs im Büro angesagt. Als Hausaufgabe musste ich eine kleine Präsentation vorbereiten.

Ich habe also einen alten Vortrag von mir genommen und ins Englische übersetzt. In dem Vortrag erkläre ich den Unterschied zwischen dem V-Modell XT und Scrum, und führe aus wie die beiden Modelle voneinander profitieren können. Ja, das geht. Wirklich. Aber das steht hier nicht zur Debatte.

Ich lege also los mit:

„The integration of agile and heavyweight processes for system development is no longer a methodical taboo!”

Mr. Hyde klopft mir auf die Schulter uns flüstert mir zu: „Gut gemacht, alter Junge. Zeig’s den Ladies! Weiter so!“

Optimal den Vortrag vorbereitet, was heißt: auswendig gelernt, will ich jetzt eine Show abziehen, die wieder mal einen Oscar einbringen könnte.

Doch leider habe ich gegen Paragraph 3 Absatz 5 der Präsentationstechnik verstoßen, der da lautet:

Denk an dein Publikum. Wer sind deine Zuhörer?

Eigentlich ausgearbeitet für Software-Fuzzis, zeige ich es jetzt meiner Englisch-Lehrerin und einer Kollegin aus dem Backoffice.

Auf alle Fragen war ich vorbereitet, auf wirklich alle. Bis auf diese:

„What does agile mean?“

Was meint die? Das ist doch eh klar, oder? Ich versuche also das Wort „agile“ zu erklären und erlebe die schrecklichsten 45 Minuten der letzte Wochen. Ich erzähle etwas von agilen Mindsets, vom agile Manifesto, von geforderten Artefakten auf Grund von gesetzlichen Vorgaben und was der Teufel alles. Ich rede mich immer mehr in eine Sackgasse. Es wird immer schlimmer.

Mr. Hyde sitzt auf meiner linken Schulter und kotzt sich an. „Bist du deppat Oida. Waus redst du do für an Scheiß!“. Dr. Jekyll, auf meiner rechten Schulter sitzend, hält mit ruhiger Stimme dagegen: „Na geh Hyde, er tut sein bestes. Gib ihm Zeit, er wird das schon schaffen!“

Von wegen schaffen. Ich komme mir vor wie bei DSDS, Helden von Morgen oder Austrias Next Footballstar. Meine Lehrerin schreibt alles mit, ich werde total unrund. Dieter Bohlen würde keine Worte für meine Performance finden.

Und das alles nur wegen dem beschissenen Wort: agile. 

Irgendwann bin ich durch und habe es geschafft. Jetzt kann sogar meine Kollegin aus dem Backoffice erklären was „agile“ bedeutet. Mr. Hyde hängt tot auf meiner Schulter, weil er an seiner Kotze erstickt ist. Dr. Jekyll schaut mich lobend an.

Am Nachmittag beim Daily Scrum führt FRAFU vor was er unter agile versteht. Wie er das macht?

Die Geschichte gibt’s dann morgen.

Q257: Scrum - Fluch oder Segen

Ich war wieder als rasender Reporter für das Austrian Testing Board unterwegs. Diesesmal bat ich einen Scrum-Evangelisten zum Kaffee.

DI. Joachim Niederreiter (Bild), Entwicklungsleiter von "SolveDirect Service Management", erzählte dabei was er von Scrum hält.

Seine Message: "Wenn man Scrum einmal konsequent angewendet hat, ist es schwer, sich eine Softwareentwicklung mit den herkömmlichen Methoden überhaupt noch vorzustellen."

Das ganze Interview gibts hier.

In der Ausgabe 07 des ATB-Insiders (Q199) hat ja bereits DI. Johannes Bergsmann, Geschäftsführer von Software Quality Lab, seinen Meinung zum Thema kundgetan.

Demnächst werde ich dann die beiden Interviews gegenüberstellen.

In der nächsten Ausgabe ist der ATB-Insider, aka ICH, zu Gast bei DI. Manfred Baumgartner. Er leitet das Geschäftsfeld Software-Test bei "ANECON Software Design und Beratung" und plaudert bei Kaffee und Kuchen über agiles Testen und Testmanagement.

Q161A: Polaroid of the Week!

... wenn er neben dem SAS70-Projekt mal Zeit fürs testen hat!

Q144: WII.mbledon und der heilige Teppichboden

Die Encyclopaedia Galactica beschreibt das Fraggles WII.mbledon Turnier wie folgt:

WII.mbledon Championships [Bearbeiten]

---

Im Rahmen des System Tests, der beschissener weise mit STQ abgekürzt wird, veranstaltet die Softwareentwicklungsabteilung des weltweit größten Anbieters irgendeines Softwareservice, diese sportliche Veranstaltung.

Dabei geht es nicht nur darum mit TV-Fernbedienungen einen virtuellen Ball über ein virtuelles Netz zu dreschen das mittels altmodischer Methoden an die Bürowand geworfen wird. Nein vielmehr geht es darum durch möglichst viel untergriffiges Herumquatschen den Gegner aus dem Spiel zu bringen und so Eigenfehler des Gegners zu forcieren.

Es ist das Erste der sogenannte Grand-Slam-Turniere des Jahres und das einzige, das noch auf Teppichboden hinter einen Videobeamer statt findet. Die Plätze beim WII.mbledon werden umgangssprachlich als „heiliger Teppichboden“ bezeichnet.

Geschichte [Bearbeiten]

---

Die ersten WII.mbledon  Championships fanden am 4. Dezember 2009 statt und wurden noch mit einer geborgten Konsole ausgetragen. Zunächst nur für Männer zugelassen, wurde 2010 nach massiven Protesten des Betriebsrates auch das angeblich schwache Geschlecht zugelassen. Seit 2010 wird mit einer Konsole gespielt die sich die Fraggles durch massives Zu-spät-zu-Meetings-kommen selbst finanziert haben.

Tradition [Bearbeiten]

---

Bis heute hat sich WII.mbledon einen speziellen, agilen Charakter bewahrt, der das Turnier von allen anderen abhebt. Hier scheißt sich keiner etwas um die alte Regelung, dass 90 Prozent der Spielkleidung weiß sein müssen. Gemäß dem agilen Manifest zählt das Individium, nicht die Etiquette. Genagelte Budapester sind genau so erlaubt wie Birkenstock und Badeschlapfen. Das kaum vorhandene Publikum nimmt ebenso traditionell Gummibären und Pistazien zu sich, wie die Spieler den nicht seltenen Brauch des Einmelden von Softwarebugs mit Gleichmut erträgt.

Das Eröffnungsspiel ist immer das des Titelverteidigers auf dem „Centre Court“. Der „Centre Court“ ist durch eine Scrum-Tafel vor neugierigen Blicken vorbeikommender Bosse geschützt.

Sieger [Bearbeiten]

---

Der Sieger von 2009 ist vakant, da eine einsetzende Schlecht.Code.Front massiven Bugs-Niederschlag mit sich brachte und das Turnier vor dem Finale abgebrochen werden musste.

Rekordsieger an der Karl-Farkas ist somit der Qualitätsbeamte der Fraggles mit einem Sieg, der im Finale Rel. 5.4 (Codenamen Web2.0) den Favoriten FRAFU mit 3:2 besiegte.

Q122: Tue Gutes und sprich darüber, tue schlechtes und büße dafür!

Eine Buddhistische Weisheit besagt, dass das was man gibt auch wieder zurück bekommt. Nicht gerade in der selben Form, aber in einer anderen. Will heißen: „Tue Gutes, dann kommt Gutes zurück. Tue Schlechtes dann kommt Schlechtes zurück!“.

Was also passiert wenn man (aka TheBoss) beim Kartfahren in Senna Manier den Prost (aka DLTB) von der Strecke bugsiert um den Gewinn einzufahren? Richtig, der SAS70-Gott rächt DLTB und beschert TheBoss einen Haufen interne Controls. Will heißen in Zahlen: 18 Controls für TheBoss, 1 für DLTB. Und wer glaub dass es agile Controls gibt, der glaubt auch das Projektmanager Projekte managen und Zitronenfalter Zitronen falten.

Q53: Was sagt die Risikobewertung?

Die Permissiongroups unserer Applikation waren nicht so implementiert wie im Handbuch beschrieben. Das wiederum bedeutet, dass die Abweichung gefixed wurde.

Unser Ivan Drago (aka der MIG-Pilot aka Y.) hat sich darum gekümmert. Das Ganze ohne den Spruch: "Das ist eine Kleinigkeit". Was heißt das jetzt? Traut sich keiner mehr den Spruch zu führen, oder ist es wirklich so heikel. Eine durchgeführte Risikoanalyse trifft sich in der Risikomatrix bei B2, was soviel bedeutet wie "Fast volle Wäsch testen!". Gott sei Dank nur "fast".

Was die Ableitung der logischen Testfälle erleichtert ist die Tatsache, dass mir ein Testorakel*  zur Verfügung steht aus dem ich ableiten kann. Hippie. Freude kommt auf. Nachdem aber nicht viel Zeit zur Verfügung steht, greifen wir wieder auf Session Based Testing zurück. Denn: Ich bin agil, du bis agil, wir sind agil – usw. usw.

Nach 15 Minuten komm ich drauf, dass etwas nicht stimmt. Ein kurzer 6-Augen-Check (Ivan Drago, DLTB, Q) stellt fest dass ein Update in der DB zu erfolgen hat. Schnell ist ein Script geschrieben, versioniert, deployed und die Permissionsgroups machen das was sie machen sollen. Voll Agil. Ich liebe dieses Wort und alles was dahinter steckt.

Im Zuge des OnBoarding-Prozesses meiner Person hat BvQ einen gemeinsamen Bekannten, M. (Agil hoch 2), nach mir ausgefragt. Mit M. habe ich im gleichen Softwarehaus gearbeitet. Seine Empfehlung für BvQ: "Treib eam sei Stuaheid aus, und du host an guate Maun". Die Sturheit war bezogen auf meine Liebe zum V-Modell-XT und meiner Meinung "AGIL = Pfuschen". Mich** kann niemand zu etwas überreden, mich kann man nur Überzeugen. Dank an M., dass er nicht alles von mir verraten hat.

*(Für TF: Nicht gleich schwitzig werden, das hat nichts mit einer Orakel-Datenbank zu tun. Für MOR: Ja, leider - hat nichts mit einer Oracle-DB zu tun)
*** (Sternzeichen Stier. Aber wer glaubt so einen Sch%$§&§&$§?)

Q44: Wie agil ist Session Based Testing?

Y. (aka Ukrainischer DEV-Fraggle) hat die Setups des ReportsSchedulers umgebaut. Der gelbe Zettel auf der Scrumtafel mit der Aufschrift "ENG Test" schreit: "Q., nimm mich. Hallo ich will von dir in Progress genommen werden. Los, du Sack fang endlich zum Testen an!". Nachdem gelbe Zettel mit dieser Aufschrift meine besten Freund sind, komme ich diesem Wunsch gerne entgegen.

Schritt 1: Testbasis (aka RFC-Dokument aka User-Story aka das-Ding-das-nie-vollständig-ist-wenn-PK-eine-Anforderung-hat" sichten. Was jetzt kommt brauch ich nicht erzählen, es ist eh klar.

Aber halt. Was sehe ich da. Der zuständige DEV-Fraggle hat eine technische Spec geschrieben. Schampus für den Y. Wobei der Lenin-Orden würde dem Ukrainischen-Tom-Cruise-Top-Gun-Absolventen besser stehen.

Na gut. Session Based Testing, mein neuestes Lieblingwort. Ich verfahre auch danach. Vorerst zum Kennenlernen. BvQ (aka den kennt jetzt eh schon jeder, das ist mein Boss) sagt immer "Sehe es als eine Chance etwas neues Auszuprobieren!". Recht hat der BvQ.

Ich definieren als Testcharta: "Prüfe ob die Java-Script-Funktionalität in allen Browsern korrekt arbeitet". SB-Timescope: "90 Minuten". Das muss reichen um zu beweisen dass eine Abweichung vorliegt.

Werfe meine Wunderwaffen an: 6 Virtuelle PC auf meiner 4-GB-aber-nur-2-adressierbaren-Workstation an. Auf jedem läuft der jeweilige Browser (FF35, IE7, IE8, Opera, Safari, Crome) in einer nackten Windows-XP-Umgebung. Weil, man kann ja nie wissen welcher Browser welchen was zusammenhaut.

Richtige Abweichung finde ich keine. Java Script funktioniert. Mir fällt nur auf das ich Datenfelder eingeben kann die keiner braucht und daher auch nicht gespeichert werden. Sofort mache ich meinem Gegenüber DLTB (aka die-lebende-Test-Basis aka BdF aka Boss der Fraggles aka der-Mann-der-jedes-Byte-der-Applikation-kennt) klar das somit ein klarer Usability-Verstoß nach SD§ 4711 Absatz 0815 vorliegt.

Nach heftigen Diskussionen meint DLTB "Des woar scho imma so. Oba du host scho recht. Des kennt ma a noch schnö mochn!". Alarmglocken schrillen, " a no schnö mochn". DLTB formuliert schnell die neue Anforderung und gibt diese verbal über meinen Kopf hinweg an Y. weiter. "Y., geh berücksichtige das die zwa Felder nur angezeigt werden wenn im Feld Periode der Wert  Täglich steht."

Cruise meldet verbal über meinen Kopf zurück: "OK, das haben wir gleich...!"

Ich liebe agile Softwareentwicklung. Doch halt. Was war da zwischen "OK...!" und "Ich liebe agile...."?