10 Tipps für eine effektive Meetingführung:

1. An einem Meeting nehmen ausschließlich Teilnehmer teil, die direkt und unmittelbar in das Theman involviert sind.
   * Wer auch sonst?
2. Es gibt ein ausführliches Protokoll, anhand sich sonstige Interessenten informieren können.
   * Dann gibt es auch kein Argument mehr gegen kleine und überschaubare Teilnehmerzahlen.
3. Der Tagesordnungspunkt “Sonstiges” steht an erster Stelle und wird, nachdem er abgehakt ist, nicht mehr aufgenommen.
   * “Sonstiges” wird immer für ausschweifendes Palaver missbraucht. Zu Beginn eines Meetings fehlt den meisten noch das Palaverpulver …
4. Meetings als “Stehung” veranstalten: Keine Stühle, kein Kaffee, nur Stehtische
   * Man ahnt ja garnicht, wie schnell ein Meeting wieder vorbei sein kann …
5. In Runden, in denen alle was zu ihrer Arbeit sagen sollen, Konzept festlegen: z.B. was habe ich gestern gemacht, was gedenke ich heute zu tun, welche Probleme sehe ich?
   * kommen Sie auf den Punkt und zwingen Sie Ihre Mitarbeiter und Kollegen dazu
6. Keine Problemlösungsdiskussionen in Meetings. Problemlösungen werden in Kleinstgruppen mit kompetenten Teilnehmern ausgelagert.
   * Das ist effektiver und zielführender.
7. Themen werden vorher kommuniziert, Ergänzungen während der Sitzung werden nicht akzeptiert, sondern in Kleinstgruppe ausgelagert.
   * Nie wieder ein “Ähh, ich hätte da noch was …!”
8. Powerpoint wird strikt limitiert: Jeder Vortrag unter 10 Minuten braucht kein Powerpoint. Ansonsten 5 min / Folien, keine Death-By-Bulletpoint Folien (Grafiken, Übersichten sind ok), kein Ablesen. Verstöße dagegen führen zu Abbruch des Vortrags von Meetingleitung und Bitte um Überarbeitung.
   * Dringend zu vermeiden: Death-By-Powerpoint
9. Meetings beginnen und enden pünktlich: Wer zu spät kommt, bleibt draußen. Längerdauernde Gespräche werden ausgelagert.
   * Ja, auch erwachsene Menschen brauche ein bißchen Erziehung und Führung. Klingt komisch, ist aber so!
10. Es gibt Regeln, wie Meetings ablaufen sollen, die von der Meetingsleitung durchgesetzt werden.
    * Vielleicht mal ein paar Gedanken machen, was man eigentlich wirklich in son einem Meeting will. Also, vorher.

Was machen Sie, um effektive Meetings sicherzustellen? Ist das alles Unsinn, was ich schreibe?

ANSI 829 Struktur

Insgesamt haben wir also die folgenden Dokumente zu betrachten

Planungsdokumente

Und dann noch die Berichtsdokumente (ohne hierarchische Struktur)

Im Testplan werden Planungselemente beschrieben, so wie man es halt kennt: Personal, Zeitplan, die Testumgebung, welche Softwarekomponenten zu testen sind und was genau (welche Merkmale) so zu testen sind. Darüber hinaus findet man auch Softwaretest-typische Punkte wie Akzeptanzkriterien (welche Kriterien erfüllt sein müssen, damit die Software vom Kunden akzeptiert wird), was zu tun ist, wenn der Test unterbrochen und wieder aufgenommen wird, Informationen zu Risiko und Risikomanagement und vieles mehr.

Zu jedem Testplan gehören verschiedene Spezifikationen. Inhalt der Testspezifikationen ist die Beschreibung der anzuwendenden Testverfahren, die zu testenden Fuktionen, die Pass / Fail Kriterien usw.

Die beiden weiteren Planungsdokumente sind quasi parallel zu betrachten: In der Testvorschrift wird beschrieben, welche Reihenfolge der Testfälle einzuhalten ist und welche speziellen Anforderungen zu beachten sind. Im Testfalldokument stehen die Eingabedaten, die erwartete Ausgabe, Abhängigkeiten zu anderen Testfällen usw.

Wenn ich solche eine (in Dateien oder Papierform) vorliegende Planung in einem Projekt sehe, verziehe ich zwar das Gesicht, aber: hey, man kann es so machen.

Kommen wir doch nun mal zu den Berichtsdokumenten: Um den Übergabebericht kommt man nicht herum. Aber, bitte, ich erstelle doch nicht immer ein Dokument! Wenn man ernsthaft Softwareentwicklung betreibt, dann verwendet man auch eine Quellcode Verwaltungssoftware (z.B. subversion, sourcesafe usw.). Also setzt man einen Tag oder Label und damit ist klar was zu testen ist und wo es zu finden ist.
Die Problemmeldung ist das wahrscheinlich wichtigste Element einer Testdokumentation. Problemmeldungen dürfen auf gar keinen Fall in Form von Dokumenten in einem Verzeichnis dümpeln. Es gibt hervorragende freie OpenSource Software (z.B. Bugzilla), die wesentliche Verbesserungen mit sich bringen. Auf einfache Art und Weise kann nachgehalten werden wer, wann, was berichtet hat und was damit geschehen soll, wie der aktuelle Stand ist und vieles mehr. Machen Sie sich die Mühe auch verschiedene kommerzielle Produkte zu testen. Empfehlung gefällig?

Das eigentliche Durchführen des Testens benötigt Informationen, die einfach zu erfassen sind und beieinander stehen. Testvorschrift und Testfall gehören zusammen und das am besten in einer tabellenartigen Datenstruktur. Man findet viele Produkte in diesem Bereich und kann sehr viel Geld dafür ausgeben. Allerdings kann man kleinere bis mittlere Projekte auch mit Hilfe einer Tabellenkalkulation lösen. In einem Tabellenblatt kann man dann auch einfach Auswertungen vornehmen, so dass der Abschlussbericht gleich mit erschlagen wird. Vielleicht biete ich mal ein, zwei Lösungen dazu zum Download an.

Und was will uns das sagen? Nun, man erkennt daran, die Einstellung der Menschen zu Test, insbesondere derjenigen, die nichts mit dem Test zu tun haben wollen. Sie unterliegen nämlich den

10 Irrtümer des Softwaretest

Irrtum 1: “Testen ist destruktiv und macht alles kaputt!”

Der Softwaretest wird oft als destruktive Tätigkeit gesehen, bei der etwas “kaputtgetestet” wird. Die Kollegen, die sich damit beschäftigen, habe zuweilen einen schweren Stand. Denn sie sabotieren ja die wunderbare konstruktive Arbeit der Entwicklung. So eine Arbeit will man nicht machen, niemals!

Irrtum 2: “Testen geht nur die Testabteilung etwas an! Das sollen die mal machen!”

Es ist aus den Köpfen nicht herauszubekommen, dass Testen die letzte Phase der Entwicklung ist, eigentlich unnötig, weil: es ist ja alles schon fertig.
So gibt es eine klare strukturelle und personelle Grenze zwischen der Entwicklungs- und der Testabteilung. Wir und die anderen. Gerne auch mal gegeneinander.

Irrtum 3:  “Testen kann jeder! Da klickt man halt ein bißchen rum und schaut, ob man was findet.”

Was für eine Ausbildung haben Tester? - Keine! Richtig! Was soll man denn da auch schon groß wissen, was man sich nicht innerhalb von zwei Wochen anlernen kann?

Irrtum 4: “Mit dem Abschluss der Entwicklung ist das Projekt beendet! Da fange ich doch schon mal mit den neuen Aufgaben an!”

Und wenn dann doch noch mal was kommt? Ein Fehler (keine Ahnung, wie der da reingekommen ist …) soll behoben werden. Na, dann bequemt man sich halt, seine aktuelle wichtige Arbeit mal eben zu unterbrechen und, bevor die Kollegen Tester noch lange nerven, das da halt mal schnell rauszubauen.

Irrtum 5: “Wenn es im Projekt eng wird, dann wird halt der Test beschnitten und bis zum letzten Tag entwickelt!”

Muss ja fertig werden ….

Irrtum 6: “Der Test hat mit der Arbeit der Entwickler nix zu tun! Das geht die nix an, wie da gearbeitet wird!”

Schließlich liefert so ein Entwickler ja ein höchstkompliziertes, fragiles, dabei aber auf technisch höchstem Niveau produziertes Kunstwerk ab. So etwas kann man nicht messen, bewerten, beurteilen; davor kann man nur erfurchtsvoll in die Knie gehen.

Irrtum 7: “Wenn der Kunde anruft und einen Wunsch hat, ja dann bau’ ich das halt noch schnell ein!”

Dokumentieren wird nicht gemacht: kostet nur Zeit und der Entwickler weiß doch schließlich, was er getan hat.

Irrtum 8: “Die Qualität unserer Produkte ist mies! Da werden wir wohl mal testen müssen …!”

Denn mit Testen finden wir die Fehler und dann ist alles gut.

Irrtum 9: “Ich bin Entwickler und kein Tester!”

Genau! Schließlich haben die Kollegen schon genug mit ihrer Entwicklungsarbeit zu tun. Da können die sich nicht noch um was anderes kümmern!

Irrtum 10: “Test? Wieso Test? Ich hab’ doch schon alles getestet!”

Alles klar, wenn also ein paar Zeilen Code mal mit dem Debugger durchgesteppt wurden, dann ist der Test beendet! Schließlich habe ich keinen Fehler gefunden.

Bisher dachte ich eigentlich, dass es in der Politik um das Ringen um Lösungen für sehr komplexe Probleme geht (sicher manchmal hart an der Grenze des Erträglichen). Mittlerweile tendiere ich doch deutlich mehr dazu, dass es in der Politik um Macht, Geld, Einfluss und Kontrolle geht. Und in diesem Fall auf dem Rücken und quasi unter Missbrauch der zu schützenden Kinder! - Wie kann ein halbwegs intelligenter Mensch den machtmissbrauchenden Irrsinn, der dahinter steckt, eigentlich noch übersehen, oder sogar leugnen?
Wer es noch nicht getan hat: Bitte beteiligt euch an der Online Petition!

“Ja, wir müssen testen!” ist die schon fast triviale Erkenntnis vieler Softwarehersteller. Und dann? Fange ich mit naivem “Geklicke” an? Oder lerne ich erstmal monatelang etwas über Methoden, Prozesse und Techniken?
Ganz anders: als aller erstes steht die Analyse der eigenen Vorgehensweise, denn ein Test ist immer nur so gut, wie der Reifegrad des Softwareentwicklungsmodelles, das dahinter liegt. Und als weiter wichtiger Punkt ist “persönliche Verantwortung” zu nennen. Was ich damit meine, kommt gleich. Aber eins nach dem anderen.

Wenn bisher Softwareentwicklung “auf Zuruf” betrieben wurde, können von dem Test keine Wunder erwartet werden. Dann ist vielleicht gerade mal ein wenig exploratives Testen möglich, mit sehr dünnem Erkenntnisgewinn.
Ein Prozess, in dem Softwarequalitätssicherung sinnvoll angwendet werden soll, muss ein paar Voraussetzungen erfüllen.

Es gibt einen definierten Softwareentwicklungsprozess - Minimum: Softwareentwicklung findet in Phasen statt

Zu jeder Phase gehört: es wird festgelegt, was entwickelt werden soll, es wird entwickelt und am Ende wird das Ergebnis mit einem “Stempel” versehen. Z.B. einer Version, einer Bezeichnung oder sonst einem eindeutigem Erkennungsmerkmal. Und das ganze in einer vorher festgelegten Zeit. Das ist Minimum!
Das können sie leisten? Prima, dann können wir mit Softwaretesten anfangen.

Wenn sie bereits einen definierten Softwareentwicklungsprozess leben und auch schon irgendwie testen, dann kann es vielleicht sinnvoll sein mal genauer hinzuschauen, wie weit sie mit ihrem Prozess sind und welche Entwicklungsmöglichkeiten sie dann bzgl. des Tests haben. Dazu gibt es eine feine und erschreckend und logische Vorgehensweise namens TPI (Test Process Improvement). Mit Hilfe dieses Modells wird ihr aktueller Testprozess anhand von 20 Kriterien analysiert und mit Hilfe des Ergebnisses eindeutige Anregungen für die Verbesserung des Tests gegeben. (TPI ist eine Entwicklung von sogeti. Unterstützung bekommen sie auch von meinem Arbeitgeber). Bei Gelegenheit mache ich mal einen Artikel zum Thema TPI …

persönliche Verantwortung

In der Praxis begegnet mir immer wieder die Situation, dass QS und Test in einer Firma, Abteilung, Projekt nicht ernst genommen wird. Softwaretest hat keine Lobby. “Ja, muss man ja auch noch machen! Hach, hätte man doch glatt vergessen … tststs!” Das Ergebnis einer solchen Einstellung ist eine unzureichende Qualitätssicherung. Formell wird dann ein vielleicht sogar unternehmensweit vorgeschriebener Testprozess erfüllt, tatsächlich ist das meiste davon Fake.
Meiner Erfahrung nach muss sich in solch einer Situation eine Person persönlich verantwortlich für den Test fühlen und mit seiner ganzen Persönlichkeit in die Bresche springen. Man braucht den Typen, der sich freiwillig die Pappnase aufsetzt und in jeder Besprechung immer und immer den Test-Narren macht. Und dabei hilft es nicht einfach jemanden auszugucken (per Flaschendrehen oder Pinchenziehen), denn der macht den Job nur halbherzig. Am besten scheint mir dann eigentlich ein externer Profi, der es sich leisten kann, losgelöst von den internen Abteilungsbefindlichkeiten zu handeln.
Natürlich ist sowas nicht akzeptabel: aber, hey, irgenwie muss man ja weiterkommen!
Hier mal ein paar Softskills, die solch ein Mensch haben sollte:

• Teamfähigkeit, diplomatisches Geschick
• Kommunikationsfähigkeiten, -geschick
• Kreativität beim Hinterfragen der Gegebenheiten
• Pingeligkeit in der eigenen Arbeit, Durchführung, Dokumentation usw.
• Fähigkeit, sich schnell in fremde Sachverhalte einarbeiten zu können
• Disziplin und strukturierte Arbeitsweise
• Leidensfähigkeit

Also, quasi ein Supermann .

Und jetzt bin ich auf die Kommentare gespannt …

Was ein Wiki ist sollte mittlerweile auch jedermann wissen. Auch hier findet man hervorragende Open Source Lösungen, wie z.b. das Mediawiki, das als Grundlage für die Wikipedia dient.
Atlassian hat auch diese Software professionalisiert (Plugin-Konzept, User Mangement uvm.), so dass sich das Ergebnis mit dem Namen Confluence als ein Knowledge Management Werkzeug darstellt. Immer wenn es gilt, Wissen aus den köpfen der Mitarbeiter in verwaltbare Form zu bekommen ist Confluence das Mittel der Wahl.
Jep, auch Confluence gibt es für 5$. Anwendung? Nun, die gesamte Atlassian Seite beruht auf Confluence.

Allerdings sollte man sich schnell entscheiden, die ganze Aktion geht nur noch bis zum 24. April!

Wer mehr als 5 User benötigt und überhaupt Unterstützung und Beratung rund um die Atlassian Software kann sich natürlich auch an meinen Arbeitgeber wenden …

Was passiert aber, wenn eine Software nicht mehr einfach auf Zuruf entwickelt werden kann? Weil man komplexe Kundenbeziehungen berücksichtigen muss, Spezial-Know-How braucht oder das Projekt eine Größe von mehreren Mannjahren erreicht? Na, klar das geht nur in einem Team, viel Aufwand, Ressourcen, Zeit und Geld. Ja, klar, das kostet Geld. Insbesondere kosten Mitarbeiter Geld. Ein halbwegs funktionierender IBM kompatibler PC kostet heute nicht mehr als 2000 €, die passende Software dazu noch mal 5000 €. Der Arbeitspaltz (Stuhl, Tisch, Büro, Infrastruktur) ist auch nicht so tragisch. Alles in allem hat man Einmalkosten von nicht mehr als 10.000 €. Das ist in etwa das, was ein qualifizierter Mitarbeiter in zwei bis drei Monaten kostet. Und im nächsten Monat kostet er, und im nächsten, und im übernächsten auch.

Deshalb ist immens wichtig Lohnkosten so niedrig wie möglich zu halten, was zu den unschönen Entwicklungen führt, die wir alle in den letzten Jahren (und vermutlich auch in Zukunft) in der Wirtschaft beobachten. Nun, gut, man kommt nicht darum herum.

Nun schauen wir doch mal, was in den einzelnen Phasen einer Softwareentwicklung passiert, wenn ein Fehler entdeckt wird.

Codeerstellung / Coding

Der Entwickler findet, während er den Code schreibt, einen Fehler. In aller Regel kann er das Problem sofort lösen. Schlimmstenfalls muss er kurz Rücksprache mit der Projektleitung und / oder Kollegen halten.

Das Ändern der Codezeilen dürfte, natürlich je nach Art des Problems, in der Größenordnung von wenigen Minuten liegen.

Integration der Teilsysteme

Die Module und Teile einzelner Entwickler und / oder Teams werden zum Gesamtsystem zusammengestellt. Die Fehler, die in dieser Phase i.d.R. auftauchen beziehen sich auf das Zusammenspiel einzelner Teile (Schnittstellen, Kommunikation, Protokolle usw.)

Was passiert also, wenn ein Problem erkannt wird und eine Komponenten nicht zu den anderen passt: Die Komponenten muss geändert werden, vermutlich recht aufwendig. Das System kann (immer noch nicht) im Zusammenhang arbeiten. Wahrscheinlich müssen Diskussionen über Dokumente geführt werden (ist eigentlich alles richtig beschrieben?) und einige Änderungen vorgenommen werden.

Der Zeitaufwand ist schwer zu schätzen, aber ich tu’ es trotzdem: Klärung der Unstimmigkeiten, Überprüfung der Doku usw. ca. 0,5 Tage, Überarbeitung ca 0,5 Tage. Die Behebung des Problems liegt bei ca einem Tag.

Weil bisher kein nennenswerter Testprozess eingeführt ist und das System soweit ja arbeitet, kann man das Ganze ja mal beim Kunden installieren. Nur mal so im

Testbetrieb (beim Kunden).

Und es kommt, wie es kommen muss: der Kunde findet das seine Geschäftsvorgänge in der Software, zumindest an einer Stelle, nicht richtig abgebildet werden. Natürlich gibt es Gespräche, Abstimmungsbedarf (im besten Fall) oder gerne auch mal Schuldzuweisungen, Drohungen, Zahlungszurückhaltung. Den Schlamassel zu klären dürfte einige ‘Tage dauern.

Ich muss, glaub’ ich, nicht weiter schreiben. Was passiert wohl, wenn ein echtes Problem im Livebetrieb beim Kunden auftaucht. Regressvorderungen, Produktionsausfall, blablabla. Viel Spass, das wieder in den Griff zu bekommen!

Und was soll mir das jetzt sagen?

Tja, ein paar Dinge muss man sich mal vor Augen halten:

1) Ziel ist es nicht, eine fehlerfrei Software abzuliefern (das geht eh nicht. Wer mag kann die Gründe in der einschlägigen Literatur nachlesen), sondern zu wissen, wo man steht.

2) Wie man oben gesehen hat,muss mit sinnvollen QS - Maßnahmen aus wirtschaftlichen Gründen so früh wie möglich begonnen werden.

3) Von einem Problem beim Kunden überrascht zu werden grenzt an eine Katastrophe. Wichtig ist vorher zu  klären wie hoch die Wahrscheinlichkeit ist, dass das eintritt und sich entsprechend betriebswirtschaftlich darauf vorzubereiten.

Also: sinnvolle QS - Maßnahmen, so früh wie möglich angesetzt, sparen Geld, vermeiden Chaos und Unstimmigkeiten und führen zu erweiterten, wichtigen Wissen über das eigene Produkt.

Natürlich habe ich nicht alles hier aufgeführt, was man an dieser Stelle schreiben könnte. Aber ich denke, der Kern ist klar geworden und bietet schon mal ein paar gute Argumente.

Noch Fragen?