Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Baustein- vs. Funktionsorientierte Organisation

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Baustein- vs. Funktionsorientierte Organisation

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Baustein- vs. Funktionsorientierte Organisation

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

Features / User Stories m Baustein übergreifende Funktionalität m realisiert (Teil-) Anforderung m Use Case + GUI Entwurf + textuelle Szenarien + Objektdiagramme (Story Boards) m automatischer JUnit Test m Implementierung

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Scrum

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Scrum m Product Backlog: priorisierte Features / User Stories m Release Backlog: Unterteilung des ProductBacklog m Sprint Backlog: Features des Sprints mit l Status l geschätzter Aufwand l Bearbeiter l Restaufwand l Kunagi Example

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Scrum Roles: m Product Owner: l lebende Anforderungsdoku l Onsite Customer l Priorisierung der Features l Reviews der Entwürfe l Abnahme der Implementierung l Alpha Tester

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Scrum Roles: m Scrum Master: l Project Manager l Scrum Meetings l Burndown Charts l provide Tools, Computers, Room, Coffee, … l manage Risks l manage Failures l Parties l … m The Team:

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Scrum Roles: m The Team: l do the work l story boards / user stories l tests l implementation l bug tracking l bug killing l reviews l testing l debugging l documentation

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Was Scrum verschweigt: m Story Boards müssen harmonisiert werden m Klassendiagramme / Architektur m Metaphern / gemeinsame Vision m Bug Sqash Weeks m Libraries / Frameworks

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Kunagi

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

Features / User Stories m Baustein übergreifende Funktionalität m realisiert (Teil-) Anforderung m User Story + GUI Entwurf + textuelle Szenarien (+ Objektdiagramme (Story Boards) ) m automatische JUnit Test m Implementierung

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Testen m (Whitebox) Glassbox-Test l anhand der Implementierung l Normal- und Grenzfälle aus Bedingungen l Überdeckungskriterien m Blackbox-Test l mit Hilfe der Spezifikation (ohne die Implementierung zu kennen) l Normalfälle aus der Spezifikation l Sonderfälle der Spezifikation l Unzulässige Eingaben der Spezifikation

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University White-Box-Testing m C0-Überdeckung (Anweisungs- und Bedingungsüberdeckung) l Beim Test muss jedes Statement und jeder Ausdruck mindestens einmal ausgewertet werden l Code Coverage Tools können das automatisch messen (Ergebnis gehört ins Testprotokoll) (Für Java z.B. EMMA) l manchmal schwer zu erfüllen z.B. try {... } catch (HeapOverflow e) { xxx () } l findet nicht alles: m (x, y) { int z = 0; if (x > 0) { z = 1; } y = x / z; // <== ERROR: Division by zero... l Der Aufruf m(1,0) erreicht C0-Überdeckung aber keine Fehlerfreiheit

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University White-Box-Testing m C1-Überdeckung: Zweigüberdeckung l auch leere if-then-else-Zweige müssen durchlaufen werden l (while) Schleifen müssen sowohl durchlaufen als auch übersprungen werden l findet aber immer noch nicht alles: m (x, y) { int z = 0; if (x > 0) { z = 1; } else { z = -1;} if (y > 0) { z ++; } else { z --; } y = x / z; // <== ERROR: Division by zero on x = 1 and y = -1

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University White-Box-Testing m C2-Überdeckung (Pfadüberdeckung) l Testfälle sollen alle möglichen Durchläufe durch eine Methode testen l Schleifen null und ein mal durchlaufen l Problem exponentieller Aufwand: m (x, y) { int z = 0; if (x > 0) { z = 1; } else { z = -1;} if (y > 0) { z ++; } else { z --; } if (...) {... } else {...} y = x / y; // <== ERROR: Division by zero on y = 0 l Bei jedem if-Statement 2 Fortsetzungsmöglichkeiten l bei n if Statements 2 hoch n Pfade (20 ifs 1 Millonen Testfälle) l in der Praxis nicht vertretbarer Zeitaufwand l findet immer noch nicht alle Fehler Bemerkung: sowas findet man gut mit Reviews

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University White-Box-Testing m Coverage Tools l cobertura ( l EMMA ( l EclEmma ( l Coverlipse ( l jCoverage ( l OptimzeIt ( l Clover (

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

Black-Box-Testing m Funktionsorientierter Test l jede Funktion / Feature / Variable einzeln m Äquivalenzklassenbildung l Definitionsbereich der Variablen betrachten l Partitionierung, zwei Tests pro Partition l Randwerte m Regressionstests l Wiederhole Tests bei Programmänderungen l vgl. XP m Szenario-basierte Tests l vgl. FUP

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Random Testing

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University JUnit Tests – Test First Principle m im eXtreme Programming / agilen Methoden: JUnit Tests l Für jede Funktionalität (jedes Oval im Use-Case Diagramm) wird als erstes eine automatische Testroutine geschrieben l Testroutine ist einzeln aufrufbar und wird in Gesamttest eingehängt l Testroutine kommt in die gleichen Klassen, wie die Implementierung l Testroutinen verbleiben im Code und gehören zum Endprodukt l Aufgaben der Testroutine: l verschiedene Ausgangssituationen herstellen l Funktionalität aufrufen l Messpunkte im Code abfragen (Testanweisungen fügen Meldungen an Testreport an) l Testprotokoll ausgeben (Testreport mit erwartetem Output vergleichen) l expliziter Unit-Test kann entfallen m im Unified Process l Tester != Programmierer Defect-Removal-Rate ~ 1 per day

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Test Summary: m ein Fehler pro Tag m Test First m Funktionstests (anstatt Bausteintests) m Ein Assert pro (typischer) Fehler(quelle) m Coverage m vollautomatisch m unglaublich wertvoll bei Änderungen / iterativem Vorgehen

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Reviews m Entwickler selbst plus Co-Entwickler oder externer Reviewer m Check-Liste mit typischen Fehlern m Code ist schon Unit getestet => suche nur nach typischen Fehlerquellen: l Division durch 0 l null-Pointer Dereferenzierung l Speicher-Lecks l Array-Grenzen bei for-Schleifen l deckt kompliziertes if alle Fälle richtig ab l Terminiert die Schleife / Rekursion sicher l Dead-Lock-Gefahren l Racing Conditions l... + Defect-Removal-Rate ~ 1 per hour + Reviewer lernt viele Kniffe + Viele Leute kennen viele Teile des Gesamtprogramms m bei XP pair-programming

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University