Tester werden wie Entwickler behandelt

• Individuen und Interaktionen > Prozesse und Werkzeuge

• Funktionierende Software > Dokumentation

• Zusammenarbeit mit Kunden > Vertragsverhandlungen

• Reagieren auf Veränderungen > Befolgen von Plänen

• Ausführliches Manifesto

  • Höchste Priorität: Kunden früh und kontinuierlich gute Software ausliefern und zufriedenzustellen.

  • Anforderungsänderungen auch in später Entwicklung in Ordnung.

    Veränderungen = Wettbewerbsvorteil des Kunden.

  • Funktionierende Software regelmäßig innerhalb wenigen Wochen / Monate liefern.

  • Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

  • Entwicklern wird benötigte Unterstützung und Umfeld gegeben und darauf vertraut, dass sie die Aufgabe erledigen.

    Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

  • Informationen an und innerhalb eines Entwicklungsteams von Angesicht zu Angesicht.

  • Funktionierende Software ist das wichtigste Fortschrittsmaß.

  • Nachhaltige Entwicklung fördern - gleichmäßiges Tempo dauerhaft halten können.

  • Technische Exzellenz und gutes Design fördert Agilität.

  • Einfachheit: Menge nicht getaner Arbeit nicht maximieren.

  • In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Verantwortlich für Umsetzung und Verfolgung, Auflösung von Fragen, Hindernissen (Impediments)

Keine Teamleitung sondern Coach

Person verantwortlich für Backlog, Vertritt Kunden für Team

verantwortlich für Produkteigenschaften

Entwicklung und Testen des Produkts

Selbstorganisiert: Keine Teamleitung, Entscheidungen gemeinsam getroffen, funktionsübergreifende Zusammenarbeit

• Task Boards aufstellen, Product Backlogs vervollständigen → Projektumfangs einschätzen

• Initiale Systemarchitektur, erste Prototypen, notwendige Werkzeuge (für Testmanagement, Fehlermanagement, Testautomatisierung, continuous Integration)

• Initiale Teststrategie für alle Teststufen.

  Bestimmung von: Testumfang, technische Risiken, Testarten und überdeckungsziele

• Initiale Qualitätsrisikoanalyse

• Definition von Metriken für: Testfortschritt, Produktqualität

• Definition of Done

• Definition des Zeitpunktes andem nicht mehr getestet werden soll, bevor System an Kunden geliefert wird

Aufwand = Komplexität, Schwierigkeitsgrad (inkl Testen, da Whole-team approach)

In Story-Points (1, 2, 3, 5, 7, 13, ...) oder T-Shirt größen (S, M, L, XL)

Planning Poker

Meeting mit kompletten Team (auch Tester)

Priorisierung von offenen US im Product Backlog

Aufwandsabschätzung (falls nicht bereits erfolgt)

Diskussion vom Scope des Sprints und Team-Commitment

Formale Abhname der US: Demo gegenüber von Stakeholder und Owner

Unvollständige US landen in den nächsten Sprint

Team-Sitzung am Ende jeder Iteration: Was erfolgreich war, was verbessert werden könnte - Prozess, Beteiligte und deren Organisation und Beziehungen, Werkzeuge

Anforderungen aus der Sicht eines Fachbereichsvertreter (Funktionale und Nicht-Funktionale Eigenschaften) und Abnahmekriterien

Befinden sich im Product-Backlog

Spezifikation

Konstrukt: As a [user role] , I want to [goal] , so that I can [reason] .

1. Card

   Das physische Medium, dass die Userstory beschreibt.

   genaue Anforderung, Drinklichkeit, erwartete Test und Entwicklungsdauer, Abnahmekriterien

2. Conversation

   Diskussion die erklärt wie Software genutzt werden soll

3. Confirmation

   Abnahmekriterien die in Diskussion festgelegt werden Bestätigung des Abschlusses der Userstory.

• Beispiel

  

  Confirmation

  1. Success-valid user logged in and referred to home page. a. “Remember me” ticked - store cookie/ automatic login next timne. b. “Remember me” not ticked -force login next time.

  2. Failure- display message: a) "Email address in wrong format" b) "Unrecognised user name, please try again" c) Incorrect password, please try again" d) "Service unavailable, please try again" e) Account has expired- refer to account renewal sales page.

basierend auf Definition of Done

– Vollständigkeit – Konsistenz – Unmissverständlichkeit – Realisierbarkeit – Testbarkeit – Tracability – Spezifisch – Messbar – Durchführbarkeit innerhalb eines Sprints – Unabhängigkeit

Testen ist Teil der Entwicklung (Unit Tests, TDD)

Akzetanztests durch Owner, Kunde nach jedem Sprint

Fokus auf Kundensicht statt technische implementierung

Fokus auf Fehler anstatt von Verfikation der Vollständigkeit

– Statisches Testen (Anforderungen, Dokumentation) – Dynamisches Testen (Ausführung von Akzeptanztests) – Erstellung von Akzeptanztests – Verwaltung von Testfällen im Source Code Manager SCM – Unterstützung bei Unit Tests und TTD – Test Ansatz, Planung – Regressionstests (manuell & automatisiert) – Risikoanalyse, Risikoabschätzung – Schätzung, Tracability von Tests der User Stories – Demonstration während des Sprint Reviews – Erstellung und Wartung von automatisierten Tests – Unterstützung bei Akzeptanztests

Entweder außerhalb des Teams und nur bei kritischen Punkten aufgerufen oder in Team vollzeit Integriert:

– Security – Performance und Stresstests – Usability – Portability – Wartbarkeit

– Mentoring – Personalmanagement – Aufteilung der Testressourcen über Teams – Wissenstransfer – Training und Entwicklungsplanung – Test Strategie / Ansatz – Test Planung – Identifikation, Analyse und Verhinderung von Risiken – Bindeglied zwischen Business und Stakeholdern – ...

– repetitive manuelle Tätigkeiten reduzieren – Die Effizienz des Testens zu steigern: Hohe Anzahl an Tests in angemessener Zeit ausführen – Tests durchführen, die man nicht manuell durchführen kann (z.B. Last-Tests) – Automatisch Reports der Testergebnisse generieren

Nach jeder Iteration muss funktionierende Software vorliegen.

Kontinuierlich (min 1x am Tag oder bei Änderungen) automatisiert in CI-Pipeline durchgeführt:

Komponenten miteinander zusammenführen (Integration)

Aktivitäten:

Workflows / Pipeline in Versionierungssystemen (SCM): Verwendung von Branching-Modelle für verpflichtende Code Reviews

Änderungen von stabiler Codelinie ist ohne Review / QA Überprüfung (oder CI) nicht möglich

Siehe: https://help.github.com/articles/about-pull-request-reviews/

Auslieferung / Deployment / Release erfolgt automatisiert nach Qualitätsüberprüfung

• Continuous Delivery: Automatisches deployment von Artefakten

• Continuous Deployment: Automatische Installation in Produktion

  zB: Continuous Deployment der Netflix API

  Siehe: https://medium.com/netflix-techblog/preparing-the-netflix-api-for-deployment-786d8f58090d

eher Unit-Tests, automatisiert in CI

1. Think

   – Auswahl der Anforderungen die implementiert werden sollen – Testfall-Spezifikation

2. Red

   Implementierung und Ausführung der Testfälle

   – Alle Tests müssen fehlschlagen

3. Green

   Implementierung der Komponenten und Klassen und Ausführung der Testfälle

   – erfolgreich → weiter bei Schritt 4, Refactor – schlägt fehlt → weiter bei Schritt 3, Green

4. Refactor

   Optimierung der Implementierung ohne Änderung der Funktionalität, Ausführung der Testfälle.

   – Testfälle dürfen nicht fehlschlagen. – Auswahl der nächsten Anforderung (weiter zu Schritt 1)

US enthält Abnahmekriterien, Test

Wiederverwendbare Tests für Regressionserstellung.

Entwickler testet erwartetes Verhalten

In manchen Frameworks Gherkin-Format (deklarativ) → automatische Testerstellung:

In agilen Projekten Tests gleichzeitig mit Komponenten entwickelt (nach US, Abnahmekriterien)

Blackbox Testentwurfsverfahren: Äquivalenzklassenbildung, Grenzwertanalyse (um Testwerte auszuwählen), Entscheidungstabellen, zustandsbasierte Tests.

Wichtig wegen begrenzter Zeit für Testanalyse und Detailgenauigkeit der US.

zusätzlich zu anderen Testentwurfsverfahren

basiert auf Intuition, Erfahrung des Testers

muss dokumentiert werden

Vorgehen:

Testsitzungen beinhalten:

2 Teammitglieder (beliebig: Entwickler, Tester, Owner) setzten sich zusammen um Test oder andere Sprintaufgabe zu bearbeiten.

Testfälle, Chartas aus US aufgebaut.

zum Finden und Beschreiben von Teststrategien.

Kriterien anhand denen entschieden wird, ob Inkrement abgeschlossen

Abnahmekriterien mit Abnahmetests getestet:

Userstories

Iteration

• Beispiel: Registrieren Funktion

  1. Conditions of Satisfaction

     Welche Bedingungen, Anforderungen gibt es? “Passwörter dürfen nicht knackbar sein”

  2. Acceptance Criteria

     Wann gilt ein Passwort als “nicht knackbar”?

     – Mind. 8 Zeichen, aber nicht mehr als 12 – Darf nur alphanumerische Zeichen beinhalten – Muss mind. eine Zahl beinhalten – Muss mind. einen Buchstaben beinhalten

  3. Examples

     Erstellung von Testdaten: “abc123”, “abcdefghi”, “1aaaaaaaaa”, “ajx972dab”

  4. Executable Examples

     Durch BDD:

     Given the "Unregistered User" user has navigated to the "register" pageWhen entering "newuser" in the "Username" field
     And entering "abc123" in the "Password" field
     And entering "abc1 23" in the "Confirm Password" field
     And pressing the "Register" buttonThen the text "Thank you for Registering" should appear on page
     And the URL should end with "use/accountPage"

Organisation vom Team

Kommunikation

Build und Distribution

Konfigurationsmanagement und Version Control System VCS

Testentwurf, Implementierung und Durchführung