Smidig testing fra veislakt til hestekrefter

Presentasjon om: "Smidig testing fra veislakt til hestekrefter"— Utskrift av presentasjonen:

1 Smidig testing fra veislakt til hestekrefter
Geir Amdal og Rita Nordtug Hei, Ingen av oss har testfaglig bakgrunn, men lyntalen er basert på erfaringer og utfordringer fra forskjellige team i forskjellige prosjekt både i og utenfor BBS Temavalget er inspirert av boken agile testing av Lisa Crispin og Janet Gregory. Innholdet springer ut av samarbeid med strukturerte testere og arbeid med å integrere QA testing i smidig, og vi presenterer tiltak som har fungert og tiltak som er under utprøving.

2 Større organisasjon/prosjekt Dedikerte QA-ressurser
Anta følgende Større organisasjon/prosjekt Dedikerte QA-ressurser Strenge krav til produkt og sporbarhet Flere utrullingsmiljø Utvikling QA Akseptansetest Produksjon [Geir fyller inn] Geir lager ’før-bilde’ Miljøene

3 Verden har endret seg, testing not so much? Dette kan umulig gå bra
Hypoteser Verden har endret seg, testing not so much? Dette kan umulig gå bra Rollestereotyper kræsjer med smidig arbeidsform Kravene til krav er endret Vi har fire hypoteser: - Smidig har forandret utviklings verden, men testing foregår mer eller mindre uforandret - Vi tror dette ofte går galt - Rollestereotypene fra fossefalltiden vil ikke fungere i smidig - Med smidig så har kravene til krav forandret seg

4 Verden har endret seg.. MANUS: Testing har kjempefokus i smidig
Hva testing innebærer er ikke det samme i vannfall og smidig. Tidligere var praktisk talt all testing basert på manuelle tester ofte mot et bruker grensesnitt, men med smidig er hovedvekten på enhets og komponent testing. Smidig testing forutsetter automatisering fordi regresjonstesting må skje kontinuerlig.

5 Verden har endret seg.. Smidig testing forutsetter automatisering fordi regresjonstesting må skje kontinuerlig. Innenfor iterasjonen jobber vi mot et bevegelig mål Da må vi enten å gjøre kontinuerlig manuell retesting eller Vente til koden er klar og teste på slutten av iterasjonen. ------ Mulige konsekvenser: - vi har bare flyttet fossefallet inn i iterasjonen: test er fremdeles en isolert oppgave som gjøres etter at utviklerne er ferdig - testerne blir inkludert i teamet men ikke integrert som team medlemmer - testerne kan ikke gå god for kvaliteten på de automatiserte testene fordi andre har laget dem og de ikke selv kjenner teknologien. - vi er ikke ferdig-ferdig: koden er ferdig når iterasjonen er slutt, men testing sklir. - dette blir jo ikke smidig

6 Hva skjer når vi flytter fossefallet inn i iterasjonen?
Et tenkt tilfelle: Planen er å gjennomføre all utvikling først og så all testing for hele inkrementet inne i iterasjonen. La oss være greie til å starte med, og si at det går bra første iterasjon: Testerne venter riktignok på utviklerne i starten av iterasjonen, men få feil oppdages og teamet kommer i mål. Iterasjon 2 går det verre: Utviklerne blir forsinket og testerne får liten tid. Man kommer så vidt i mål ved å bruke overtid. Testerne ser igjennom fingrene med noen feil.

7 Hva skjer når vi flytter fossefallet inn i iterasjonen?
Dette vil selvfølgelig ikke teamet fortsette med så Tredje iterasjon sprekker det: Når iterasjonen er slutt, er man ikke ferdig. Halvparten av den manuelle testingen gjenstår. Dette gir teamet to valg: å si at de ikke er ferdige (og ikke få noen uttelling for oppgaven), eller å la testarbeidet fortsette inn i neste iterasjon (testgjeld). Teamet velger å la testarbeidet fortsette inn i neste iterasjon. Dette passer bra for testerne må uansett vente på utviklerne i starten. Høres dette kjent ut? Hva har egentlig skjedd her? Dette blir fort en ond sirkel med stadig mere work in progress: Oppgaver blir med på lasset gjennom flere iterasjoner uten å bli heeeeeeeelt ferdige. Feilrettingen (for feil oppdaget i iterasjon 2 eller 3) er ikke med i estimatene for sprinten Dette fører til ytterligere forsinkelse. Teamet valgte å la testingen fortsette inn i neste iterasjon. Det gjør at oppgaver ikke er ferdig ved slutten av sprinten og vi ikke overholder timeboxen. Hva betyr ’ferdig’ i en slik modell? Har demo-møtet noen mening? I praksis lekker fossefallet ut av iterasjonen igjen, og vi ender opp med å planlegge en oppgave over to iterasjoner. Først utvikling, så test.

8 Foreldede roller og nye arbeidsformer
Vår neste hypotese er at den tradisjonelle testrollen må forandre seg i smidig: Fossefallsmodellen fungerte som en kjede av oppgaver som ble utført av ulike roller. En utvikler var ansvarlig for utvikling og kunne ikke begynne sin oppgave før spesifikasjonen var overlevert Testeren var ansvarlig for testing og godkjenning av programvaren og kunne ikke begynne sin oppgave før programvarekoden var overlevert Fokus for den enkelte var innenfor sin rolle, hvordan skal jeg kunne gjøre min oppgave best mulig etter å ha fått overlevert resultatet fra det forrige leddet i kjeden? Så kom smidig med tverrfaglige team som skulle være selvorganiserende. Rollene skal ikke lengre overlevere men samarbeide om programvaren, og roller og hatter må endres etter behov. Spørsmålet er ikke lenger: når kan teamet kan gi meg det jeg trenger for å gjøre min jobb, men hvordan vi sammen kan levere det som er lovet i sprinten. Altså: Hva kan jeg bidra med for å få den felles leveransen i havn? Fokus går fra å være en rolle til å være et team medlem. Men en tester kan vel bare gjøre testing? © Bowie15| Dreamstime.com

9 Fra kvalitetspoliti til gjengmedlem
I utvikler-ører betyr ’å teste’ tradisjonelt å kontrollere kvaliteten på produktet ved å forsøke å finne feil og mangler i det. Testere kan kjenne seg igjen i en rolle som kvalitetspoliti, mens utviklere da blir gjødselprodusenter. (Nei, ikke kunstgjødsel.) Dette innebærer at den tradisjonelle modellen setter utviklere og testere opp mot hverandre som opponenter. Vi tror at vi må denne identiteten som kvalitetskontrollører til livs. © Anke Van Wyk | Dreamstime.com

10 Hva da - en sekk poteter? Fra før er vi vant til at alle har sitt eget avgrensede kompetanse- og ansvarsområde. [bilde 1] I et smidig team er det ment å endre seg. [bilde 2] Vi deler ansvaret for all jobben. Men vi gjør også jobben sammen. Da lærer vi også mer, og forståelse og kjennskap blir spredt. Vi må unngå at det blir en kobling mellom oppgave og person i teamet. Hvis testere fortsetter i rollen som kvalitetspoliti blir dette vanskelig. [Bilde 3] Man får nemlig ikke samarbeidet om å bli ferdig med oppgavene. I tillegg kan testerne bli utsatt for press om å gi godkjenning, slik at teamet som helhet skal komme i mål. Hva som ligger i ’ferdig’ blir to forskjellige ting internt i teamet.

11 Kravene til kravprosessen er endret
Vår fjerde hypotese er at måten vi arbeider med krav på har endret seg. - vi har ikke lenger lange spesifikasjonsperioder - hvor vi definerer en mursteins kravspesifikasjoner hogd i stein, signert i blod. - kravene er spesifisert pr enkeltoppgave ikke pr kvartalsmessige release. Utgangspunktet for hele prosessen endres ved at: - vi ikke spesifiserer kravene før de trengs og jo nærmere vi kommer jo mer spesifikke blir kravene. - mye av krav spesifiseringen skal nå skje r i form av samtale (vi skal snakke sammen!!!) - hvilke oppgaver som skal inn i en sprint skal kunne bestemmes av PO ved sprint planleggingen. - detaljer er ikke krav og tas under veis i iterasjonen - kravene må være konkrete, kvantifiserbare og testbare. - Egentlig burde det alltid ha vært slik men når de skal automatiseres er det kritisk.

12 Nye hatter, nye samarbeidsformer
Så la oss presentere noen mulige nye hatter for testerne: Power of 3 Alle diskusjoner om en oppgave/funksjonalitet skal ha 3 personer tilstede: en programmerer, en tester og produkteieren - testerne tilrettelegger kommunikasjonen mellom utviklere og kundesiden. Dette innebærer ikke at de skal komme i veien for den direkte kommunikasjonen mellom kunde og utvikler. Men de skal inkludere seg i kommunikasjonen i stedet, og sørge for at kommunikasjonen skjer når det trengs. Utviklere får riktigere forståelse av kravene Tester får riktigere forståelse av den tekniske løsningen kunde, qa og utvikling ender opp med et delt språk -- Etableres akseptkriteriene som del av kravprosessen, oppstår muligheten akseptansetestdrevet utvikling først i iterasjonen defineres (ved par-testing mellom utvikler og tester) automatiserte tester som skal brukes som akseptansetester på demo-runden testene utvides av testerne mens utviklerne skriver kode for å få dem til å passere vi får en løkke som går fra feilende akseptansetest feilende enhetstest  passerende enh. test  passerende akseptansetest Bonus: - feilrapportering i form av feilende tester © Vladimir Mucibabic | Dreamstime.com

13 automatisér, automatisér! Nødvendig automagi
Det er helt umulig å utvikle smidig uten automatisering av testene. fordi det ikke er nok tid til å gjøre all testingen vi trenger manuelt. Dette har smidigbeveglsen omfavnet og enorme mengder litteratur og verktøy er laget for å gjøre dette enklere. Det er likevel utviklerne som har tatt hovedansvaret for disse testene, hvilket har gjort at testerne ofte tenker at dette er noe som utviklerne holder på med og som jeg ikke forholder meg til. Det er jo helt borte i natta! Det er testerne som må eie de automatiserte testene og være hovedansvarlig for innholdet. Testene må være på en slik måte at testerne: a) selv kan definere dem uten å være avhengig av utviklerne b) ha tillit til testene selv om det er utviklerne som har koblet de sammen med koden Helst bør testerne ha kompetansen til selv å kunne lage de automatiserte testene fra topp til bunn Der det ikke er mulig så må disse utvikles i sammen med utviklerne i teamet. © Chris Doyle| Dreamstime.com

14 Pragmatisk hybrid? © Stephen Coburn| Dreamstime.com
Valget står ikke mellom alt eller ingenting. Det kan derfor være lurt å bruke hybridmodeller på veien fra dagens løsning til en mer smidig prosess. Man tar inn enkelte ting og bruker dette til å øke kompetansen til teamet som helhet. Det er både praktisk og lurt å velge ut det som er relevant for organisasjonen, og dermed sørge for å utnytte de ressursene vi faktisk har på teamet. For eksempel må ikke mangel på programmeringserfaring blant testere få bli et hinder for testautomatiseringen. Det vil uansett være tilstrekkelig kompetanse i teamet til at slike praktiske problem løser seg, bare det er et driv i riktig retning. Det er viktig at vi alltid drar så mye i riktig retning at det gjør litt vondt. ------ Å erstatte de manuelle testene våre med automatiserte regresjonssuiter er verken billig eller gjort i en håndvending. Hva gjør vi i mellomtiden, mens vi øker andelen automatisering? Vi deler opp oppgaver i to: Funksjonell oppgave (som innbefatter funksjonalitet, akseptansetesting og automatisert regresjon) -- testere er støttepersonell for utviklerne, samarbeider om å spesifisere akseptansekriterier og –tester --- nye automatiserte funksjonelle tester utvider tilfanget av automatisert test (til dels begrenset av legacykode og detestable arkitektur) --- ferdig: ferdig akseptansetestet leveranse fra utviklingsmiljø til qa-miljø Utrullingsoppgave (som omfatter manuell testing i test- og kundeakseptansetestmijø, siden vi ikke har tilstrekkelige regresjonssuiter fra før) -- starter med utrulling i qa-miljø, og nødvendig manuell regresjonstest for å dekke opp manglende automatiserte tester -- utviklere er støttepersonell for testere, samarbeider om løpende feilretting og tilrettelegging -- relevant egenskapstesting kjøres i denne fasen -- er mulig å sammenlikne med en rettet systemtest, med snevert skop og begrenset tid -- testlogger samles av testleder i egen rapport for sporbarhet av leveransen -- ferdig: ferdig testet og klart for utrulling i produksjonsmiljø - hva gjør vi når vi har flere parallelle team som alle har behov for tilgang til testmiljøene? - ofte vil man ha en koordinator og prosessansvarlig utenfor teamet også, spesielt dersom man har flere parallelle team. - prøver nå ut en løsning med sentral koordinering av testmiljøene for å unngå kollisjoner - tilgang samkjøres som del av planleggingsprosessen til teamene - dette innebærer at den som sørger for sentral koordinering har oversikt over alle leveranser og - blir samlingspunkt for sporing av krav, funksjonalitet og testresultat. - samler inn testlogger fra teamet og lager de formelle testrapportene per produksjonssetting © Stephen Coburn| Dreamstime.com

15 Anbefalt lesning

16