Smidige testprinsipper

Transkript

1 Smidige testprinsipper Frokostseminar Mai 2017 Øyvind Utby

2 Øyvind Utby NTNU - Siv.ing elektronikk. Lektor realfag. Accenture, 3 år Fossefall generasjon Comperio, 2 år Søk, PL, Smidig DSS, 4 år Testansvarlig, SM, Smidig SOCO, 4 år Testledelse, testrådgivning ISTQB Adv TM/Agile.., SM, PO, Prince2

3 Meny Smidig testing Trender Hvordan ivareta den økte kunnskapen i prosjektet? Akseptansekriterier, Testscenarier

4 Utgangspunkt

5

6 Hvorfor smidig? Vet alt på forhånd? Endringer i krav/ behov? 40 % av feil à krav

7 Hvorfor smidig? Vet alt på forhånd? Endringer i krav/ behov? 40 % av feil à krav

8 Tid kost - omfang

9 Smidig på alle prosjekter? Problem Kjent Ukjent Vannfall Scrum LEAN Startup Kjent Løsning Ukjent

10 Hva er din/deres største utfordring med smidig testgjennomføring? 1. Manglende verktøy? 2. For dårlig samarbeid/ dialog? 3. Manglende prosess? 4. Ressurser (feil folk/ kompetanse)?

11 Hva er din/deres største utfordring med smidig testgjennomføring? 1. Manglende verktøy? 2. For dårlig samarbeid/ dialog? 3. Manglende prosess? 4. Ressurser (feil folk/ kompetanse)?

12 Hva gjør de som lykkes? Fullfører små endringer av produktet som de eksponerer for brukerne for å få feedback. Planleggingstid uten resultat à ekte validering av antagelser.

13 Agile manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

14

15 Noen test-trender (fra internasjonal forskning og egen erfaring) 1. Kundens/ brukernes forventninger øker! Godtar ikke feil og dårlig funksjonalitet like lett, og forventer ny funksjonalitet raskere à Hoved-driver 2. Fra reaktiv à Proaktiv kontinuerlig testing 3. Agile à Kontinuerlig deploy, (CD) 1. Betinger at testing er integrert i design og utvikling 2. Automatiske tester (42 % bruker Selenium, 5 % Cucumber) (kilde; How the world tests 2015) 4. Bruke cloud based device farms til mobiltesting, eks Crossbrowsertesting 5. ET mer bruk av utforskende testing 6. Økt fokus på, og viktighet av, sikkerhet- og penetrasjonstesting

16 Trend - ET

17 Trend - AUTOMATISERING

18

19 DN, 14/5-2017:

20 Oppsummert skal Visma Flyt Skole 1 Understøtte og standardisere gjennomføringen av hele skoleåret Planlegge skoleåret Inntak Følge opp elever og undervisning Gjennomføre eksamen Etablere utdanningstilbud Sluttvurdering og vitnemål 2 Erstatte 10 systemer nasjonalt 3 Være tilgjengelig for 100 ganger flere brukere enn i dag og tilrettelegge for bedre kommunikasjon SAS brukere i dag Visma Flyt Skole brukere i fremtiden Frigjøre mer tid til pedagogiske aktiviteter I dag - + Pedagogiske aktiviteter Skolens relative tidsforbruk Administrative aktiviteter - iskole (1) SAS Admin Være tilgjengelig på smarttelefoner, nettbrett og PC-er VFS Admin Lærere Elever Foresatte Totalt 6 7 Integreres med viktige fellessystemer Unntatt offentlighet (jf. offl. 14) FELLES/SENTRALE Vigo PAS2 (Udir) Samordna Opptak/NVB Folkeregisteret DBH-F (fagskole) Visma Flyt Skole LOKALE Sak/Arkiv HRM Økonomi LMS (læringsplattform) Diverse andre systemer Integreres med sentrale lokale systemer for å redusere dobbeltregistrering av data og sikre bedre dataflyt

21 Sentralt mottaksprosjekt (SMP) styrer helheten og skal sikre at Visma leverer i henhold til kontrakt Sentralt MottaksProsjekt (SMP) = Vigo IKS LeveranseProsjektet (LP) = Visma Lokale InnføringsProsjekter (LIP) = Alle fylkene Unntatt offentlighet (jf. offl. 14) Implementering av Visma FLYT Skole 21

22 Kontrakten SSA-T (Statens StandardAvtaler Tilpasning)

23 Testbasis Kravspek Akseptansekriterier Testscript

24 Mulige KPI er fra test Leveranse per sprint Antall feil per sprint Antall feil akkumulert Suksessrate (godkjente tester kontra ikke godkjente) Feil per testobjekt (per epos/ brukerhistorie/ feature etc)

25 Akseptansekriterier AK hvordan bygge inn kunnskapen? Kunnskap AK = Hva, hvordan + feil og endring ΔAK = Feil og endringer AK = Hva og hvordan AK ΔAK = Hvordan AK = Hva skal løses Kravspek ΔAK = Hva A B C D AK = Krav (nåsituasjon) Behov Spec. Detaljert design Utvikling Test - UAT Tid

26 Produkteier fagperson samarbeidsmodell

27 Mal for testscenarier (og eksempler) En mal for testscenarier er en av følgende alternativer; Som <rolle> gjør <oppgave> og sjekk at <det som skal testes> Gjør <en oppgave> og sjekk at <det som skal testes> Sjekk at <det som skal testes> Det skal ikke være masse detaljer inn i testscenariene slik at de nærmer seg testbetingelser/test cases, men nok detaljer til at testeren forstår HVA som skal testes. All enighet om funksjonalitet bør kunne beskrives i slike enkle setninger, og det er ofte det minst åpenbare som er mest interessant å få med. Noen eksempler (fra kodeverket): - As school owner, check that you can update description on existing imported codes - As school admin, check that you only have read access to codes and descriptions - Check that updating a description on an existing code is updated on the relevant schools within the same county (automatic update) -

28 Prosess - Testscenarier Open In progress Draft agreed Ready for verification Ready for UAT Closed Needs mapping Design, implementation, verification Accept Change management Legend Close interaction SMP-LP Visma activity ad hoc SMP involvement SMP responsibility

29 Burndown for tester à Prosjektstatus à forankring Value 150 Planned Actuals Date

30 Smidige testprinsipper Strev etter å finne feil tidligst mulig i krav (40%), design Proaktivt testarbeid Agile manifesto DIALOG utvikler bruker Bedre og mer bruk a ET Finn en måte å ivareta den økte kunnskapen på Testscenarier. Jobb for forankring på toppen Status på testene grunnlag for rapportering.

31 Kilder Bøker: - Agile Testing Lisa Crispin - 50 quick ideas to improve your tests David Evans, Gojko Adzic