Behaviour Driven Testing Schließen der Lücke zwischen Fachtester und Testautomatisierer

Transkript

1 Behaviour Driven Testing Schließen der Lücke zwischen Fachtester und Testautomatisierer Johannes Bergsmann Berater, Trainer, Eigentümer Software Quality Lab Über Software Quality Lab LEISTUNGSPORTFOLIO CONSULTING Management Consulting Prozesse und Vorgehensmodelle Teststrategie und -konzeption Requirements und Ausschreibungen Architektur und Modellierung Code Analyse und Metriken OPERATIONAL SERVICES & TESTCENTER TestCenter Requirements Engineering Testmanagement und -spezifikation Softwareverifikation und -validierung Testautomatisierung und -reporting Reviews und Code Analyse ACADEMY Requirements und Usability Architektur und Modellierung Testen und Automatisieren Agile Softwareentwicklung Projektabwicklung und Vorgehensmodelle Lehrgänge und Zertifizierungen TOOL EXPERTISE Tool Evaluation Center Tool-Einführung und Pilotprojekte Tool-Schnittstellen und Einbindung Managed Services und Lizenzen Softwareprozessautomatisierung Test Automation Frameworks Tool-Studien und Tool-Expertisen Software Quality Lab Software Quality Lab Seite 1

2 Über Software Quality Lab Auszug aus der Kundenliste Energie & Versorgung Elektronik & Automation Industrie & Engineering Dienstleistungen & Handel Medizin & Pharma Software & IT Finanz & Versicherung Mobilität & Kommunikation Österreiches Rotes Kreuz Software Quality Lab Präsentationsvorlage Inhalt Motivation TDD Test Driven Development BDD Behaviour Driven Development Beispielumsetzung in Polarion Software Quality Lab Software Quality Lab Seite 2

3 I don't care how good you think your design is. Test as an early indicator of specification & design If I can't walk in and write a test for an arbitrary method of yours in five minutes it's not as good as you think it is, and whether you know it or not, you're paying a price for it. Michael Feathers Software Quality Lab Test Driven Development (TDD) Software Quality Lab Software Quality Lab Seite 3

4 VOR Programmierung Tests erstellt TDD Eigenschaften Zu erstellende Software wird durch Testfälle beschrieben (= detaillierte Requirements) Ziele von Anfang an testbaren und wartbaren Code erstellen Testabdeckung erhöhen Auf mehreren Ebenen einsetzbar Testen im Kleinen (Unit Tests ) und Testen im Großen (Systemtests, Akzeptanztests) Software Quality Lab Testgetriebene Softwareentwicklung 1 Unit-Test schreiben 2 Funktionsblock programmieren 3 Programm verbessern Software Quality Lab Software Quality Lab Seite 4

5 TDD Bewertung Vorteile Qualität der Entwicklung wird verbessert Testabdeckung wird erhöht Besser Basis für Sprint- Abnahme (Test = REQ) Effizienz im Sprint wird erhöht lebende Testspezifikation Herausforderungen TDD alleine macht noch keine guten REQs und Code Manches kann nicht vorab als Test automatisiert werden (Usablity, Systemkontext, Prozessmodellierung, Architektur, etc.) Sehr hohe Disziplin erforderlich Software Quality Lab Behavior Driven Development (BDD) (eine Variante von TDD) Software Quality Lab Software Quality Lab Seite 5

6 Als <Benutzerrolle/Systemrolle> will ich <Aufgabe/ Story> [, so dass <Grund für das Ziel / Nutzen>] User-Stories Funktionale Spezifikation Einfach lesbar Einfach verwaltbar aber: Es fehlt das Verhalten! Software Quality Lab Behaviour Driven Development (BDD) 2003 von Dan North als Antwort auf Test-Driven Development (Unit-Tests sind für Fachbereich schlecht lesbar) erstellt User-Stories und erfasst dazu auch das Verhalten (Behaviour) mit Vor-&Nachbedingungen Beschreibung erfolgt in natürlicher Sprache (Gherkin): User-Story Szenario / Verhalten Vorbedingung Nicht-Programmierer schreiben Code vor der eigentlichen Entwicklung Step Aktion Nachbedingung / Ergebnis Software Quality Lab Software Quality Lab Seite 6

7 Behaviour Driven Development (BDD) Beispiel Cucumber (Tool für BDD) 1: Describe behaviour in plain text (GHERKIN) 2: Write a step definition in Ruby 3: Run and watch it fail (Class Calculator missing) Steps können parametriert werden 4. Write code to make the step pass 5. Run again and see the step pass 6. Repeat 2-5 until green like a cuke 7. Repeat 1-6 until the money runs out ;-) Quelle: Software Quality Lab Behaviour Driven Development (BDD) Automatisierte Regressionstests geben schnelles Feedback lebende Spezifikation und Dokumentation BDD: interessanter Ansatz, der versucht eine bessere Kopplung zwischen den Beteiligten (Fachexperten und Entwickler) zu erreichen. Probleme: Fachtester arbeiten typischerweise mit anderen Tools (Testmanagement-Tools) Keine systemunterstützte direkte Kopplung zwischen Testspezifikation und Automatisierungscode Textbasierte Code-Aufrufe (Steps) jeder Tippfehler (egal ob beim Tester oder beim Automatisierer) bricht den Zusammenhang und damit die Automatisierung Keine automatische Rückkopplung eignet sich ohne Ergänzung primär für entwicklungsnahe Tests (Unit-/Komponenten-Ebene) Software Quality Lab Software Quality Lab Seite 7

8 Beispielumsetzung BDD-Plugin für Polarion Closing the Gap in BDD Software Quality Lab Neues Spezifikationselement Software Quality Lab Software Quality Lab Seite 8

9 Create a BD Test Case Software Quality Lab BD Test Case workitem design BD Test Case Software Quality Lab Software Quality Lab Seite 9

10 BD Test Case - Designer Auswahl von Given, When, Then aus vordefinierten Listen Definition neuer Steps für Given, When, Then Definiertes Szenario Parameter für das Szenario Software Quality Lab Execution of the testcases create a new test run Software Quality Lab Software Quality Lab Seite 10

11 Add the BD Test Cases to the test run Software Quality Lab Start of the test run Software Quality Lab Software Quality Lab Seite 11

12 Result of the test run Software Quality Lab Zusammenfassung TDD ist ein guter Ansatz um die Qualität in der Entwicklung zu verbessern TDD erfordert jedoch sehr hohe Disziplin! BDD ist für die Zusammenarbeit zwischen Fachtester und TA sehr vielversprechend. Tester-Sicht wird nahtlos gekoppelt mit Testautomatisierung. Effizienzsteigerung im Test, TA und SWE Software Quality Lab Software Quality Lab Seite 12

13 Fragen / Diskussion zum ersten Teil? Software Quality Lab Automatische Legacy-Code Absicherung Johannes Bergsmann Berater, Trainer, Eigentümer Software Quality Lab Software Quality Lab Seite 13

14 Inhalt Motivation UnitTest-Erstellung Grobkonzept Software Quality Lab Motivation Software Quality Lab Software Quality Lab Seite 14

15 Unit-Test-Code Erstellung (halb)manuell Entwickler Code Entwickler oder Tester Unit-Test Code tw. autom. Erstellung von Unit-Test-Frames Entwickler oder Tester Compiler, Build Überprüfung Verifizierung Lauffähige SW / Unit-Tests Software Quality Lab Legacy-Code und Unit-Test - Probleme Unit-Tests decken oft nur einen Bruchteil des Code- Verhaltens ab Entwickler sind tw. nicht motiviert oder haben zu wenig Zeit, gute Unit-Tests zu schreiben Es gibt nur einen/wenige Unit-Tests je Funktion, damit im Continuous-Integration Tool grün angezeigt wird und alle zufrieden sind Unit-Tests werden nicht gewartet und blockieren dann die Entwicklung Software Quality Lab Software Quality Lab Seite 15

16 Schwächen bestehender Frameworks Tests werden meist basierend auf Interfaces der Methoden oder zufällig generiert und nicht aufgrund der inneren Struktur es fehlen Testfälle, die Semantik wird nicht ausreichend berücksichtigt Oft Zwischencode, der nicht mit den üblichen Tools weiter verarbeitbar ist Generierte Unit-Tests oft schwer lesbar Für spezielle Anwendungen sehr teuer (z.b. Embedded-Test-Tools) Generierte Abdeckung oft unzureichend (z.b. keine Mehrfachbedingungsüberdeckung) Keine offenen Schnittstellen übliche Versionsverwaltung und CI-Tools nicht oder nur schwer verwendbar Software Quality Lab Unit-Tests Erstellung Software Quality Lab Software Quality Lab Seite 16

17 Unit Test Erstellung Welche Unit-Tests werden typischerweise erstellt? Unit-Test, der einmal links geht und Unit-Test, der einmal rechts geht 100% Code-Abdeckung ist mit 2 Tests erreicht und im CI-System ist alles grün Welche Tests sollten erstellt werden, um dies funktional voll zu testen? Jede (Einzel-)Bedingung muss für sich getestet werden (4 Normal-Testfälle) Grenzwerte (oben/unten) der beiden Bedingungen (weitere 4 Testfälle) Fehlertests außerhalb der Grenzen oben und unten sowie innerhalb der Grenzen mit Fehlerwerten (weitere 6 Testfälle) A > 10 & B < 5 T1 T2 T3 T4 A > B < mind. 14 Unit-Tests erforderlich für gute funktionale Testabdeckung! Software Quality Lab Test-Code-Generator 20-30% Entwicklungsaufwand fließt in Unit-Test Erstellung Ziel: ¾ davon einsparen und Entwicklerproduktivität erhöhen Jeder Code, der getestet und für gut befunden wurde Unit-Test Code Parser Syntax und Semantik des Codes. lesbar z.b. als XML-Datei. Entwickler (Legacy) Code Code Änderung Zwischen- Modell fertiger Unit-Test- Code sichert den Legacy-Code ab Generator Einbindung in CI-System ist möglich Software Quality Lab Software Quality Lab Seite 17

18 Software Quality Lab Code Absicherung Komponenten-Schema Code (freigegeben) (C, C++, C#, Java) Code-Parser Modell Syntaxbaum, Semantik, Ein-Ausgabe- Parameter, Schleifen/ Verzweigungen, etc. TestCode- Generator UnitTest-Code (im Format CUnit, CPPUnit / CppTest, Nunit, JUnit) Code-Verwaltung Testcode- Verwaltung (z.b. GIT, SVN, etc.) Statische Code- Analyse (z.b. Lint, Checkstyle, Findbugs, Cppcheck, Splint, etc.) CI (z.b. Jenkins, Gitlab CI, Bamboo, etc.) Entwicklungsframework, Compile / Build, Unit- Test Ausführung Dynamische Analyse Finden der Soll-Werte Quality- & Test- Reports Software Quality Lab Software Quality Lab Code Absicherung Unit-Test Generierung aus Modell Kunde / Tester Modellierer (Test-) Modell Modell- Parser Syntax und Semantik des Modells bzw. Codes. Lesbar z.b. als XML-Datei. Soll-Werte für die Tests aus dem Test-Modell Entwickler Code B Code- Parser Zwischen- Modell Generator Unit-Test Code Reine Legacy-Code Absicherung lesbarer fertiger Unit-Test-Code Entwickler oder Tester A Überprüfung Verifizierung / Validierung TDD/MBT Ansatz Compiler, Build Lauffähige SW / Unit-Tests Software Quality Lab Software Quality Lab Seite 18

19 Projektstatus und -planung Software Quality Lab Software Quality Lab Code Absicherung Vorteile Einfache automatische Absicherung von Legacy-Code Generieren von Standard-Unittest-Code Einsparung eines großen Teils der Unit- Test-Codierungs-Aufwände Offen und gute Schnittstellen für eigene Erweiterungen Einfache Integration in bestehende Unit- Test Frameworks Verwendung bestehender Code- Verwaltung und CI-Systeme ist möglich Software Quality Lab Software Quality Lab Seite 19

20 Zusammenfassung (Legacy-)Code ist meist zu wenig durch Unit-Tests abgesichert! Bestehende Tools und Ansätze noch nicht rund Innovations-Projekt zur autom. Test- Code Generierung wird mit TU Wien durchgeführt Pilotkunden / Partner sind noch willkommen Software Quality Lab Fragen / Diskussion Software Quality Lab Software Quality Lab Seite 20

21 Software Quality Lab GmbH Gewerbepark Urfahr 6 A Linz Kontakt für Interessenten Johannes Bergsmann johannes.bergsmann@ software-quality-lab.com Software Quality Lab Software Quality Lab INNOVATION MEETS QUALITY Academy Consulting Operational Services Tool Expertise Software Quality Lab Software Quality Lab Seite 21