TestmanagementDie Welt verändern, ein Bug nach dem anderen…

Stacks Image 332824

Scrum Framework

  • Was ist Scrum?

    Open or Close
    Stacks Image 1560835
    Scrum ist ein agiles Managementframework zur Entwicklung von Software.

    Als agiles Framework verkörpert Scrum die Wert des Agilen Manifests (Beck et al. 2001). Dieses stellt den Menschen in den Mittelpunkt der Softwareentwicklung. Scrum ist nicht technologie- oder toolorientiert. Das Agile Manifest formuliert die Optimierung von Kundenzufriedenheit und Wertschöpfung als Ziel der Softwareentwicklung.

    Scrum ist ist ein Framework für eine kontinuierliche Produktentwicklung und nicht eine Projektmanagement-Methode.

    Die Rolle des klassischen Projektleiters kennt Scrum nicht.

    Eine hervorragende Übersicht über die Zusammenhänge zeigt Mahud Laulin (Auszug) via Scrum Alliance:
    Stacks Image 1560837
    Zertifizierungen zum Scrum Master oder Product Owner können erfolgen via
  • Rollen
    Open or Close
    Das Scrum Framework kennt 3 Rollen (=Scrum Team): Product Owner, Scrum Master und Entwicklungsteam. Für die Organisation größerer Einheiten und mehrerer Teams gibt es spezielle Frameworks mit weiteren Rollen.
    Produkt Owner (=PO)
    Der PO ist verantwortlich für den Mehrwert des Produkts und der vom Team gelieferten Produktinkremente.
    Er pflegt das Product-Backlog.
    Er ist Produktverantwortlicher gegenüber dem Unternehmen.
    Der PO ist verantwortlich für die Aufnahme, Pflege und Priorisierung aller Anforderungen.
    Der PO erstellt den Releaseplan und die Releaseberichte.
    Der PO sollte täglich ca. eine Stunde mit dem Team arbeiten, z.B. nach dem Daily-Scrum.

    Scrum Master (=SM)
    Der SM ist verantwortlich, dass Scrum verstanden, richtig angewendet wird, das Team effizient und mit bestmöglicher Qualität arbeiten kann.
    Unterstützung des PO bei der Erstellung des Product-Backlogs.
    Sicherstellung der benötigten Testumgebung.
    Schützen des Teams vor Zuweisung von Spezialaufgaben und Abziehen von Mitarbeitern aus dem laufenden Sprint.
    Der SM fungiert als Servant-Leader (= dienende Führungskraft).
    Hilfreiche Skills des SM: Moderationstechniken, Coaching und Erfahrung in der Software-Entwicklung.
    Der SM beseitigt Hindernisse.
    Der SM ist nicht der Projektleiter und er weist dem Team auch keine Aufgaben zu.
    Der SM zählt meist nicht zu dem Team hinzu.

    Entwicklungsteam (=Team)
    Das Entwicklungsteam erstellt bis zum Ende eines jeden Sprints ein fertiges und potentiell auslieferbares Produktinkrement.
    Darf keine Anweisungen außer vom PO entgegennehmen.
    Nur der PO darf das Team anweisen die Anforderungen aus dem Product-Backlog umzusetzen.
    Das Team besteht nur aus Entwicklern (Entwickler, Tester, Administratoren, Test- und Qualitätsmanager u.a. Spezialisten).
    Das Team besteht aus 3 bis 9 Mitgliedern.
    Das ideale Teammitglied ist sowohl Spezialist als auch Generalist.

    Stakeholder
    Stakeholder sind Rollen außerhalb von Scrum. Zu den Stakeholdern zählen: Marketing-, Vertriebs-, Service-, IT-Mitarbeiter und Kunden/Anwender.

    Anmerkung zur Rollenwahrnehmung
    Nicht jeder im Team muss alles können. Vielmehr muss das Team als Ganzes alle Fähigkeiten mitbringen, die zur Produktentwicklung und Qualitätssicherung benötigt werden. Tester, Testmanager, Qualitätssicherer haben in agilen Projekten durchaus ihre Berechtigung (Built-In-Quality).
  • Berichte, Hilfsmittel, User Stories, Definitionen u.a.
    Open or Close
    Anforderungsworkshop
    Verfeinerung der hochprioren Anforderungen durch den PO mithilfe eines oder mehreren Anforderungsworkshops vor dem ersten Sprint unter Einbeziehung des gesamten Teams.

    Story Cards
    Das sind Anforderungen, die auf Karteikarten geschrieben werden.

    Teamkapazität
    Ca. 20-35 % liegt die Nettoteamkapazität unter der Bruttokapazität.

    Aufwandsschätzung (Story Points)
    Storypoints beschreiben die Größe einer User Story, nicht die Zeitdauer.
    Die Größe einer Story ergibt sich aus ihrer Komplexität. Es geht nicht um die Zeitdauer, die benötigt wird, um die Story umzusetzen, sondern um eine Eigenschaft der „Struktur“ der User Story. Das bedeutet, dass die wachsende Erfahrung eines Teams und schnellere Abarbeitung von Stories die Größe einer Story nicht verändert, denn die Eigenschaften der Story haben sich nicht geändert. Der Zeitfaktor wird in Scrum durch die Velocity bestimmt. Sie ist der Durchschnitt über die Summe aller vom Team erledigten Story Points pro Iteration.

    Zur Aufwandsbestimmung werden Story Points verwendet, z.B. nach der Fibonacci-Funktion:

    Bildschirmfoto 2016-02-08 um 19.37.41
    Das ergibt eine Punktereihe:
    • 0 (kein Aufwand),
    • 1 (sehr kleiner Aufwand),
    • 2 (kleiner Aufwand),
    • 3 (mittlerer Aufwand),
    • 5 (großer Aufwand),
    • 8 (sehr großer Aufwand),
    • 13 (riesiger Aufwand).
    Es werden meist mehrere Schätzklausuren noch vor dem ersten Sprint abgehalten. Das Ergebnis fließt in das Product Backlog ein. Auch während eines Sprints werden Schätzklausuren durchgeführt.
    Das Abschätzen erfolgt ausschließlich durch das Team.
    Eine Aufwandsbestimmung kann beispielsweise auch nach T-Shirt Größen erfolgen: S, M, L, XL, XXL…
    Zum Abschätzen kann auch ein Planungspoker verwendet werden.

    Planungspoker
    Das ist eine in Scrum verwendete Methode, um Aufwände abzuschätzen. Unter Verwendung von Spielkarten auf denen Story Points abgedruckt sind, erfolgt nach Vorstellung durch den PO der jeweiligen User Story die unabhängige Schätzung der Teammitglieder solange bis ein Konsens vorliegt.
    Die in nachfolgender Abbildung verwendeten Spielkarten stammen von der Itemis AG bei der der Autor einen Scrum Master Kurs besucht hat.
    Stacks Image 1560839
    Releaseplan
    Der Releaseplan enthält die Anzahl der benötigten Sprints und die Reihenfolge der Umsetzung der Anforderungen aus dem Product Backlog.
    Der PO erstellt diesen Plan.

    Release Burndown Bericht
    Dieser Plan wird am Ende eines jeden Sprints aktualisiert.
    Er enthält die Summe der Aufwände im Product Backlog am Ende eines jeden Sprints. Die ideale Burndown-Linie berücksichtig keine Abwesenheitszeiten. Durch den Vergleich des idealen Fortschritts mit dem realen Fortschritt sieht man wie sich der tatsächliche Fortschritt entwickelt hat.

    Entwicklungsgeschwindigkeits Bericht
    (Entwicklungsgeschwindigkeit=Velocity)
    Die Velocity wird für den den Releaseplan benötigt. Die Entwicklungsgeschwindigkeit ist die Summe aller Aufwände der am Ende des Sprints vom PO abgenommenen Arbeitsergebnisse.
    Teilweise fertiggestellte oder defekte Arbeitsergebnisse fließen nicht mit ein.
    Wenn am Anfang der ersten Sprints kein Releaseplan vorliegen muss, kann die Entwicklungsgeschwindigkeit empirisch festgestellt werden. Beispielsweise wird eine maximale Geschwindigkeit mit 20 Punkten angenommen. Die Erfahrung zeigt, dass im ersten Sprint meist nur eine Geschwindigkeit von 60 % erreicht wird, die im Laufe der nachfolgenden Sprints zunimmt.

    Sprint-Endebericht (end-of-sprint report)
    Dokumentation wie viele der geplanten Anforderungen vom PO abgenommen wurden.
    Der Bericht enthält die wesentlichen Rahmendaten des Sprints.
    Erstellung durch den PO im Sprint-Review oder im Anschluss daran.
    Der Bericht ist wiederum Input für den Release-Burndown- und Entwicklungsgeschwindigkeitsbericht sowie den Releaseplan.

    Hindernisbericht (impediments charts)
    Erstellt der SM im Daily-Scrum. Aus dem Hindernisbericht wird u.a. ersichtlich wie viele Hindernisse den Sprint-Fortschritt behindern.
    Definition of Done (=DoD)
    Definition of Done (DoD) sind Fertigstellungskriterien, die das Development-Team zur Erstellung des Produktes zu beachten hat. Die Hoheit über die DoD liegt beim Development-Team.
    Zu den DoD zählen:
    Alle Akzeptanzkriterien wurden erfüllt. Der Code wurde fertiggestellt und im Versionierungssystem eingespielt. Dokumentation Update wurde durchgeführt. Release Dokumentation wurde angepasst. Es wurde ein Code Review durchgeführt oder der Code wurde im Pair Programming erarbeitet. Coding Guidelines und Standards wurden eingehalten. Es wurden Unit-Tests erfolgreich durchgeführt. Es sind keine kritischen Bugs offen. Funktionale Tests wurden erfolgreich durchgeführt.

    Definition of Ready (=DoR)
    Definition of Ready (DoR) sind Kriterien, die an die Product Backlog Items (User Stories) gestellt werden.
    Nur Product Backlog Items im Status READY dürfen in einen Sprint. Bei der "Definition of Ready" ist der Product Owner verantwortlich für die Einhaltung.
    Backlog Items sind klein genug, um sie in dem jeweiligen Sprint umzusetzen. Backlog Items sind für jeden Beteiligten klar verständlich. Jedes Backlog Item ist geschätzt. Jedes Backlog Item hat Akzeptanzkriterien. Funktionale und nicht funktionale Anforderungen werden beschrieben.
    DoR sollten folgenden Anforderungen nach Independent, Negotiable, Valuable, Estimatable, Small und Testable (INVEST) genügen.
    DoR müssen vorliegen bevor das Development-Team die UserStory in die Sprint-Planung übernimmt.

    Taskboard/Kanban-Board
    Ein Taskboard dient der Visualisierung des Sprint Backlogs in mindestens vier Spalten.
    Spalte 1: Anforderungen aus dem Product Backlog
    Spalte 2: Alle zu erledigenden Aufgaben
    Spalte 3: Aufgaben in Bearbeitung (Development und Testing)
    Spalte 4: Erledigte Aufgaben
    Ein Taskboard ist kein Kanban-Board. Ein Taskboard ist für Teams, die ihre Arbeit in Sprints planen. Kanban-Boards kennen kein Product Backlog.
    Nachfolgendes Scrum-Board ist wie folgt aufgebaut:
    • Backlog (Stories)
    • Selected (To Do)
    • Development (In Progress)
    • Testing
    • Done
    Im Daily Scrum wird das Taskboard aktualisiert.
    Tasks, die einem Tag nicht beendet werden können, werden markiert.
    Idealerweise arbeitet das Team immer nur an einer User Story.
    Stacks Image 1560841
    User Stories, Akzeptanzkriterien und Akzeptanztests
    User Stories beschreiben die Anforderungen aus Sicht des Benutzers unter Verwendung der Alltagssprache.
    Eine User Story beschreibt immer die gewünschte Produkteigenschaft und den damit verbundenen Nutzen.
    Das Design der User Stories erfolgt im Sprint Planning. Hier werden die User Stories entworfen und die dazugehörigen Tasks festgelegt. Ein Task sollte innerhalb eines Arbeitstages erledigt werden können.
    Der PO formuliert die Akzeptanzkriterien, stimmt sie mit dem Kunden ab und notiert sie zu den jeweiligen User Stories. Der dazugehörige Akzeptanztest stellt dar wie die beschriebenen Eigenschaften getestet werden sollen.
    Auch für EPICS (große User Stories) sollten Akzeptanzkriterien erstellt werden.

    Eigenschaften guter User Stories (Akronym INVEST):
    IIndependentUser Stories sollen unabhängig voneinander sein
    NNegotiableUser Stories sollen verhandelbar sein
    VValuableUser Stories sollen einen Wert für den Kunden haben
    EEstimatableUser Stories sollen schätzbar sein
    SSmall User Stories sollen klein sein
    TTestableUser Stories sollen testbar sein
    Burn-Down-Chart
    Das Burn-Down-Chart dient der Visualisierung bereits geleisteter und noch verbleibender Arbeit.
    Das Entwicklungsteam aktualisiert im Daily Scrum das Sprint Burn-Down.
    Das nachfolgende Burn-Down-Charts zeigt 5 Sprints in denen jeweils genau 20 Story Points je Sprint an Arbeit geleistet wurden. Also wurden exakt insgesamt 100 Story Points auf der Ideallinie abgearbeitet. Liegt die Velocity unterhalb der Ideallinie, muss in nachfolgenden Sprints mit erhöhter Velocity der negative Trend ausgeglichen werden, um das angestrebte Endziel nicht zu gefährden.
    Stacks Image 1560843
  • Ereignisse (=Aktivitäten)
    Open or Close
    Statt von Meetings spricht man in Scrum von Ereignissen oder Aktivitäten. Diese haben feste Zeitfenster (Timeboxing).
    Sprint
    Ein Sprint ist ein Arbeitsabschnitt in dem ein Produktinkrement erstellt wird.
    Die Produktneu- und Weiterentwicklung verläuft in stets gleich langen Iterationen/Zyklen von max. 4 Wochen.
    Sprints sollten immer die gleiche Länge haben.
    Ein Sprint ist zu Ende, wenn die Zeit um ist.
    Sprints folgen unmittelbar aufeinander.
    Muss ein Sprint durch den PO abgebrochen werden, wird der aktuelle Sprint mit einer Sprint Retrospective beendet.

    Explorationssprint
    Bei innovativen und komplexen Scrum Projekten können vor den eigentlichen Sprints n-Explorationssprints vorgeschaltet werden, um das notwendige relevante Wissen zu erwerben (Prototyp). Es werden keine auslieferbaren Inkremente erstellt. Explorationssprints sollten jeweils nicht länger als eine Woche dauern.

    Releasesprint
    Release-Sprints schaffen aus Kundensicht keinen Mehrwert. Dennoch können sie erforderlich sein, wenn beispielsweise eine kundenspezifische Konfiguration zum Einsatz kommen muss.
    Sprint Planning (Teil 1 und 2)
    Dauer: Max. 2 Stunden je Sprintwoche, also maximal 8 Stunden für einen 4-wöchigen Sprint.
    Teil 1
    Der PO stellt eine Vorauswahl der priorisierten und umzusetzenden Anforderungen vor.
    Das Produkt Backlog sollte im Product Backlog Refinement vorbereitet worden sein (für den nächsten Sprint).
    Das Team identifiziert die notwendigen Aufgaben, legt den Aufwand und die umzusetzenden Anforderungen fest.
    PO und Team einigen sich über die Definition of Done.
    Der SM moderiert die Sitzung.
    Teil 2
    Hier erstellt das Team ein realistisches Sprint Backlog auf Basis von Teil 1 und die Aufgaben zu deren Umsetzung.

    Daily Scrum
    Im Daily Scrum wird die Auswahl der Aktivitäten koordiniert.
    Im Daily Scrum werden keine Probleme gelöst - es erfolgt lediglich ein Informationsaustausch. Die Beantwortung von Fragen sollte im Anschluss an diese Aktivität erfolgen.
    Scrum Master nimmt teil, notiert sich genannte Impediments und greift moderierend(!) ein, wenn nötig.
    Product Owner nimmt nach Möglichkeit auch teil, um auf dem neuesten Stand zu bleiben und bei Bedarf Fragen zu beantworten
    Jedes Teammitglied zu Beginn eines jeden Arbeitstages berichtet über die gestern erledigte Arbeit, die heute geplante Arbeit und identifiziert Verbesserungsnotwendigkeiten.
    Es ist wichtig, daß die Team Mitglieder einander berichten und nicht ihren evtl. anwesenden Vorgesetzten oder dem ScrumMaster oder dem Product Owner.
    Dauer: Max. 15 min.

    Sprint Review
    Am Ende des Sprints und vor der Retrospektive.
    Präsentation des erstellten Produktinkrements und Einholung von Feedback insb. von den Stakeholdern.
    Das Team präsentiert seine Ergebnisse.
    Der PO entscheidet über die zu entwickelten Funktionalitäten.
    Dauer: Max. 1 Stunde je Sprintwoche.
    Teilnehmer: PO, SM, Team und optionale Stakeholder.

    Sprint Retrospektive
    Findet unmittelbar im Anschluss an das Sprint Review statt, also am Ende des Sprints.
    Besprechung im gesamten Scrum-Team über das Vorgehen, die Arbeitsmethoden und die Zusammenarbeit. Vereinbarung von Optimierungen.
    Dauer: Ca. 45 min je Woche, also bei einem 4-wöchigen Sprint 3 Stunden.
    Teilnehmer: PO, SM, Team und grundsätzlich KEINE Stakeholder.

    Product Backlog Refinement (= Backlog Grooming, auch Estimation Meeting)
    Ist ein fortlaufender Prozess, der nicht mehr als 10 % der Entwicklungsteam-Kapazität in Anspruch nehmen sollte.
    PO, Team und ausgewählte Stakeholder nehmen daran teil, um die Einträge zu bearbeiten, zu schätzen und Releases zu planen.
  • Artefakte
    Open or Close
    Scrum kennt 3 Artefakte.
    Product Backlog
    Pflegt der PO.
    Liste aller priorisierten Anforderungen und Arbeitsergebnisse, die für das künftige Produkt benötigt werden.
    Das Product Backlog wächst iterativ-inkrementell. Es liegt zu Beginn grobgranular vor und wird im Laufe der Sprints immer weiter detailliert und verfeinert.
    Scrum kennt kein Change-Request-Verfahren.
    Das Product Backlog enthält auch die Akzeptanzkriterien und den Aufwand der einzelnen Anforderungen.
    Das Product Backlog sollte zu Beginn des Projekts genügend Anforderungen für die ersten 2-3 Sprints enthalten.
    Das Product Backlog ist nach Risiken zu priorisieren. Die Priorisierung führt der PO mit dem Team durch.
    Da Use Cases komplexer als User Stories sind, sollten möglichst User Stories im Product Backlog Anwendung finden.

    Sprint Backlog
    Ausgewählte Product-Backlog Einträge für den aktuellen Sprint und der vom Scrum-Team prognostizierte Lieferumfang für das nächste Produktinkrement.
    Die Aktivitäten sind in Personenstunden geschätzt.
    Ein Sprint Backlog wird in der Sprint Planungssitzung zu Beginn des jeweiligen Sprint erstellt.

    Product Increment
    Entspricht der Summe aller Product-Backlog Einträge die während des aktuellen und der vorangegangenen Sprints fertiggestellt wurden.

  • Scrum für große Projekte

    Open or Close
    Große Projekte in Scrum sind solche, die mehr als aus einem Team bestehen. Jedes Team hat i.d.R. seinen eigenen Product Owner (PO) und Scrum Master (SM).

    Wir unterscheiden verteilte und große Scrumprojekte.
    Bei     verteilten Scrumprojekten können die Teams auf verschiedene Gebäude, Standorte, Zeitzonen aufgeteilt sein und ggf. verschiedenen Organisationen angehören.
    Bei verteilten/großen Projekten steigt der Kommunikations- und Integrationsbedarf.
    Da jedes Team einen PO hat, macht es Sinn, aus dem PO-Team einen     Chief Product Owner festzulegen und ggf. weitere Stakeholder/Spezialisten hinzuzuziehen.
    Der Chief Product Owner sollte bei mehr als 5 POs kein eigenes Team mehr betreuen.
    Die Teams können ggf. in Komponenten- und Featureteams unterschieden werden.
    In einem Komponententeam entspricht die Struktur der Softwarearchitektur.
    Featureteams sind nach Anforderungen organisiert.
    Grundsätzlich ist zu beachten, möglichst nur mit einem Produkt Backlog zu arbeiten.

    I.R. der     Multiteamplanung sollte ein Releaseplan erstellt werden, der für alle Teams gilt. Meist sind synchrone Sprints die Regel, jedoch können auch asynchrone Sprints vorkommen.

    Scrum of Scrums
    Darunter versteht man nichts anderes als ein Daily Scrum, das projektweit durchgeführt wird. Jedes Team entsendet einen Vertreter, der an dem Meeting teilnimmt.

    Meta Scrum
    Ein Meta Scrum entspricht der Scrum of Scrums und wird projektübergreifend ausgeführt.

    Frameworks für größere Projekte
    Dazu zählen beispielsweise LeSS (Less Scale Scrum), Scrum@Scale, Enterprise Scrum, Nexus, DAD (Disciplined Agile Delivery) und
    SAFe.
    SAFe bietet eine Starthilfe für traditionelle Unternehmen in die agile Welt. SAFe kennt folgende drei Ebenen.
    • Teamebene: Hier greift man gern auf Scrum oder Kanban zurück, um in Feature-Teams weitgehend selbstständig Funktionen fertigzustellen.
    • Programmebene: Mehrere Teams bilden einen Agile Release Train, der längere Zyklen als die Sprints repräsentiert.
    • Portfolioebene: Analyse und Priorisierung von Vorhaben und Delegation an die Produktentwicklung (Wertstrom).

  • Exkurs: Testen in Scrum

    Open or Close
    Nicht jeder im Team muss alles können. Vielmehr muss das Team als Ganzes alle Fähigkeiten mitbringen, die zur Produktentwicklung und Qualitätssicherung benötigt werden. Tester, Testmanager, Qualitätssicherer haben in agilen Projekten durchaus ihre Berechtigung (Built-In-Quality).

    Dokumentation
    Grundsätzlich soll nur noch das dokumentiert werden, was einen Wert/Nutzen für den Stakeholder hat.
    Gibt es regulatorische Anforderungen, so sind alle Dokumentationen, die für ein Audit erforderlich sind, in den Definition of Done (DoD) zu berücksichtigen.
    Ein Test-Management-System ist für die Dokumentation und Nachvollziehbarkeit der Tests unverzichtbar.
    Der Aufwand für die Dokumention ist bei der Planung zu berücksichtigen. Es dürfen keine technischen Schulden anwachsen.

    Rollen: Tester, Testmanager
    Tatsächlich kennt Scrum neben dem PO und dem SM nur Entwickler. Das Team als Ganzes soll jedoch alle Fähigkeiten mitbringen, die zur Produkt-Entwicklung und Qualitätssicherung notwendig sind. Folglich sind Testexperten, resp. QM , eine unverzichtbare Species für ein funktionierendes Team.

    Retrospektive
    Die Retrospektive ist eine hervorragende Möglichkeit zur kontinuierlichen Prozessverbesserung. Allerdings längst nicht so schwergewichtig wie die Reifegradmodelle SPICE oder CMMI.

    Teststrategie
    Nach ISTQB ist die Teststrategie Bestandteil des Testkonzeptes. Der alte Standard IEEE 829 Test Documentation wurde abgelöst durch ISO/IEC/IEEE 29119 (siehe http://softwaretestingstandard.org).
    Auch agile Teams benötigen eine Teststrategie. Sie könnte beispielsweise in     Definition of Test (DoT) festgehalten werden.

    Testbare Anforderungen
    In den User Stories müssen testbare Anforderungen, z.B. in Form von Akzeptanzkriterien, dokumentiert sein. Testbarkeit ist ein Qualitätsmerkmal und sollte beispielsweise mit dem Anforderungsautor (PO oder BA) sichergestellt werden.
    Anforderungen sollten risikobasiert sein, um den realistischen Testaufwand als Aufwandschätzung in den Planungsprozess einzubringen.

    Teamübergreifendes Testen
    Scrum of Testers (SoT)     ist eine sinnvolle Organisation zum übergreifenden Austausch von testrelevanten Themen.

    Definition of Done (DoD)
    Das Team sollte die notwendigen Testarten, die zu erreichende Testabdeckung und die Testendekriterien hier festhalten.

    Testprozess



    Unit-Tests


    Dynamisches testen von einzelnen Softwarebausteinen (Klassen, Objekte)
    • Testen der Methoden einer Klasse
    • Testen der Objektzustände

    Test First ("Erst Testen, dann Programmieren")
    Schreiben von Tests und automatisieren, so dass sie solange fehlschlagen bis der Code erfolgreich fertiggestellt wurde.

    Statische Codeanalyse
    Die Coverage-Messing erfolgt regelmäßig mit geeigneten Werkzeugen, um mindestens die Abdeckung der Methoden je Klasse und die Anweisungsabdeckung innerhalb der Methoden darstellen zu können.

    Integrationstests


    Sie haben das Ziel Fehlerzustände in den Schnittstellen der beteiligten Bausteine aufzudecken.

    Systemtests


    Im Systemtest werden Testfälle in einer Umgebung ausgeführt, die der späteren Einsatzumgebung sehr nahe kommen. Die Testfälle müssen das System aus Nutzerperspektive testen können. Systemtestfälle werden grundsätzlich aus den Akzeptanzkriterien der User Stories abgeleitet.

    Exploratives Testen/Sitzungsbasiertes Testen
    Sitzungsbasiertes Testen ist eine Variante des explorativen Testens, nur auf formalerer Basis. Es werden Tests protokolliert, die die Reproduzierbarkeit ermöglichen.

    Akzeptanztests
    Akzeptanztests sind Abnahmetests.
Scrum bietet viele Vorteile in der Softwareerstellung. Wir prüfen Ihr Vorhaben auf Eignung für die Umsetzung in Scrum und führen Scrum ein.
Wir unterstützen Sie bei kleinen und großen Scrum-Vorhaben und sorgen auch für eine Anpassung der klassischen Organisation an eine agile Organisation.
U
© 2023 Holger Mayer Consulting HMC2 Kontaktieren Sie mich