Unterschiedliche Herangehensweisen an das Testen

Transkript

1 Unterschiedliche Herangehensweisen an das Testen GI-FG TAV 6. Treffen am 06./ in Stuttgart by Maud Schlich - IT-PROJECT-SERVICE Seite 1 von 21 s of software testing? Essentially, all models are wrong, but some are useful. George E.P. Box (Professor Emeritus of Statistics at the University of Wisconsin ) Herangehensweisen von Testern = s of software testing Ist das nützlich? by Maud Schlich - IT-PROJECT-SERVICE Seite 2 von 21

2 Denkschulen Vier Philosophenschulen der Antike: die Akademie - Platon der Peripatos - Aristoteles die Stoa - Zenon der Kepos Epikur Gleiche Grundüberzeugungen der Lehrenden und Lernenden by Maud Schlich - IT-PROJECT-SERVICE Seite 3 von 21 s of testing (B. Pettichord) Vier 1 s of testing: school school / Standard school Assurance school 2 school 1 von Brad Pettichord 2007 ergänzt um Agile school 2 von Cem Kaner aufgeteilt in Control school Test-driven school by Maud Schlich - IT-PROJECT-SERVICE Seite 4 von 21

3 s of testing (B. Pettichord) Vier s of testing: school school Assurance school school Gleiche Grundsätze Exemplarische (Test-)Techniken Gleiche Einstufung von Werten by Maud Schlich - IT-PROJECT-SERVICE Seite 5 von 21 Grundsätze Software ist logisches Artefakt Testen ist Logik / Mathematik Testen ist technisch Die eine richtige Antwort Wichtigste Frage: Welche Technik sollen wir wählen? by Maud Schlich - IT-PROJECT-SERVICE Seite 6 von 21

4 Beispiel Strukturorientiertes Testen (Code Coverage) Voraussetzungen / Werte Präzise und detaillierte Spezifikationen Tester prüfen Konformität der Software zur Spezifikation by Maud Schlich - IT-PROJECT-SERVICE Seite 7 von 21 Grundsätze Projekt Softwareentwicklung Testen als Maß für den Fortgang der Entwicklung Testmanagement Kosteneffektivität -> Anweisung von Testern Testen folgt Regeln Wichtigste Frage: Welche Metrik sollen wir wählen? by Maud Schlich - IT-PROJECT-SERVICE Seite 8 von 21

5 Beispiel Traceability Matrix (Requirements Coverage) Voraussetzungen / Werte Klare Eingangs- und Ausgangskriterien (Abgrenzung zu anderen Prozessen) Stabile Pläne Taylorism Best Practices, Standardisierung der Ausund Weiterbildung by Maud Schlich - IT-PROJECT-SERVICE Seite 9 von 21 Assurance Grundsätze Qualität durch Disziplin Testen zeigt, wie gut SW-Prozesse gelebt werden Kontrolle der Entwicklung durch Testen Tester schützen End-Anwender Wichtigste Frage: Folgen wir einem guten Prozess? by Maud Schlich - IT-PROJECT-SERVICE Seite 10 von 21

6 Assurance Beispiel Freigabe der SW durch QA Voraussetzungen / Werte Qualitätssicherung vor Testen Testen als Schritt zur Prozessverbesserung Tester und Entwickler stehen auf zwei Seiten by Maud Schlich - IT-PROJECT-SERVICE Seite 11 von 21 Grundsätze SW durch Menschen in definiertem Kontext entwickelt Bugs aus Sicht der Stakeholder durch Testen aufdecken Testen erzeugt Informationen für das Projekt multidisziplinäre, mentale Aktivität individuelles Können geht vor Best Practices Wichtigste Frage: Welche Tests sind gerade jetzt die wertvollsten? by Maud Schlich - IT-PROJECT-SERVICE Seite 12 von 21

7 Beispiel Concurrent Test Design und Ausführung Rapid Learning Voraussetzungen / Werte Stetig anzupassende Pläne basierend auf Ergebnissen Ungeprüfte Annahmen sind gefährlich Pragmatismus Feldtests zeigen Effektivität der Teststrategie Skills sind wichtiger als Best Practices by Maud Schlich - IT-PROJECT-SERVICE Seite 13 von 21 Risikobasiertes Testen Anwendungsprofile Berechnung der Zuverlässigkeit Risikowahrnehmung des Managements Pseudomathematik Assurance Projektrisiken aufdecken Zeigen, dass Projekt außer Kontrolle ist Risikoverständnis des Teams durch Testen Design von Tests auf Basis der Risiken by Maud Schlich - IT-PROJECT-SERVICE Seite 14 von 21

8 Usability Testing Keine Form des Testens Andere machen lassen Machen, falls Management es fordert Assurance Zurückhaltend Schwierig, Abweichungen vom Standard zu finden Auf jeden Fall durchführen Usability Bugs sind Bugs by Maud Schlich - IT-PROJECT-SERVICE Seite 15 von 21 Fehlende Spezifikationen Unmöglich Irgendetwas Ähnliches nutzen Grabe versteckte Spezifikationen aus Assurance Entwickler zur Prozesseinhaltung zwingen Tu was du kannst, um nützlich zu sein Frage, wo nötig Schau mal, ob nicht Spezifikationen oder Ähnliches irgendwo vorhanden sind. by Maud Schlich - IT-PROJECT-SERVICE Seite 16 von 21

9 Zertifizierung von Testern Weder dafür noch dagegen Einfacher Tester einzustellen, zu trainieren und zu managen Assurance Status des Testens und der Tester verbessern Aktuelle Zertifikate basieren auf Praxis nicht Können by Maud Schlich - IT-PROJECT-SERVICE Seite 17 von 21 Vertreten in/bei Wissenschaft Industrie mit Hochverfügbarkeits- Anforderungen (Telekommunikation) IT Projekte Projekte in Behörden Assurance Bürokratien Kommerzielle Software Marktgetriebene Software by Maud Schlich - IT-PROJECT-SERVICE Seite 18 von 21

10 Vertreter / Autoren Boris Beizer - Robert V. Binder John Musa - Paul Jorgensen Rex Black - Dorothy Graham Assurance Alka Jarvis Cem Kaner - Brian Marick James Bach - Brad Pettichord by Maud Schlich - IT-PROJECT-SERVICE Seite 19 von 21 / Literatur Pettichord, B. März s of Software Testing. [WWW] ols.pdf. (5. Dezember 2007). Pettichord, B. February Workshop on the Teaching of Software Testing. [WWW] (not working any longer). Cem Kaner. Cem Kaner s Blog» Blog Archive» s of software testing. [WWW] (5. Dezember 2007). by Maud Schlich - IT-PROJECT-SERVICE Seite 20 von 21

11 Maud Schlich Thomas Roßner IT-PROJECT-SERVICE imbus AG Vorstadt 35 Kleinseebacher Str Kirchheimbolanden Möhrendorf Tel mailto:ms@itprojectservice.de thomas.rossner@imbus.de by Maud Schlich - IT-PROJECT-SERVICE Seite 21 von 21