PTA Presentation SpiraTeam in Action Case Study
- 1. 23.03.2017 1 SpiraTeam im Einsatz Projekterfahrung aus einem Kundenprojekt www.pta.de
- 2. 23.03.2017 2 Inhaltsverzeichnis 1. Application under test 2. Für die QS relevante Systeme 3. Wichtige Lessons-Learned 4. Kurze Demo Testautomatisierung 5. Ausblick
- 3. 23.03.2017 3 Inhaltsverzeichnis 1. Application under test 2. Für die QS relevante Systeme 3. Wichtige Lessons-Learned 4. Kurze Demo Testautomatisierung 5. Ausblick
- 4. 23.03.2017 4 Application under Test Kurze Beschreibung und besondere Herausforderungen Anwendung • Branche: Einzelhandel • Aktionsplanung und -Nachbetrachtung Technologie • Programmiersprache: .NET • Windows Presentation Foundation • MS Visual Studio 2015 • Datenbank: Oracle 11g Besondere Herausforderungen • Kaum Zugriff auf bisherige Testdokumentation • System- und Anwenderdokumentation nicht vollständig bzw. einheitlich Nicht dokumentiertes Spezialwissen einzelner Mitarbeitern • Komplexe, nicht intuitive Anwendung Viele Ausnahmen und Sonderfälle Viele fachliche Abhängigkeiten der Testdaten
- 5. 23.03.2017 5 Inhaltsverzeichnis 1. Application under test 2. Für die QS relevante Systeme 3. Wichtige Lessons-Learned 4. Kurze Demo Testautomatisierung 5. Ausblick
- 6. 23.03.2017 6 Für die QS relevante Systeme Zusammenspiel der Systeme Testfälle Tester- gebnisse VorfälleSpiraTest (Testmanagement) Testskripte TestComplete (Testautomatisierung) TACT (Testumgebungen) AUT Manuelle Test- durchfühung TFS (Kanban) Incidents Anforder- ungen ArbeitspaketeAnforderung User Story
- 7. 23.03.2017 7 Inhaltsverzeichnis 1. Application under test 2. Für die QS relevante Systeme 3. Wichtige Lessons-Learned 4. Kurze Demo Testautomatisierung 5. Ausblick
- 8. 23.03.2017 8 Lessons-learned Wichtige Herausforderungen und unsere Lösungsansätze Komplexe Testszenarien erfordern Modularisierung der Testfälle Kontinuierliche Weiterentwicklung der Software (2-3 Releases pro Jahr) Wiederauffindbarkeit von Testfällen (ca. 1800 Testfälle) Integration der Testautomatisierung
- 9. 23.03.2017 9 Herausforderung: Modularisierung der Testfälle Lösungsansätze für die Modularisierung von Testfällen in SpiraTeam Anmeldung mit bestimmter Rolle Modularer Testfall Aufruf eines Dialogs Modularer Testfall Suche nach definierten Daten Modularer Testfall Manipulation der Daten Spezifischer Testfall Überprüfung im Bericht ErsterAnsatz Schritt 1 Schritt 2 Schritt 3 Schritt 4 Schritt 5 Eigentlicher Testfall
- 10. 23.03.2017 10 „Lessons learned“: Erster Lösungsansatz Modularisierung von Testfällen Struktur und Moduldefinition Komposition Ausführung1 2 3
- 11. 23.03.2017 11 Herausforderung: Modularisierung der Testfälle Lösungsansätze für die Modularisierung von Testfällen in SpiraTeam Anmeldung mit bestimmter Rolle Modularer Testfall Kurzbeschreibung des Testfalls Pre-/Postconditions Testhandbuch Aufruf eines Dialogs Modularer Testfall Suche nach definierten Daten Modularer Testfall Manipulation der Daten Spezifischer Testfall Überprüfung im Bericht Erster Ansatz Aktueller Ansatz Schritt 1 Schritt 2 Schritt 3 Schritt 4 Schritt 5 Spezifischer Testfall Eigentlicher Testfall
- 12. 23.03.2017 12 „Lessons learned“: Zweiter Lösungsansatz Modularisierung von Testfällen Änderungen • Definition von Vor- und Nachbedingungen in der Testfallbeschreibung • Verweis auf ein Testhandbuch für komplexe und/oder wiederkehrende Tätigkeiten • Verzicht auf Testfallmodule zugunsten von einfachen Testschritten Verbesserungen • Schnellere Testfallerstellung • Höhere Qualität der Testfälle • Weniger Redundanzen • Leichtere Zugänglichkeit für weniger erfahrene Tester
- 13. 23.03.2017 13 Struktur der Testfälle Ordnerstruktur und Namenskonventionen Testfälle werden nach Prozessen in (Unter-)Ordnern strukturiert. Namenskonvention: Objekt_Kurzbeschreibung_Unterklassifizierung_Aktionsbereich Testfälle werden Testart-übergreifend zusammengefasst (benutzerdefiniertes Feld)
- 14. 23.03.2017 14 Pflege der Testfälle bei Release-Wechsel Regressionstest Anforderungen Fehlernachtest Anforderungen Fehlernachtest Release A Release B Regressionstest
- 15. 23.03.2017 15 Integration der Testautomatisierung Strukturierung der Testfälle Erster Ansatz AktuellerAnsatz Unterscheidung durch Attribut „Automatisierungsplattform • Die manuellen und die automatisierten Tests wurden in getrennten Ordner abgelegt • Nachteil war die fehlende Transparenz in der Abdeckung
- 16. 23.03.2017 16 Inhaltsverzeichnis 1. Application under test 2. Für die QS relevante Systeme 3. Wichtige Lessons-Learned 4. Kurze Demo Testautomatisierung 5. Ausblick
- 17. 23.03.2017 17 Inhaltsverzeichnis 1. Application under test 2. Für die QS relevante Systeme 3. Wichtige Lessons-Learned 4. Kurze Demo Testautomatisierung 5. Ausblick
- 18. 23.03.2017 18 Ausblick Integration SpiraTeam / Team Foundation Server • Unterschiedliche Nutzergruppen pro System • Inkonsistenzen aufgrund manueller Übertragung von Vorfällen • Ziel: Automatische Synchronisation durch Einsatz des TFS-Plugins Tester BA EntwicklerPL/QS PL/QS Vorfälle
- 19. 23.03.2017 19 Referenten www.pta.de Dr. Johannes Skarka PTA GmbH Seckenheimer Str. 65-67 D-68165 Mannheim +49(0)621/41960-936 Johannes.Skarka@pta.de Keno Glasmeyer PTA GmbH Adlerstr. 72 D-40211 Düsseldorf +49(0)211/913289-205 Keno.Glasmeyer@pta.de
Hinweis der Redaktion
- #7: Für jedes Release (ca. 3 Monate Entwicklung) wird ein Anforderungsdokument erstellt User Storys werden samt Anforderungen im TFS verwaltet Hauptanforderung = UserStory, Anforderungen als Unteranforderung werden im SpiraTeam nur als Dummy zu Reportingzwecken geführt(Testabdeckung etc.) Referenz auf Kapitel
- #10: Ggf. viele Vorschritte notwendig, um die zu testende Funktion zu erreichen. Testfälle so schreiben, dass „jeder“ die Testfälle durchführen kann Ziele der Modularisierung: Wiederverwendbarkeit Abbildung von Testfallvariationen über Parameter Standardisierung Zeitersparnis bei ... Testfallerstellung Testausführung
- #11: Schritte: (Animation Nr. 0) Identifizieren von Modulen Strukturieren der Module Komponieren der Testfälle aus den Modulen Ausführen der Testfälle Probleme in unserem Szenario: Jeder auszuführende Schritt muss als Testfallmodul vorliegen Kein „ad-hoc“-Einfügen von Testschritten Das Komponieren von Testfällen ist mühsam (GUI) (Animation Nr. 1) Kein mehrfaches hinzufügen des selben Moduls in einem Arbeitsschritt Auswahl der Module in kleinem Fenster Vorherige Position/Auswahl wird nicht gespeichert Eigentlicher Kern des Testfalls geht selbst bei kleinen Testfällen unter (Animation Nr. 2) Beispiel beschreibt einfachen Testfall Problem wird größer bei umfangreichen Testfällen Beispiel: User-Story Testfälle
- #12: Lösung: Keine Modularisierung Vereinfachung der Testfälle Vor- und Nachbedingungen Referenz auf Testhandbuch für wiederkehrende Aufgaben Frage: Haben die Änderungen den erwünschten Erfolg erbracht?
- #13: „Höhere Qualität der Testfälle“: die alten Testfallmodule teilw. nicht genau auf den jew. Ablauf passten. Verwendet wurden sie trotzdem, was insbesondere bei unerfahrenen Testern für Irritationen sorgte. Mit der neuen Struktur können Variationen im Testvorgehen leichter umgesetzt werden.
- #14: Anordnung der Testfälle: Zuvor: Nach Release, Testart und Funktionalität Jetzt: Testfälle werden Testart-übergreifend nach Prozessen angeordnet Bessere Übersicht bzgl. Testabdeckung; automatisiert/manuell, allg. Navigation zwischen Testfällen Namenskonvention: Der Ordner, in dem der Test liegt, beinhaltet schon Informationen zum Prozess, den der Test prüft Anordnung nach Objekt_Kurzbeschreibung_Unterklassifizierung_Aktionsbereich um sicherzustellen, dass zusammenhängende Testfälle immer untereinander stehen
- #15: Nach einer Release müssen die Regressionstests angepasst werden (neue Anforderungen etc.) Zusätzlich werden Testfälle zu neuen Anforderungen oder Fehlernachtests in die Regressionstests zum nächsten Release aufgenommen. In Release B kommen wieder neue Anforderungen und Fehler, die ihre eigenen Tests benötigen.