Scribd Logo
Hochladen

Willkommen bei Scribd!

  • Agiles Testkonzept

    Hochgeladen von

    wimbo wombo
    404 Ansichten2 Seiten

    Originaltitel

    agiles Testkonzept

    Copyright

    © © All Rights Reserved

    Verfügbare Formate

    RTF, PDF, TXT oder online auf Scribd lesen

    Stufen Sie dieses Dokument als nützlich ein?

    Sind diese Inhalte unangemessen?

    Dieses Dokument melden

    Copyright:

    © All Rights Reserved
    Als RTF, PDF, TXT herunterladen oder online auf Scribd lesen
    Markieren Sie unangemessene Inhalte
    Als rtf, pdf oder txt herunterladen
    404 Ansichten2 Seiten

    Agiles Testkonzept

    Hochgeladen von

    wimbo wombo

    Copyright:

    © All Rights Reserved
    Als RTF, PDF, TXT herunterladen oder online auf Scribd lesen
    Markieren Sie unangemessene Inhalte
    Als rtf, pdf oder txt herunterladen
    von 2

    Agiles Testkonzept

    - das generelle Testkonzept ist beim agilen Testen ähnlich der Test Policy auf hohem Abstraktionsniveau

    - darin definiert sind Prinzipien, Vorgehensweisen und wichtigsten Ziele einer Organisation in Bezug auf
    das Testen, die für jedes Projekt einzuhalten sind

    - möglicher Aufbau:

    Testrichtlinie der Fa. Anonym GmbH


    1. Definition des Testens im Unternehmen
    Unsere Produkte stehen für Qualität. Wir stimmen jede Kundenanforderung mit

    unseren Kunden ab, identifizieren gemeinsam jene, die unseren Kunden am

    wichtigsten sind bzw. den größten Nutzen bringen, und liefern diese zügig und

    mit nachweislicher Qualität.

    Diese Qualität wird nachweislich im gesamten Entwicklungsprozess gelebt.

    2. Definition des Testprozesses


    Von der Erhebung der Anforderungen über den Ansatz des Test-Driven Development begleitende
    Sicherstellung der Qualität durch Tester in den Teams, die die Qualität jeder einzelnen Anforderung aus
    Enduser-Sicht sicherstellen, Automatisierung der Akzeptanzkriterien bis hin zu Regressionstests der
    bestehenden Funktionalität.

    Im Detail:

    a) Backlog Item Quality


    Jeder Eintrag, der in das Product Backlog aufgenommen wird, ist dahingehend zu prüfen, dass dieser das
    richtige Story-Format hat und der vereinbarten Beschreibungstiefe entspricht.

    b) Testbare Akzeptanzkriterien
    Sicherstellen, dass jedes Backlog Item bzw. jede User Story testbare Akzeptanzkriterien aufweist – hier
    sind statische Testtechniken wie Reviews anzuwenden und so lange mit Product Owner, Entwicklern und
    Business Analysten abzuklären, bis alle Kriterien klar sind.

    c) Testaufwand berücksichtigen
    Einbringen der Testsicht bei allen Planungsmeetings, d. h. bei den Komplexitätsschätzungen ist
    sichergestellt, dass auch der Testaspekt berücksichtigt wird.
    d) Testentwurf und Durchführung
    Während der Entwicklungszyklen (Sprints) sind für jedes Akzeptanzkriterium je nach Kritikalität Testfälle
    zu entwerfen, zu dokumentieren und durchzuführen.

    f) Abnahmetest
    Sicherstellung, dass zu jedem Akzeptanzkriterium zumindest ein Testfall erstellt wird.

    g) Traceability
    Jeder Testfall ist eindeutig einer Story zugeordnet.

    3. Sicherstellung der Qualität (Testevaluation)


    a. Vorgaben für Teams bzgl. Entwicklung:
    Jede Funktion ist mittels TDD (Test-Driven Development-/Test First-Ansatz) zu entwickeln. Die so
    entstandenen Unit- und Integrationstests sind im Rahmen der Daily/Nightly Builds laufend
    durchzuführen. Sollten dabei Fehler auftreten („Broken build“), sind diese umgehend zu beheben.

    b. Fertigkriterium (definition of done)


    Fertig ist eine Story (Anforderung) erst dann, wenn alle Kriterien der Definition of Done erfüllt sind.

    c. Qualitätsnachweis
    Der Nachweis ist durch ein Testprotokoll zu erbringen.

    d. Teamzusammensetzung
    Das Team besteht aus Mitgliedern mit crossfunktionalen Skills. Um die Enduser-Sicht in den Teams
    bereits zu berücksichtigen, ist in jedem Team mindestens ein Tester fix einzubinden.

    4. Zu erreichende Qualitätskriterien
    Durch „Definition of Done“-Meldung von Stories ist sichergestellt, dass keine Fehler der Klasse „Blocker“
    und „Schwere Fehler“ vorliegen. Somit ist sichergestellt, dass diese Funktion im Einsatz funktionstauglich
    ist.

    5. Verbesserungsprozess
    Jeder Entwicklungszyklus (Sprint) ist mit einer Retrospektive abzuschließen, in der Rückblick und
    Potenzial für Verbesserungen entwickelt wird.

    Das könnte Ihnen auch gefallen