IT -Teststrategien, -umsetzung, -technologien

IT -Teststrategien, -umsetzung, -technologien

Posts 11-15 of 15
  • Martin Böhm
    Martin Böhm
    The company name is only visible to registered members.
    Re^7: wie genau sollte ein Testfall dokumentiert sein
    Hallo Herr Schmotz,

    in der Tat ist es so, dass die Testfallbeschreibung nicht unbedingt nur
    eine Prosabeschreibung dessen sein muss, was der Tester zu tun hat.
    Ich sehe den Idealfall so, dass eine Prosabeschreibung vorhanden sein
    sollte, um einfach den Testfall und dessen Zweck an sich zu verstehen
    und korrekt ausführen zu können. Nicht jeder Tester ist mit jedem Test-
    fall im Detail vertraut. Und nicht jedem Tester ist die Systematik einer
    Exceltabelle mit Testinformationen bekannt. Auch das gehört in die
    allgemeine Beschreibung eines Testfalls hinein, wie solche Testhilfs-
    mittel gegebenfalls zu interpretieren und zu verwenden sind.

    Das Handling der Testfälle selbst kann sich durch die Verwendung
    von Entscheidungsbäumen, Tabellen etc. aus Sicht des Testers
    erheblich vereinfachen. Auch die Auswertung und Beurteilung der
    Testergebnisse wird dadurch ohne Zweifel einfacher.

    Wie Sie schon angesprochen haben, kann der Kunde, der die Software
    abnimmt, die Qualität der Software dann wesentlich einfacher beurteilen -
    ein Blick aufs Tableu und er weiß Bescheid, wie weit die Tests gediehen
    sind, wo Fehler sich häufen und welche Teile der Software er guten
    Gewissens abnehmen kann.

    Entscheidend, und dabei denke ich an den Beginn der Diskussion, ist aus
    meiner Sicht, dass die Art der Testfallbeschreibungen auf die Testobjekte zugeschnitten
    sein sollten und gleichzeitig eindeutig und verständlich für den Tester sind.
    Und letztendlich sollte die daraus resultierende Testausführung mit
    geeigneten Hilfs- und Prüfmitteln ausreichend unterstützt werden.

    Mit freundlichen Grüßen
    Martin Böhm
    • 30 Jan 2007, 11:26 am
  • Katja Piroué
    Katja Piroué    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^8: wie genau sollte ein Testfall dokumentiert sein
    Hallo in die Runde,

    Diese Frage wird in jedem Projekt gestellt und ist letztendlich eine philosophische.
    Die häufigste Antwort (soviel wie möglich jedoch soviel wie nötig) ist daher keine wirkliche Hilfe.

    Aus meiner Sicht sind folgende Ansätze umfeldunabhängig die wichtigsten.

    1) so früh wie möglich (d.h. sobald es abgenommene Spezifikationsdokumente gibt) - so genau wie ein Tester wird keiner im Überblick alle zu einem Testobjekt vorhandenen Dokumente haben.

    2) auf alle Fälle sind logische und konkrete Testfälle zu trennen.

    Was bedeutet das? Der logische Testfall beschreibt den tatsächlichen fachlichen Ablauf, der konkrete Testfall ist mit dem dazugehörigen Datensatz angereichert.

    Warum ist das so wichtig?
    zum einen ist die fachliche Logik meist früher bekannt, als die technische Umsetzung (und das nicht nur in Projekten, in denen nach dem V-Modell gearbeitet wird)
    zum anderen ist in Fragen der Wartung essentiell, dass man sowenig wie möglich Anpassungsbedarf hat.
    und drittens wird, sobald man Testfälle wiederverwenden möchte (z. B. aus Funktionstestfällen Testfallketten für den Integrations- oder den Abnahmetest zu erstellen) eine Trennung das K.O. Kriterium sein - das gilt selbstverständlich auch für Fälle, in denen die Tests in der Zukunft auch automatiert werden sollen.

    3) Alle Testfälle sind in einheitlichen Strukturen abzulegen
    JAAAAAA!
    weiter oben wurde das bereits diskutiert. Man darf nicht vergessen, dass in vielen Projekten Kollegen Testfälle erstellen, die noch nie vorher etwas mit der Testfallerstellung zu tun hatten. Jede Form von Gerüst und Stütze wird dabei eine Hilfe sein.

    Zusätzlich erhöht es die Qualität, da z.B. wichtige Angaben nicht vergessen werden können.

    und letztendlich erhält eine Struktur auch die Möglichkeit, diese Daten in einer nachgelagerten Projektphase in ein Werkzeug zu überführen. Hiervon ausgenommen sind aus meiner Sicht die vielen Testfälle, die in Worddokumenten angelegt wurden. Hier ist an automatischen Datenimport nicht mehr zu denken. In Unternehmen mit solchen Strukturen ist bei Automatisierungsbeginn oder anderer Werkzeugeinführung mit erheblichem Mehraufwand in der initalen Phase zu rechnen.

    4) Inhaltliches
    jeder Testfall ist so zu beschreiben, dass eine 2. oder 3. Person, die den Fall nicht selber verfasst hat, diesen exakt reproduzieren kann.
    Diese Anforderung ist aber natürlich im Zusammenhang Budget und auch Termindruck des Projektes anzupassen.

    5) Zuordnung zu den abgedeckten Anforderungen

    es muss sichergestellt werden, dass ich im Falle eine Anforderungsänderung auch die entsprechenden Testfälle wiederfinde. Dies sollte mit sowenig Aufwand wie möglich vonstatten gehen. Die Referenzierung der Testfälle ist excelbasiert meist ein schwieriges Thema, ein Testtool sollte diesen Service selbstverständlich zur Verfügung stellen.

    diese fünf Kernpunkte sind eine Kurzzusammenfassung und es gibt zu diesem Thema eigentlich noch VIEL mehr zu sagen, allerdings möchte ich den Bogen hier nicht überspannen.

    mit freundlichen Grüssen
    Katja Piroué
    • 02 Feb 2007, 10:01 am
  • Ralf Mack
    Ralf Mack
    The company name is only visible to registered members.
    Re^9: wie genau sollte ein Testfall dokumentiert sein
    Guten Morten Frau Piroué, Guten Morgen die Herren,

    irgendwie scheint einem das Testen selbst an einem Samstag morgen nicht loszulassen... Und nun zur philosophischen Frage von Frau Piroué:

    Ganz klar es gibt zwei Schulen aus meiner Sicht:
    - Schule 1 hätte am liebsten Testfälle, die so detailliert sind, dass man zur Testdurchführung kein Fachwissen benötigt, wie der berühmte Mann von der Straße.
    - Schule 2 wird von den Minimalisten vertreten, die nur soviel dokumentieren möchte, dass ein Fachexperte die Testfälle eindeutig unterscheiden kann (Darauf kann selbst der Minimalist nicht verzichten). Konkrete Testdaten in einer Testspezifikation sind Schule 2 sicher ein Graus.

    Die Vor-und Nachteile der beiden Positionen kann man in der obigen Diskussion schön nachverfolgen.
    Ich persönlich mehme als Hauptzutat Schule 2 und Würze mit einem Hauch von Schule 2. Man muss das Gericht eben so abschmecken, dass es den meisten Gästen (bzw. Umfeld) schmeckt :-)

    Schöne Grüße und Danke für die rege Diskussion.

    Ralf Mack
    • 03 Feb 2007, 10:50 am
  • Matthias Schmotz
    Matthias Schmotz
    The company name is only visible to registered members.
    Re^10: wie genau sollte ein Testfall dokumentiert sein
    Hallo nochmal,

    ein Problem scheint mir der Begriff des Testfalls an sich zu sein. Ich vertrete die Ansicht, dass ein Testfall eine abstrakte Beschreibung dessen ist, was abgeprüft werden soll, altes Beispiel Äquivalenzklassenanalyse, Abhebung am Geldautomat, Eingabe eines Wertes größer dem maximalen Abhebewert, Ergebnis Fehlermeldung "Geht net" (der Automat steht in Hessen). Das ganze stünde zunächst mal in einer Spalte einer Entscheidungstabelle. Aus dieser Spalte sollte man nun eine Testfallbeschreibung ableiten können (nach Möglichkeit automatisiert), die die weiteren Informationen des zugehörigen Testobjekts enthält (also z. B. Testprojekt = Geldautomat, Testphase = Funktionstest, Testobjekt = Geld abheben usw.).
    Zu diesem (abstrakten) Testfall können nun 1 bis n Testdatenkombinationen/konkrete Testfälle abgeleitet werden, wiederum hoffentlich automatisiert. Hier stünde nun z. B. bei einem entsprechenden Wertebereich von > 500 Euro bis < 1.000 im Falle einer Grenzwertanalyse TDK 1 = 501, TDK2 = 750 und TDK 3= 999. Wenn der Kunde dies wünscht, kann er nun eine komplette Beschreibung erhalten, bei der zudemdie Herleitung noch transparent ist. Ändert sich nun der untere Grenzwert, kann der Testfall unverändert bleiben und TDK 1 muß angepaßt werden. Befinden sich immer alle Informationen in einer Testfallbeschreibung der Schule 1, haben wir schon Redundanzen, die dann erhöhten Pflegeaufwand im Falle von Änderungen erfordern. Im übrigen finde ich die Paarung Testfälle/Testdatenkombinationen griffiger als logische Testfälle/konkrete Testfälle, aber das ist sicher Geschmackssache. Noch eine Anmerkung zur Strukturierung, ich bin schon auch der Meinung, dass der formale Aufbau einer Testfallbeschreibung gleichartig sein sollte (eben jene Angaben wie Testprojekt, Testphase, Testspezifikationstechnik etc.), nur die "innere" Struktur sollte sich am Testobjekt orientieren, um nicht zuviel Overhead zu erzeugen.
    Eine Anmerkung noch zur Lesbarkeit der Testfälle, die Inhalte könnte man entweder im Testkonzept/Methodenhandbuch erläutern und/oder schulen, sodass auch die neu mit dem Thema betrauten Kollegen damit zurechtkommen.

    Mit freundlichem Gruß

    Matthias Schmotz
    • 03 Feb 2007, 5:51 pm
  • Katja Piroué
    Katja Piroué    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^11: wie genau sollte ein Testfall dokumentiert sein
    Zur Begrifflichkeit

    Matthias Schmotz schrieb:
    >Im übrigen finde ich die Paarung Testfälle/Testdatenkombinationen
    griffiger als logische Testfälle/konkrete Testfälle, aber das ist sicher Geschmackssache.
    Die Begriffe kommen aus den offiziellen Lehrplänen der ISTQB und werden daher von mir als kleinster allgemeingültiger Nenner verwendet.

    Denn wie wir alle wissen, gibt es in jedem Unternehmen unterschiedliche Begriffswelten.

    wochenendliche Grüsse
    Katja Piroué
    This post was modified on 03 Feb 2007 at 06:31 pm.
    • 03 Feb 2007, 6:30 pm