Agile Testing Days 2011 – About testers and garbage men by Stefaan Luckermans

Credits gehen an DI Reinhard Salomon, der diesen Artikel verfasst hat:

Einen sehr interessanten Vortrag hielt Stefaan Luckermans: “About testers and garbage men”.

Schon sein Auftritt – er kam verkleidet als Oliver Hardy vom legendärem Komiker-Duo „Laurel und Hardy“ – erzeugte Neugier auf seine Ausführungen. Begleitet von alten Stummfilmen und  in Zusammenhang mit der Filmbranche brachte Stefaan auf diese unkonventionelle Art seine Überlegungen, wo im Testumfeld die Quellen von Verschwendung/Müll liegen. Auch japanische Klassifizierungen wurden herangezogen. DIe 7 Quellen von MUDA (=Verschwendung)  sind hier

Mehr von diesem Beitrag lesen

Advertisements

Agile Testing Days 2011 – Keynote: People and Patterns by Esther Derby

Esther Derby kommt aus dem Managementconsulting und das merkt man im Zuge ihrer Keynote. Sie hat sich ausführlich mit der Fragestellung der Schuldzuweisungen in agilen Teams beschäftigt und macht in ihrem Vortrag auf die Hintergründe aufmerksam.

Grundproblem ist: Systemprobleme werden meist Personen zugeordnet und Probleme mit Personen auf Systeme zurückgeführt.

Um dies aufzulösen und zu einem besseren agilen Team zu gelangen schlägt Esther vor die Strukturen herauszufinden, die die Dinge zusammenhalten. Dies kann z. B. gleiches technisches Wissen, gleiche Sprache, gleiche Rolle, etc. sein, in einem Team gibt es viele Gruppen, das Team ist eine übergeordnete Gruppe, quasi unsichtbare Strukturen. Mehr von diesem Beitrag lesen

Agile Testing Days 2011 – Keynote Appendix A: Lessons Learned since Agile Testing Was Published by Lisa Crispin & Janet Gregory

Lisa Crispin und Janet Gregory sind Vorreiter in der Publikation erster Arbeiten zum agilen Testen. Letztendlich haben die beiden das erste Buch zum Thema geschrieben und damit eine erste ausgereifte Diskussionsgrundlage vorgestellt.

Seit der Vorstellung des Buches sind nunmehr 2 Jahre vergangen, wie angekündigt haben die beiden dann abwechselnd ihre Lessons Learned zu unterschiedlichen Punkten vorgestellt.

Ein paar habe ich hier herausgepickt: Mehr von diesem Beitrag lesen

Agile Testing Days 2011 – Keynote: Agile Testing and Test Management by Johanna Rothmann

Johanna ist ein Urgestein in der Softwareentwicklung, seit vielen Jahren im agilen Umfeld tätig, mehrfache Buchautorin und – wie ich sie erleben durfte – eine hervorragende Vortragende. Mit viel Witz und Charme hat sie skizziert, dass der von ihr viel zitierte Second Class Tester (ein Tester, der nicht von Beginn an im Projekt mitwirken darf, von allen Vorgängen ausgeschlossen ist und weder vom Team noch vom Rest der Firma ernst genommen wird) eine vom aussterben bedrohte Art ist. In der heutigen Zeit ändern sich die Dinge, die Mauern zwischen Testen und Entwicklern fallen, alle rücken näher zusammen. Die Rolle des Testers wird immer wichtiger, er „entwickelt“ genauso am Produkt mit, wie ein Entwickler, kann sein, dass er dafür nicht codieren muss, aber die meisten Tester heute codieren auch (zumindest ihre Testautomation) und tragen mit ihrem Qualitätsfeedback entscheidend zur Entwicklung des Produktes bei. So kommt Johanna zum Schluss, dass Tester heute agile Tester sind und damit „First Class Tester“. Mehr von diesem Beitrag lesen

Serie: Spaß am Testen (3)

In den ersten beiden Teilen der Serie wurde der mögliche Einfluss von Testmanagement, Testautomation und der Entscheidungen zur Weiterbildung und Zertifizierung auf die Motivation des Testers beschrieben. Der Tester steht aber zumeist nicht alleine im Unternehmen, sondern arbeitet in einem Team, einem Testteam. Wie können wir dieses Team erhalten und aufbauen? Und was können wir den Teammitgliedern noch Gutes tun? Fangen wir mit Letzterem an.

Infrastruktur: Ein alter Rechner und ein 15″ CRT, dazu ein Großraumbüro, eine kaputte Kaffemaschine und eine Mensa als Kantine. Das sind die Idealbedingungen für einen nicht motivierten Mitarbeiter. Dabei ist es gar nicht so schwer, die Arbeit eines Testers zu erleichtern und den Gang zur Arbeit erträglicher zu machen. 21″ LCD Monitore kos- ten mittlerweile nicht mehr die Welt und nur zu oft kann man durch 2 Stk. nicht nur die Motivation, sondern auch die Effizienz der Arbeit steigern. Auf der einen Seite das Testobjekt, auf der anderen Seite das Durchführungsskript: Das ergibt gut getestete Software und gute Dokumentation. Das alles gepaart mit einem Rechner, der auf dem neuesten Stand ist, so sollte der Freude am Testen nichts mehr im Wege stehen. Das Argument der Kosten kann hier nicht gelten, denn die Kosten für einen unmotivierten Mitarbeiter, der sich mit seinem Rechner ärgert, stehen weit über denen eines Rechners und zweier Monitore.

Mehr von diesem Beitrag lesen

10 things I wished they’d told me – Softwaretestdokumentation

Für alle die bei der Präsentation (1) nicht dabei sein konnten möchten wir hier die Gelegenheit nutzen Ihnen auch einen kompakten inhaltlichen Rückblick zu dem Vortrag und insbesondere eine schriftliche Übersicht der 10 Tipps zu geben.

Gerade mit dem Begriff Testdokumentation werden viele Begriffe und Standards in Verbindung gebracht. Was davon brauchen wir aber wirklich, also was ist der Kern einer guten Testdokumentation? Wie kann ich diesen bei Bedarf weiter ausbauen und optimieren?

Tag Cloud Test Documentation

Tag Cloud der Testdokumentation

Dokumentieren Sie immer die Testdurchführung

Ein Ansatz ist es einfach und schlicht nichts zu dokumentieren. Man bekommt das Testobjekt testet drauf los, schickt die Findings, welcher Art auch immer, direkt an die Entwicklung und diese erledigt eben diese so gut sie kann. Solang das Testobjekt überschaubar ist und die Entwicklung eng mit dem Test zusammen arbeitet, funktioniert dieses Vorgehen zur Beurteilung der Qualität auf Basis der Aussagen eines Testers. Dies ist aber auch implizit der Nachteil, in Wirklichkeit kann keiner außer diesem einen Tester die Qualität beurteilen.  Auch wenn er viel und gut getestet hat, gibt es dafür keinen Nachweis und seine Arbeit ist weder nachvollziehbar noch reproduzierbar. Dies gilt nicht nur für das Management, sondern auch für den Tester selbst. Er kann seine Regressionstests nicht mehr auf dem bereits einmal ausgearbeiteten und durchgeführten Tests aufbauen und hat keine Chance seine eigenen Aktivitäten zu verfolgen.  Aus diesen Gründen sollte man immer zumindest die Testdurchführung, die konkreten Ergebnisse der Durchführung (Test OK, Test Nicht-OK) und die Findings dokumentieren. Die Form der Dokumentation ist in dieser Ausprägung irrelevant, es kann ein Video-Capture der Tests sein oder Dokumentation im Notepad oder bereits in einem Testtool. Die Auswahl der geeigneten Methode ist schon eine Maßnahme der Optimierung, aber oft auch intuitiv gewählt.

Mehr von diesem Beitrag lesen

Kann ich mit einem BMW Radio auch in einem VW Musik hören?

In der Autobranche ist es seit einigen Jahren Usus, dass jeder Hersteller sein eigenes Süppchen kocht.  Der gute alte DIN Schacht wurde nahezu verdrängt und durch die Vernetzung der restlichen Elektronik mit dem Radio ist mitunter ein einfacher Radiotausch auf das nächstbessere Modell selbst für den Hersteller nicht gerade trivial. Die Frage ist somit ganz klar mit „nein“ zu beantworten.

Wie stellt sich nun die Situation dar, wenn ich Testtools von unterschiedlichen Herstellern verwenden möchte oder muss? Nicht immer ist das Automationstool des Herstellers von dem ich das Testmanagementtool habe, für meine Aufgaben geeignet. Eine Integration der beiden Tools oft unmöglich. Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: