IT -Teststrategien, -umsetzung, -technologien

IT -Teststrategien, -umsetzung, -technologien

Posts 1-10 of 10
  • Martin Böhm
    Martin Böhm
    The company name is only visible to registered members.
    Wo zieht man die Testfallgrenzen?
    Hallo,

    in der Vergangenheit habe ich häufiger Diskussionen über die Testfallgrenzen verfolgt, bin aber nie zu einem einheitlichen Meinungsbild dazu gekommen. Dabei ging es darum wo die Testfallendekritieren liegen und ob ein einziger Testfall eventuell mehrere Testszenarios abdecken sollte oder nicht. Dazu ein verkürztes Beispiel:

    --------
    Testpaket: Versandbestückung

    Testfall: Ungepflegten Artikel übernehmen

    Testschritte:
    1. Ungepflegten Artikel suchen
    2. Ungepflegten Artikel selektieren
    3. "Übernehmen" auslösen

    Testergebnis:
    1. Anzeige einer Warnmeldung: "Sie haben einen ungepflegten Artikel übernommen."
    2. Erzeugung einer Aufgabe: "Bitte Artikel xyz pflegen."
    --------

    Während die Anzeige der Warnmeldung ein Teil des eigentlichen Anwendungsfalls "Ungepflegten Artikel übernehmen" ist, ist die Erzeugung einer Aufgabe fachlich gesehen nicht unbedingt als Teil der Artikelübernahme zu betrachten, sondern ein Teil der Aufgabenverwaltung.

    Wo ist hier die Testfallgrenze?

    Um modularer testen zu können, bin ich tendenziell der Meinung, dass hier zwei Testfälle innerhalb von zwei Anwendungsszenarien (Versandbestückung, Aufgabenverwaltung) vorliegen. Es gäbe also einen Testfall "Ungepflegten Artikel übernehmen" innerhalb des Testszenarios "Versandbestückung" und einen Testfall "Aufgabe durch Übernahme ungepflegter Artikel generieren" innerhalb des Testszenarios "Aufgabenverwaltung". Folglich ergeben sich die Testfälle:

    --------
    Testpaket: Versandbestückung

    Testfall: Ungepflegten Artikel übernehmen

    Testschritte:
    1. Ungepflegten Artikel suchen
    2. Ungepflegten Artikel selektieren
    3. "Übernehmen" auslösen

    Testergebnis:
    Anzeige einer Warnmeldung: "Sie haben einen ungepflegten Artikel übernommen."
    --------

    --------
    Testpaket: Aufgabenverwaltung

    Testfall: Aufgabe durch Übernahme ungepflegter Artikel generieren

    Testschritte:
    1. Ungepflegten Artikel in Versandbestückung übernehmen
    2. Aufgabe in Aufgabenverwaltung über Artikelnummer suchen

    Testergebnis:
    Aufgabenliste des Artikels enthält "Bitte Daten von Artikel xyz pflegen."
    --------

    Andererseits wäre ja auch der obige Testfall ausreichend.

    Wie sind ihre theoretischen Vorstellungen dazu und was sind ihre praktischen Erfahrungen? Welche Vorteile und Nachteile sehen sie?

    Ich würde mich freuen, wenn sie ihre Meinung von Fall zu Fall begründen würden.

    Vielen Dank und mit freundlichen Grüßen
    Martin Böhm
    • 07 Oct 2008, 1:43 pm
  • Post visible to registered members
  • Thomas Schlitzer
    Thomas Schlitzer    Premium Member
    The company name is only visible to registered members.
    Re: Wo zieht man die Testfallgrenzen?
    Bei der Entscheidung über die Intensität der Testfälle bzw. der Testfallentwurfsmethode(n) helfen mir folgende Überlegungen:
    - Was erwarten Stakeholder in den Testberichten?
    - Wer will wie detailliert Ergebnisse erhalten?
    - Sollen die Tests oder Teile davon wiederverwendet werden? (idealerweise sollte die Antwort Ja sein)
    - Werden die Tests in absehbarer Zeit automatisiert werden?
    - Habe ich genug Ressourcen, um die Testfälle klar abzugrenzen?
    - Reicht die Zeit dafür?

    Auch hilft es sich Klarheit über Kritikalität der Anforderungen und der Produkt-Risiken zu verschaffen. An manchen Stellen wird es durchaus Sinn machen sehr abgegrenzt und damit intensiver zu testen. An anderen Stellen wird ein "Draufgucken" vielleicht schon ausreichen. Sind die Anforderungen gewichtet und priorisiert? Wenn nein, klären Sie dies mit den "Kunden". Dies ist ein sehr wichtiger Input bei der Entscheidung über die Trennung oder Zusammenfassung von Testfällen.

    Wie schon erwähnt gibt es beim Testen keine Silverbullets. Jedes Vorgehen muss an die Applikation, den Entwicklungsprozess und vor allem an die Stakeholder und das Business angepasst werden. Richtig oder Falsch gibt es nicht, nur schlechte Vereinbarungen.

    Bei der Planung und Strukturierung der Tests sollte man auf ein gute Architektur achten. Das gleiche Verlangen wir ja auch von den Programmierern. Wenn die Architektur "sauber" ist, können die Testfälle später getrennt werden. Bei einer chaotischen Architektur ist dies leider nicht mehr (ohne Weiteres) möglich.

    Bei Ihrem Beispiel würde ich die Testfälle ebenfalls trennen (unter idealen Rahmenbedingungen), da damit die Testfälle modular wiederverwendet, einfacher gewartet und erweitert werden können und eine spätere Testautomatisierung erleichtert wird.
    • 12 Oct 2008, 2:26 pm
  • Martin Böhm
    Martin Böhm
    The company name is only visible to registered members.
    Re^2: Wo zieht man die Testfallgrenzen?
    Hallo Herr Schlitzer,

    Thomas Schlitzer schrieb:
    Auch hilft es sich Klarheit über Kritikalität der Anforderungen und der Produkt-Risiken zu verschaffen. An manchen Stellen wird es durchaus Sinn machen sehr abgegrenzt und damit intensiver zu testen. An anderen Stellen wird ein "Draufgucken" vielleicht schon ausreichen. Sind die Anforderungen gewichtet und priorisiert?
    [...]
     
    Bei der Planung und Strukturierung der Tests sollte man auf ein gute Architektur achten. Das gleiche Verlangen wir ja auch von den Programmierern. Wenn die Architektur "sauber" ist, können die Testfälle später getrennt werden.
    Genau um diese Überlegungen geht es mir, denn die Testfälle können sehr zielführend formuliert werden, weil das Testziel fast ausschließlich fachliche Anwendungsfälle bzw. UseCases beinhaltet.
    Weil es sich auch um zwei separate Anwendungsmodule (wie im Beispiel beschrieben) handelt, würde ich letztendlich die Testfälle trennen, auch weil das Zusammenspiel der Module nicht im direkten Fokus dieser Teststufe liegt. Überdies bin ich zu dem Schluss gekommen, dass das Zusammenspiel beider Anwendungsmodule in einem abgeschlossen Testpaket erst in einer zweiten Teststufe u. U. sinnvoller zu testen ist.

    Vielen Dank an alle Diskussionsteilnehmer
    Mit freundlichen Grüßen
    Martin Böhm
    • 14 Oct 2008, 5:17 pm
  • Bernhard König
    Bernhard König    Premium Member
    The company name is only visible to registered members.
    Re^3: Wo zieht man die Testfallgrenzen?
    Einen Aspekt zur Definition von Testfallgrenzen möchte ich auch noch beisteuen:
    Es kommt darauf an, wer die Tests tatsächlich durchzuführen hat.

    Wenn also die Frage zu klären ist, ob ein bestimmtes Verhalten z.B. rechlich OK ist, kann der Testfall relativ zusammengefasst formuliert werden, wenn der durchführende Tester das entsprechende Fachwissen, im Beispiel juristisches Wissen, mitbringt.

    Wenn der Testfall dagegen von fachfremden Personen durchgeführt werden soll, müssen Sie den Testfall wesentlich genauer definieren. Und hierbei schlägt die bereits aus der Softwareerstellung bekannte Komplexitätsgrenze dann relativ schnell zu, d.h. der Testfall muss als Ganzes durch den durchführenden Tester verstanden werden können, dies führt relativ schnell dazu, dass eben doch besser aufgeteilt wird - genau wie beim Strukturierten Softwaredesign: Probleme werden solange in Teilprobleme zerlegt (d.h. es entstehen weitere Funktionen bzw. Testfälle), bis die Teilprobleme lösbar werden.

    Grüße vom Rhein
    • 15 Oct 2008, 11:57 am
  • Post visible to registered members
  • Thomas Schlitzer
    Thomas Schlitzer    Premium Member
    The company name is only visible to registered members.
    Re^5: Wo zieht man die Testfallgrenzen?
    Beide Antworten sind natürlich korrekt. Mit fachlichen Testern sind aber wohl die Tester aus den Fachabteilungen gemeint und diese benötigen mehr Beschreibungen, um den technischen Teil verstehen zu können. Es geht wohl eher um die Frage, ob ich wirklich jeden einzeilnen Schritt beschreibe oder nicht ("Schalten Sie den PC ein" und ähnliche Randbedingungen). Ein technischer Tester benötigt diese Anweisungen nicht und würde sie wahrscheinlich auch nicht ernst nehmen.
    • 16 Oct 2008, 5:47 pm
  • Post visible to registered members
  • Thomas Schlitzer
    Thomas Schlitzer    Premium Member
    The company name is only visible to registered members.
    Re^7: Wo zieht man die Testfallgrenzen?
    Da gebe ich Ihnen Recht. Das erwartete Ergebnis muss natürlich eindeutig und interpretationsfrei sein. Ich denke, da sind wir uns alle einig. Die Diskussion ging auch eher um die Trennung der Testfälle, wenn ich das richtig verstanden habe. Dieses Thema kann man auf unterschiedliche Arten angehen und ich finde es sehr interessant zu hören, wie dies andere planen.
    • 20 Oct 2008, 1:11 pm
  • Paul Huber
    Paul Huber    Premium Member
    The company name is only visible to registered members.
    Re^8: Wo zieht man die Testfallgrenzen?
    Sehr geehrte Herren,
    meiner Ansicht nach könnte entscheidend sein, wie sich die Software-Architektur darstellt.

    Fall a, strukturiert:
    Wenn für den Vorgang immer dasselbe Modul eingebunden wird, das die Funktion bereitstellt, könnte es meiner Ansicht nach reichen, wenn das Modul einmal freigetestet wird. Und dann beim Einbinden in eine neu entwickelte Software vielleicht nur noch rudimentär getestet wird, ob das Einbinden geklappt hat.

    Fall b, relativ unstrukturiert:
    Wenn die Software nicht zwingend modular ist, würde ich mich schon vergewissern, ob jeder Programmaufruf auch die gleiche Routine aufruft und gleich funktioniert........

    Viel Spaß noch beim Diskutieren!


    Mit freundlichen Grüßen aus Neu-Ulm


    Paul Huber

    PS: Edit mit der Zeit findet man heraus, wie die Kollegen drauf sind.....
    This post was modified on 20 Oct 2008 at 10:17 pm.
    • 20 Oct 2008, 10:08 pm