IT -Teststrategien, -umsetzung, -technologien

IT -Teststrategien, -umsetzung, -technologien

Posts 1-10 of 15
  • Norbert Fux
    Norbert Fux    Premium Member
    The company name is only visible to registered members.
    wie genau sollte ein Testfall dokumentiert sein
    Hallo!

    Ich befasse mich z.Z. mit Grundlagen der Testfalldokumentation und bin dabei recht schnell auf die Frage gestoßen, wie hoch der Dokumentationsgrad eines Testfalls sein sollte. Dies hat dann in weiterer Folge natürlich Auswirkungen auf die Anforderungen eines Testfallverwaltungs-Tools.

    Reicht es den Testfokus (z.B. Kundenanlage) anzugeben und darauf zu hoffen, dass der Durchführende den Testfall schon wird durchführen können.

    Oder sollte man jede einzelne Eingabe dokumentieren und so sicherstellen, dass bei der Durchführung eines Testfalls immer die gleichen Eingaben getätigt werden und im Prinzip jeder (mit IT-Know-How) den Testfall durchführen könnte.

    Ich bin gespannt auf Ihre Ansichten und die zugehörigen Begründungen.

    einen schönen Tag

    Norbert Fux
    • 07 Aug 2006, 11:01 am
  • Ralf Mack
    Ralf Mack
    The company name is only visible to registered members.
    Re: wie genau sollte ein Testfall dokumentiert sein
    Hallo Herr Fux,

    wichtig ist, dass Sie sich Ihre konkreten Randbedingungen (z.B. Know-How der Tester, Zielgruppe: Wer liest die Dokumentation, Kundentauglichkeit erforderlich usw.) und Anforderungen (z.B. Kundenanforderungen, irmeninterne Vorgaben, Vorgaben aus verbindlichen Standards usw.) an die Testfall-Beschreibung vergegenwärtigen und auf dieser Basis festlegen, mit welcher Granularität dokumentiert bzw. spezifiziert werden soll.

    Aus meiner Sicht ist es unter wirtschaftlichen Gesichtspunkten legitim, nur das zu dokumentieren, was die konkretenTester zur Erstellung der Testdaten, Testprozeduren benötigen und der Leserkreis der Dokumentation zum Verständnis benötigt.

    Unabhängig davon empfehle ich, dass Sie sich welche weiteren Testfall-Attribute (z.B. Priorität, Testphase etc.) dokumentiert werden sollen.

    Schöne Grüße
    Ralf Mack
    • 09 Aug 2006, 1:25 pm
  • Norbert Fux
    Norbert Fux    Premium Member
    The company name is only visible to registered members.
    Re^2: wie genau sollte ein Testfall dokumentiert sein
    Hallo Herr Mack!

    Aus meiner Sicht haben Testfälle, in denen nicht alle Eingaben dokumentiert sind zur Folge, dass die Testergebnisse variieren können (nicht einmal ein und der selbe Tester wird einen Tf immer gleich ausführen)
    Natürlich wird sich der Dokumentationsgrad von Tf zu einem Wartungsprojekt von dem von Tf für eine Neuentwicklung unterscheiden, aber mit der Zeit sollten auch die Tf der Neuentwicklung einen hohen Dokumentationsgrad aufweisen.
    Was ich damit meine - man sollte einen hohen Dokumentationsgrad anstreben und auch bei der Toolauswahl berücksichtigen.
    Weiters bin ich der Meinung, dass die Testfalldurchführung von genau dokumentierten Testfällen kürzer dauert, da sich der Tester keine Eingabedaten überlegen muss. Das hat auch zum Vorteil, dass "jeder" als Tester eingesetzt werden kann.

    Schöne Grüße aus Wien

    Norbert Fux
    • 09 Aug 2006, 1:56 pm
  • Ralf Mack
    Ralf Mack
    The company name is only visible to registered members.
    Re^3: wie genau sollte ein Testfall dokumentiert sein
    Hallo Herr Fux,

    bei wenig komplexen Anwendungen mit Benutzeroberflächen mag es funktionieren auf dem Schreibtisch die perfekte Testspezifikation in einem Wurf zu erstellen. Bei komplexen Systemen steigt nach meiner Erfahrung der Aufwand sehr stark an, den man in die Erstellung, Review und Nacharbeit der Testfall-Spezifikation investieren muss. Daraus habe ich für mich einen pragmatischen Ansatz abgeleitet:
    Erst mal nur grob die Testfälle zu spezifizieren, diese dann Überprüfen zu lassen, dann nur symbolische Testdaten zu verwenden. Die konkreten Testdaten kann man notfalls noch während der Testdurchführung dokumentieren, so dass die Tests wiederholt werden können.

    Je perfekter die Testspezifikation ist, umso teurer wird sie. Man muss sich im konkreten Projekt im Vorfeld darauf einigen, ob die Testdurchführung nur von Experten oder von "jedem" gemacht werden kann. Sicher ist das auch eine Frage des Budgets.

    Viele Grüße
    Ralf Mack
    • 09 Aug 2006, 5:14 pm
  • Norbert Fux
    Norbert Fux    Premium Member
    The company name is only visible to registered members.
    Re^4: wie genau sollte ein Testfall dokumentiert sein
    Hallo Herr Mack!

    Das von Ihnen beschriebene Vorgehen bei der Testdatenbefüllung (während des ersten Testdurchlaufes) wird auch von mir praktiziert.

    Da meist nicht nur ein Projekt von einem Tester betestet wird, macht es aber durchaus Sinn jeden Tf möglichst genau zu dokumentieren. Ich habe dabei die erfahrung gemacht, dass dies mit dem entsprechenden Tool nicht kostenintensiver ist. Der Inintialaufwand ist dabei natürlich zu berücksichtigen; dieser kann aber bei den geringeren Vorarbeiten für die spätere Automation wieder gewonnen werden.

    Mit freundlichen Grüßen!

    Norbert Fux
    • 10 Aug 2006, 07:47 am
  • Felix Meulenkamp
    Felix Meulenkamp
    The company name is only visible to registered members.
    Re: wie genau sollte ein Testfall dokumentiert sein
    Die Erstellung eines Testfalls und der dazu gehörigen Testergebnisse ist immer eine Gradwanderung.

    Unser Vorgehen ist hier für gewöhnlich, Testfälle grob schon gegen Ende der Spezifikationphase erstellen. An dieser Stelle kann man positiv auf die Spezifikationabteilung rückwirken und direkt erste Fehler in den Konzepten finden. Als Tester denkt man hier eher an Rand- und Spezialfälle und kann diese dann gegebenfalls direkt in die Spezifikation mit einfliessen lassen.
    Eine Verfeinerung der Testfälle sollte dann während den ersten Implenentationzyklen vorgenommen werden.
    Die ersten Prototypen und Teilimplementationen können hier getestet werden.
    In der späteren Realisierung sollten nur noch Änderungsaufträge in die Testdokumentation einfliessen, die restlichen Testfälle müssen hier ein stabiles Stadium erreicht haben.
    Zum RollOut darf sich an der Testspezifikation natürlich nichts mehr ändern.

    Zur Dokumentation der Testergerbnisse.
    Es muss immer soweit dokummentiert werden, das ein anderer Tester und die Realisierer zusammen mit der Testfallbeschreibung den Fehlerfall korrekt nachstellen können. Kurzum welche Aktionen wurden in einem Fehlerfall kongret ausgeführt und welche Aktionen muss ich Ausführen um den Fehler zu reproduzieren.
    Zudem muss erfasst werden in welcher Umgebung getestet wurde. Auf welchen Servern oder Computern, ob sich an diesen während oder zwischen den Tests etwas geändert hat. Je genauer eine solche Dokumentation ist (in gewissen Grenzen), desto mehr Informationen stehen dem Relisierer bereit den entsprechenden Fehler einzugrenzen und zu beheben. Als ein Minimum hat sich hier herausgestellt, die Server-Client-umgebung, die Versionsnummer der genutzten und getesteten Software sowie die entsprechenden Ausschnitte aus den Logdateien.

    Auch ich kann hier nur zustimmen, ausführlich erstellte Dokumentation kostet nicht mehr Zeit, da sich hiermit unmittelbar Zeit bei der Fehlersuche einsparen lässt.
    Gute Software kann bei diesen Prozess unterstützen, so dass bei einem Testlauf nur noch die Ergebnisse erfasst werden müssen und die Umgebung einheitlich dokumentiert werden kann.
    • 10 Aug 2006, 12:14 pm
  • Martin Böhm
    Martin Böhm
    The company name is only visible to registered members.
    Re^3: wie genau sollte ein Testfall dokumentiert sein
    Hallo Herr Fux,

    ich tendiere bei der Frage der Testfalldokumentation zur Meinung meiner Vorredner.
    Ja, die Testfälle sollten so detailliert wie möglich sein und zwar in Bezug auf das
    angestrebte Testziel bzw. dem verfolgten Testfokus. D. h. dass sogar einzelne
    Tastenanschläge für eine Beschreibung relevant sein können, wenn z. B. in einer
    Eingabezeile die korrekte Reaktion des Cursors von Bedeutung ist (Testfokus des TF :
    Cursorreaktion prüfen).

    Zum Zweiten ist der Detailgrad der Testfalldokumentation auch von der
    Tiefe des Tests abhängig. Soll das Anlegen eines Kundendatensatzes
    getestet werden, ist natürlich das Anlegen im Detail zu beschreiben.
    Ist das Anlegen eines Kundendatensatzes ein einzelner Testschritt, dann
    bedarf es nicht notwendigerweise einer Beschreibung dieser Einzelschritte,
    wenn dies aus Sicht des Testers/Anwenders bereits klar ist. Hier reicht oftmals
    eine Notiz aus, wie der Kundendatensatz angelegt wurde. Z. B. Anlegen
    per Web-Client oder XML-Request.

    Norbert FUX schrieb:
    Hallo Herr Mack!
     
    Aus meiner Sicht haben Testfälle, in denen nicht alle Eingaben dokumentiert sind zur Folge, dass die Testergebnisse variieren können (nicht einmal ein und der selbe Tester wird einen Tf immer gleich ausführen)
    Sollte dieser Fall auftreten, dann ist der Testfall tatsächlich
    unzureichend dokumentiert, denn offenbar führen die Tester
    so unterschiedliche Aktionen aus, dass der eigentliche
    Testfokus verfehlt wird und eine plausible Prüfung des
    Testergebnisses nicht möglich ist. Dies ist allerdings
    Voraussetzung für einen validen Testfall.

    Zum Dritten ist die Abgrenzung der Testfälle von Bedeutung.
    Beispiel: Es soll eine Suchanfrage getestet werden.

    Es macht nun einen Unterschied, ob man testen möchte, ob
    das Ergebnis korrekt angezeigt wird oder ob die korrekten
    Suchtreffer zurückgeliefert werden.

    Für den ersten Fall ist lediglich ein beliebiges valides Suchkriterium
    in die Dokumentation aufzunehmen.
    Für den zweiten Fall ist das Suchkriterium im Detail anzugeben und
    auch das erwartete Ergebnis im Detail zu beschreiben; z. B. je nach
    Detailgrad der TF-Beschreibung die Anzahl der Treffer oder sogar
    die einzelnen Suchtreffer.
    Es wird sofort deutlich, dass hier zwei unterschiedliche Testfälle
    mit unterschiedlichem Testfokus die Suche testen.

    Zum Vierten ist zu Berücksichtigen, das der Detaillierungsgrad der
    Testfallbeschreibung auch vom Implementierungsgrad der Software
    abhängt. Oft ändern sich Button-Bezeichner oder es ist zu Beginn
    der Entwicklung noch gar nicht klar, wie der Anwender durch eine
    Dialogfolge geführt wird.

    Folglich ist die Testfalldokumentation mit dem Entwicklungsgrad
    der Software zu überarbeiten und zu detaillieren. Damit wird gleich-
    zeitig auch gewährleistet, dass Testfälle hinzugefügt, erweitert
    oder detailliert werden, wenn die Software wächst.

    Mit freundlichen Grüßen
    Martin Böhm
    This post was modified on 08 Jan 2007 at 12:33 pm.
    • 08 Jan 2007, 12:28 pm
  • Matthias Schmotz
    Matthias Schmotz
    The company name is only visible to registered members.
    Re^4: wie genau sollte ein Testfall dokumentiert sein
    Guten Morgen zusammen,

    der Inhalt einer Testfallbeschreibung ist m. E. abhängig vom zugrundeliegenden Testobjekt. Ist das Testobjekt eine fachliche Funktion, welche in der fachlichen Feinspezifikation beschrieben ist, haben dort m. E. Tastenanschläge nichts zu suchen, es gibt ja im Idealfall auch noch gar keine darauf aufbauenden DV-technischen Spezifikation. Ein solcher Testfall enthält nun zwar auch Vorbedingungen, Testschritte und erwartete Ergebnisse, allerdings auf einem abstrakteren Niveau. Die Füllung mit Leben erfolgt dann in der nächsten Testaktivität, der Testdatenerstellung, die aus solchen abstrakten Testfällen ein oder mehrere ablauffähige Testdatenkombinationen macht.
    Insofern man also Testfallerstellung und Testdatendefinition trennt, ist auch keine Detaillierung der Testfallbeschreibung notwendig, sofern sich im Rahmen des Projektfortschrittes nur die Testdaten betreffende Dinge geändert haben (z. B. ein Grenzwert im Rahmen einer Grenzwertanalyse).
    Da sich die Art der Testfälle aus dem Testobjekt ergibt, halte ich übrigens auch nicht so viel von standardisierten Testfalldokumenten, wenn schon, dann sollten solche Formulare pro Testobjekt erstellt werden.
    Die Beschreibung der Testdaten sollte aber dann (möglichst) so detailliert erfolgen, dass es egal ist, wer es durchführt.

    Mit freundlichem Gruß

    Matthias Schmotz
    • 09 Jan 2007, 08:12 am
  • Ralf Mack
    Ralf Mack
    The company name is only visible to registered members.
    Re^5: wie genau sollte ein Testfall dokumentiert sein
    Hallo Herr Schmotz,

    ich möchte noch einen zusätzlichen Aspekt in die Diskussion einbringen, nämlich die Leser einer Testspezifikation. Dazu zitiere ich Sie
    Matthias Schmotz schrieb:
    Da sich die Art der Testfälle aus dem Testobjekt ergibt, halte ich übrigens auch nicht so viel von standardisierten Testfalldokumenten, wenn schon, dann sollten solche Formulare pro Testobjekt erstellt werden.
    Die Beschreibung der Testdaten sollte aber dann (möglichst) so detailliert erfolgen, dass es egal ist, wer es durchführt.
    Es gibt Fälle, in denen wird z.B. eine Systemtestspezifikation an den Auftraggeber zum Review und zur Abnahme geliefert oder die Systemtestspezifikation wird von nachgelagerten Gesamt-Integrationsteststufen als Grundlage verwendet. In diesen Fällen wünschen die Leser sicher eine einheitliche Gliederung und einen einheitlichen Aufbau der Testspezifikationsdokumente.

    Auf der anderen Seite ist eine Testspezifikation ein Mittel zum Zweck und sollte möglichst wirtschaftlich erstellt werden. Ich habe den Ansatz, dass man nur dass dokumentieren sollte, was ein eingearbeiteter Mitarbeiter eines Testteams wissen muss um die Testfälle präzise durchführen zu können. Dass sich jemand anhand einer detaillierten TF-Spezifikation effektiv einarbeitet kann, halte ich eher für einen Ausnahmefall.

    Schöne Grüße und erfolgreiches Testen wünscht

    Ralf Mack
    • 21 Jan 2007, 11:51 am
  • Matthias Schmotz
    Matthias Schmotz
    The company name is only visible to registered members.
    Re^6: wie genau sollte ein Testfall dokumentiert sein
    Hallo Herr Mack,

    zunächst einmal gibt es für mich hier wieder das Problem der Namensgebung von Testphasen (oder -stufen, -abschnitten oder wie auch immer;-). Ich vermute mal, Sie meinen hier mit Systemtest einen fachlichen Funktions- und Anwendungstest, oder?
    In meinem Wunschprozess wäre es nun so, dass zunächst einmal auf Basis der fachlichen Feinspezifikation eine Testfallermittlung stattfindet, je nach Testobjekt (nämlich einer Funktion im Falle des Funktionstests bzw. einer Gruppe von Funktionen auf gleiche Datenobjekte im Falle der Anwendungstests) entstehen dann Entscheidungstabellen oder -bäume, Funktionsmatrizen und was es sonst noch so gibt. Die Testfallermittlungsmethode ergibt sich dabei aus der Bedeutung des Testobjekts. Im Falle einer Entscheidungstabelle ist nun beispielsweise eine Spalte der Tabelle ein Testfall, den ich nun hoffentlich automatisch in das "übliche" Format einer Testfallbeschreibung mit Vorbedingungen, Testschritten und erwarteten Ergebnissen überführen kann. Würde ich als Kunde nun eine Abnahme durchführen wollen, wäre mir ggf. mit einer Entscheidungstabelle mehr geholfen als mit einem Ordner direkt ausführbarer Testfallspezifikationen, da ich mir so ein besseres Bild über die Testabdeckung machen kann.
    Diese nochmalige Unterteilung der Testfallermittlung in diese zwei Elemente wirkt sich dann hoffentlich auch positiv auf den Aspekt der Wartbarkeit aus, die meines Erachtens bisher häufig übersehen wird, da sie zur Laufzeit des Projekts nicht so im Fokus steht.
    Was ich nämlich leider immer wieder erlebe sind veraltete Testfälle (die zwar häufig noch zu den veralteten Konzepten passen, aber leider nichts mehr mit der Anwendung zu tun haben).
    Jetzt aber genug gemeckert!

    Mit freundlichem Gruß

    Matthias Schmotz
    • 24 Jan 2007, 06:17 am