Lav testsuppe på en sten med exploratory test TestExpo 29. Januar 2015
Lidt om mig selv Uddannelse Konstabel i flyvevåbnet Certificeringer: SCRUM master, ISEB foundation/practitioner, CAT trainer, TMap Test Engineer, TPI Next foundation Ansættelse 19 års ansættelse i IT branchen Heraf 3 år i Capgemini Sogeti Gitte Ottosen Managing Consultant Capgemini Sogeti Danmark A/S Gitte.ottosen@capgeminisogeti.dk +45 52 18 97 11 Twitter: godtesen Erfaring Testledelse, Test engineering, SCRUM, procesforbedring, LEAN, agile, Kontekst drevet test, forandringsledelse Agil erfaring Kunder: Mærsk Line IT, DONG Netværk Test20/Tecpoint, CAT trainer network Fellow Sogeti Labs 2
Hvorfor denne præsentation? Reaktioner omkring exploratory test: Det lyder så simpelt, men hvordan gør vi i praksis? Har hørt og læst en masse omkring exploratory, men hvordan kommer jeg igang? Mindre teori mere praksis Jeg vil vise jer et eksempel på hvordan jeg har brugt exploratory i en bestemt kontekst, for at inspirerer dig til at komme igang. Jeg har ikke en best practice men jeg har en good practice ud fra den kontekst jeg var I på det tidspunkt. 3
Jamen hvad med alt det gamle vi har lært? All these test design techniques are still relevant in exploring. The more familiar you are with test design, the better able you are to design good experiments on the fly. Elisabeth Hendrickson - Explore It 4
Lad os komme igang! 5
Definition of Exploratory Test An interactive process of simultaneous learning, test design, and test execution. Exploratory testing is not against the idea of scripting. In some contexts, you will achieve your testing mission better through a more scripted approach; in other contexts, your mission will benefit more from the ability to create and improve tests as you execute them. I find that most situations benefit from a mix of scripted and exploratory approaches. James Bach Exploratory Testing Explained
7
Casen Projektet Lille agilt projekt (6 deltagere inkl. mig) Distribueret team udviklerne var i Kuala Lumpur Udvidelse af et system der allerede var i produktion Systemet Web baseret applikation Komplekse muligheder for at oprette og skræddersy dialoger og oversigter fra brugerfladen Komplekse definitioner af beregninger fra brugerfladen Forbindelse til Data Warehouse 8
Udfordringen Organisation Krav fra TMO Produktejer <-> Projektleder Test basis Ingen system specifikation for det eksisterende system Kun begrænset bruger dokumentation (to slides) En masse user stories men intet overblik og begrænset forretningsperspektiv Ingen testware for den del af systemet der allerede var I produktion. Den menneskelige udfordring Produktejer kun til rådighed på deltid Produktejer kunne ikke se værdien af en tester Spild ikke tid på dokumentation, det er overhead! Kun begrænset adgang til folk på projektet. 9
Udfordring modtaget Men hvad så? 10
Identificer interessenter Projektleder Test management office (TMO) Produktejer Brugere Senior udvikler Superbrugere Udviklere 11
Krav fra TMO Definer og dokumenter test strategi Kontinuerlig test i løbet af projektet Udvikling af regressionstest Dokumenter test i Quality Center 12
Det første overblik Produktejer præsenterede systemet Nuværende funktionalitet en overordnet præsentation Det nye en mere detaljeret præsentation. Kun mundtlig, ingen dokumentation 13
Fra samtalen det indledende mindmap 14
Overblik over user stories Grupér stories i features 15
Men hvorfor døje med det System Feature 16
Test Strategy på én side Formål Scope Produkt risici Projekt risici Test niveauer Unit test Unit integration test Test på story niveau Test I sprintet Regressionstest Værktøjer og teknikker Test design teknikker Test dokumentation QC 17
Få overblikket Indledende udforskning Startede med den del der var i produktion (stabil) Stiftede bekendskab med applikationen Identificerede: Generelle koncepter Generelle problemer MASSER AF NOTER 18
Resultatet efter første udforskning 19
Hvorfor et elektronisk mindmap? Kommunikationsbehov deles med: Produktejer Udviklere Af historiske årsager gemt i QC efterfølgende og fordi jeg har en dårlig håndskrift 20
Mere struktur på Meget mere udforskning Identifikation og brug af relevante testdesignteknikker Identifikation og brug af relevante heuristikker EP Pair-wise 21
Hvor skal jeg bruge dem? 22
EP/BVA og klassifikationstræ Field1 Field 2 Field 3 Field 4 Field5 23
Datakombinationer med pairwise. 24
Process Cycle Test Møde med en superbruger Tegne og diskutere Udforske systemet Udvikle tegningen Præsentation for produktejer Yes Yes No No 25
Men også det kreative Gad vide om de har kigget på felt-længder i databasen da de definerede felter I GUI? Har de husket at understøtte danske bogstaver? Man kan lave så mange typer af beregninger, hvad hvis man kombinerer de forkerte I en beregning (en i Kilo og en anden I Liter) Når du kan specificere interval (dag, uge, måned) hvad så hvis du kombinerer forskellige intervaller? Hvad hvis en bruger ikke tilføjer kolonner når han laver dialogen? Hvad hvis brugeren bliver afbrudt og forlader applikationen I 15minutter uden at gemmme? Hvilke typer af brugere er det vi har? Forstår de engelsk? (fejlmeddelelser på engelsk) forstår de teknisk engelsk... Osv osv 26
Heuristikker Nul, en, mange For mange for få I starten, i midten, til slut Sortér nummerisk <-> alfabetisk Geografisk placering 27
28
Præsentation af det fundne Præsentation af klassifikationstræ Præsentation af bugs Diskussion om severity og prioritet Dokumenteret i fejlhåndteringsværktøj 29
Supporter teamet Input til testdesign Kontinuerlig test af stories Afklaring af stories Supporter dokumentation af accept kriterier Reproducer fejl (dele desktop) Verificer fejlrettelser 30
Hvordan laver vi en god unit-integration test? Automating what was originally manual test Create a new meter with the following values Remember negative scenarios 31
Regressionstest: Fra Mindmap til Quality Center Gemte test strategi I roden Fra mindmap til testtræ Dokumenter charter/mission Tilføj resultat af testdesignteknikker Ingen eller få trin (måske bare ét brug vedhæftede.) 32
Resultatet Maksimum tid brugt på at teste, minimum på at dokumentere Grundig test af ny funktionalitet Regressionstest af eksisterende funktionalitet Oprettelse af regressionstest suite Support til unit integration test Afklaring af user stories Feedback til/fra produktejer En masse fejl i både ny og gammel funktionalitet Og en produktejer som nu så værdien af at nogen lavede struktureret test. Kan du komme tilbage næste år? 33
Hvad jeg tog med mig? Genopdagede glæden ved exploratory test Fokus på at kombinere det jeg ved og at bruge mit værktøjsbælte Man kan godt fastholde resultatet af exploratory test, men husk dine noter. 34
Forudsætning for denne tilgang Erfaren tester Erfaringer fra andre projekter Kender testdesign teknikker Kender heuristikker Er struktureret Regressionstest De næste testere kender systemet De næste testere forstår testdesign teknikker... Hvis ikke må du dokumentere mere. Tilpas ideen til din KONTEKST 35
Questions? 36