Zusammenfassung des Treffens am 07.12.2007 in Stuttgart

Einführung von Testprozessen

Auf dem Treffen haben wir uns weiter mit dem Thema "Einführung von Testprozessen" befaßt.

Herangehensweisen an das Testen

Auf der vorangegangenen Sitzung in Nürnberg wurde die Idee geboren, uns mit einem Vortrag von Brett Pettichord auseinanderzusetzen in dem 4-5 "Schulen" beim Testen identifiziert werden. In unserer Arbeit hatten wir den Titel "Herangehensweisen" gewählt.

Maud Schlich und Thomas Roßner haben freundlicherweise einen Einführungsvortrag und einen "Psychotest" vorbereitet. Im großen Kreis der Fachgruppe wurde die Befragung durchgeführt, um herauszufinden wie die Teilnehmer der TAV bezüglich der Schulen einzuordnen sind.

Der Einführungsvortrag zu den Herangehensweisen und die Testergebnisse stehen im Download-Bereich zur Verfügung

Insgesamt ist während der Diskussion der Eindruck entstanden, die Schulen seien möglicherweise zu sehr aus Sicht der Context-Driven School charakterisiert worden.

Wir wollen daher auf dem nächsten Zwischentreffen die Positionen der einzelnen Schulen nochmals im Detail beleuchten.

Requirements-Engineering und Test

Da die TAV 27 in Zusammenarbeit mit der Fachgruppe Requirements-Engineering durchgeführt werden soll, hat sich der Arbeitskreis entschlossen, sich auf dieses Thema vorzubereiten.

Begonnen haben wir mit einem Fragenkatalog:

Ausgangspunkt:

  1. Beim Requirements-Based Testing sind oft keine sauberen Requirements vorhanden, sondern nur Entwürfe (Lösungsbeschreibungen)
  2. Wenn Requirements vorhanden sind, dann sind sie oft nur schwer testbar
  3. Was haben Requirements mit uns zu tun?
  4. Helfen explizit formulierte Requirements?
  5. Sollten wir nicht auch ein paar Requirements formulieren dürfen?

Neue Trends:

  1. Werkzeuge zum Testmanagement werden populär (z.B. Borland Silk Central, HP Quality Center), dort existieren Möglichkeiten, sogenannte Testrequirements abzulegen ("Was soll ein Test tun?")
  2. Test Driven Development: Testfälle sind ausführbare Requirements Fehler = Anforderung, alles wird in einem ?Stack? gehalten

Fragen zum Diskutieren:

  1. In Projekten ohne juristischen Vertrag sind oft die Anforderungen mit der Lösungsbeschreibung vermischt. Gibt es eine reale Chance, sie zu trennen? Welche Vorteile würde das bringen?
  2. Die sogenannten Requirements in der Praxis haben einen Doppelcharakter: Sie sind Verwaltungsgegenstand im Projektmanagement (Einmalaufträge in Listen) und inhaltliche Forderung, die länger Bestand hat, oft über mehrere Releases hinweg. Muss dies getrennt verwaltet werden?
  3. Wenn die Testfälle zu konkret sein sollten, wären doch die Testrequirements (die Stoffsammlung der Tests oder das ?Inhaltsverzeichnis?) der ideale Ersatz für das eigentliche Requirements-Management?
  4. Statt Einzeldaten wird im Unit-Test (z.B. mit JUnit) mit sog. Theorien getestet. Gibt es dazu ein Pendant auf der Systemtest-Ebene?
  5. Wie können die Entwickler solche hierarchisch strukturierten Sammlungen erstellen, wenn Sie mit WORD vertraut sind?
  6. Wie gestalten sich die Beziehungen zwischen den inhaltliche Aspekten und dem Projektmanagement?
  7. ?Erweitertes Single Source-Prinzip?: Könnte auf der einen Seite Code und Entwurf/Lösungsbeschreibung zusammenwachsen (Single Source im engeren Sinne), auf der anderen Seite die Anforderungen mit den Testfällen als Implementation, ebenfalls Single Source?
  8. Verhältnis Anforderung -Fehler: Wann steigt ein Fehler zu einer Anforderung auf?

Weitere Fragen zur Diskussion sind jederzeit willkommen.

Zudem haben wir uns mit einigen Internet-Seiten zum Thema Requirements-Engineering befaßt. Insgesamt fühlten wir uns als Tester dort jedoch "mißverstanden". Dieses Bild vom Testen wird auf dem kommenden Zwischentreffen ebenfalls thematisiert werden

Nächste Termine

Für die weitere Arbeit im Arbeitskreis haben wir uns schließlich folgendes Programm vorgenommen:

15. Februar 2008:Zwischentreffen des AK in Wiesbaden:
  1. Vertiefung des Themas "Herangehensweisen"
  2. Vorbereitung des nächsten Treffens, Thema: Requirements-Engineerig und Test.
Juni 2008:Arbeitskreissitzung im Rahmen der TAV 27 in Bad Honnef

 

Falls Sie sich an der Vorbereitung des nächsten Treffens beteiligen möchten, wenden Sie sich bitte an:

bernhard.moritz@cc-gmbh.de

 


Zurück zur Übersicht