inoxio erklärt agiles testing

Preview:

DESCRIPTION

How we understand agile testing

Citation preview

inoxio Quality Services GmbH

seit 2007

Sitz in Erfurt

3 Geschäftsführer, Tester, Entwickler

Projekte in ganz Deutschland

Telekom, Post, Otto, ...

Agile Testing

Mini-Wasserfall

4 PO schreibt Story

4 Entwickler implementieren Software

4 QA testet ob Software der Story entspricht

ODER ...

Behavior

Driven

Development

QA ist Teil des Enwicklungsteams

Agiles Team mit 4-6 Devs, QA, PO

Story Life Cycle - Discovery

4 PO schreibt Story

4 Estimation erzeugt Verständnis im Team

Story Life Cycle - Test Design

4 QA + PO schreiben erstes Example (HappyPath)

4 QA schreibt mehr Examples

4 vollständige Acceptance Tests

4 PO kann Acceptance Tests überprüfen/ändern

Story Life Cycle - Planning

4 BDD ist Kommunikationswerkzeug!

4 im Planning werden die Examples benutzt um Anforderungen zu veranschaulichen

4 Probleme und EdgeCases können erkannt werden

Story Life Cycle - Implementation

4 Acceptance Tests werden zu erst automatisiert

4 BDD + TDD Cycles

4 alle Tests grün -> Story DONE!

Test AutomationWhole Team!

Pairing: Devs & QA

Automated Acceptance Tests

4 Ausführbare Acceptance Tests

4 Regression Suite

4 Menschenlesbare Acceptance Tests

4 immer aktuelle Feature Documentation

4 PO kann Anforderungen anpassen

Cucumber for the Resque!

Cucumber: FeaturesFeature: Instant Printing of Orders

As a *Barkeeper* I want to get an instant printout when a *Waiter* receives an *Order* so that I can prepare the ordered beverages faster

Scenario: Orders from Mobile-Waiter-Device are transfered to POS

GIVEN a system with a Mobile-Waiter-Device M and a POS-Device P AND a Printer is connected to the POS-Device P WHEN the Waiter uses M to log in a Order for Table 2: | Bier, groß | 1 | | Wasser, klein | 2 | THEN P should receive the Order within 1 second AND the Printer is printing a printout with these facts: | Table: 2 | | ---------------- | | Bier, groß: 1 | | Wasser, klein: 2 |

Cucumber: Features II

4 menschenlesbare Specs

4 Step-Definitions erkennen Schritte und machen diese ausführbar

Cucumber: Step DefinitionsWhen(/^the Waiter uses (\w+) to log in a Order for Table (\d+):$/) do |device_id, table_no, order| # drive actual device or simulator # ...end

Then(/^the Printer is printing a printout with these facts:$/) do |data_table| @mocked_printer.should_receive(:print_recipe).with(...).once()end

Cucumber: Step Definitions II

4 sind wiederverwendbar

4 gibt es nicht geschenkt

4 QA und Devs müssen im Pair arbeiten

4 Black-, Gray- & White-Box

Driving Applications

4 Webpages: Webdriver / Selenium

4 iOS/Android: Calabash:

4 mit Simulator

4 mit echtem Device

Challenges

4 verschiedene Technologien

4 Rails + iOS

4 Integration-Tests mit verteilten Devices

4 Handheld + POS + Backoffice

Test Pyramide für verteilte Systeme4 solide Unit-Tests als Grundlage

4 wasserdichte automatisierte Interface-Tests

4 automatisierte Acceptance Tests (System-Level)

4 manuelle voll integrierte Smoke-Tests vor jedem Release

Ein Schritt nach dem Anderen

4 QA im Team

4 Acceptance Tests pro Story (manuell?)

4 Automated Acceptance Tests

Testing friendly Environment

4 Test Driven Development

4 Continious Integration

4 One-Click Deployments auf Test-Umgebung

4 Continious Delivery