Test i Praksis NTNU Februar 2014
Hvem er vi? Erik Gjerdrum Master i Kommunikasjonssystemer fra IFI UiO Jobbet med test i siden 2006 Markus Living Master i Industriell Økonomi fra Linköping, Sverige Jobbet som tester siden 2013 2
Test i Accenture Mer enn 30 stykker som har test som karrierevei Egne kurs/sertifiseringer Konferanser Mer enn 50 som jobber med test til daglig ute på prosjekt hos kunder Test er en sentral og integrert del av all systemutvikling vi utfører 3
Agenda Introduksjon til test Testing i praksis En utviklers hverdag Oppsummering 4
Agenda Introduksjon til test Testing i praksis En utviklers hverdag Oppsummering 5
Myter om test Du trenger ikke teste: Det er bare en to-linjes endring Du trenger ikke teste: Vi skal ha en pilot Du trenger ikke funksjonelle tester: Brukerne tester dette for oss Du trenger ikke regresjonsteste: Gammel kode virker alltid Vi har ikke tid til å teste: Vi har nok med å fikse feil fra produksjon Du må stoppe å teste: Hvis du finner flere feil nå så rekker vi ikke deadline Ikke test: Det å finne feil lager dårlig stemning i teamet Jeg tester ikke: Det står ikke i min jobb-innstruks Jeg dokumenter ikke test-tilfeller og resultat: Det begrenser kreativiteten og stjeler tid fra tilgjengelig tid til å teste 6
Hvorfor er test viktig? Folk gjør feil men liker ikke å innrømme det! Feil kan få alvorlige konsekvenser: Risikoreduksjon Verifisere at løsningen tilfredsstiller Spesifikasjonene Oppdage og rette feil før produksjon: Kvalitetsheving Kjenne Kvalitetsnivå til løsningen som settes i produksjon 7
Veien til VG er kort. 8
Veien til VG er kort. 9
Hva er Test? ALT vi gjør for å sikre kvalitet i produktet som skal leveres Før utvikling starter Underveis Etter at utvikling er ferdigstillt Test er mye mer enn å finne bugs 10
Hva er Test? Test inngår som et ledd i kvalitetskontrollen av leveransene. Målet for alle testaktiviteter er todelt: å sikre at nye leveranser ikke fører til feil, forstyrrelser eller ustabilitet i det totale produksjonsmiljøet å teste at leveranse og totalprodukt tilfredsstiller både de funksjonelle og tekniske forretningsmessige krav 11
Hvem er en tester? ALLE Utvikler Dedikert person med testfaglig kompetanse Automatiserte tester Osv, osv Teammedlemmer som kun jobber med test er en luksus! 12
Agenda Introduksjon til test Testing i praksis En utviklers hverdag Oppsummering 13
Test i praksis Før utvikling starter Sikre at kravene til det vi skal levere er forståelige, entydige og testbare Sikre at kunde og levandør har en felles forståelse om hva som skal leveres 15
Test i praksis Felles forståelse av hva som skal leveres Hvordan kunden forklarte sine ønsker Hvordan prosjektlederen forsto det kunden forklarte Hvordan utvikleren programmerte det Hva kunden egentlig trengte 16
Test i praksis Underveis Enhetstest, Integrasjontest og Egentest Utarbeidelse av testmodell, forberedelse til systemtest Fritest/Bughunting Hyppig avklaringer 17
Test i praksis Etter utvikling er ferdigstillt Systemtest Regresjonstest Akseptansetest 18
Test i praksis Testfaser Enhetstest Integrasjonstest Egentest Systemtest Fritest Regresjonstest Akseptansetest 19
Agenda Introduksjon til test Testing i praksis En utviklers hverdag Oppsummering 20
En utviklers hverdag Testdreven utvikling (TDD) Enhetstest Integrasjonstest Utviklers egentest 21
En utviklers hverdag Test sine krav til utvikling, eksempler Test forventer og krever at kode aldri sjekkes inn uten enhetstest. Tester skal alltid være med i samme innsjekk. Test forventer og krever at alle antakelser avklares med fagressurs eventuelt Scrum Master og dokumenteres i aktuell brukerhistorie. Alle linjer som vises som ikke testet i code coverage report, må kunne begrunnes hvorfor de ikke er testet dersom utvikler får spørsmål om det. Test forventer og krever at utvikler har et bevisst forhold til testdekning og kvalitet på sine enhets- og integrasjonstester, at en modul ikke lukkes med dårligere testdekning og kvalitet enn når den ble åpnet og at testdekningen (med god margin) er innenfor prosjektets krav. 22
Testverktøy 23
Jenkins 24
Crucible 25
Sonar 26
Selenium Selenium 27
Agenda Introduksjon til test Testing i praksis En utviklers hverdag Oppsummering 28
Oppsummering Hva er test? Testing er å komponere, redigere, fortelle og rettferdiggjøre tre historier: En historie om status på Produktet Hvordan det feilet, og hvordan det kan feile på måter som betyr noe for sluttbruker En historie om Hvordan du testet det Hvordan du konfigurerte, gjennomførte og observerte testen Hva du ikke har testet (enda ) Hva du ikke tenker å teste i det hele tatt (og hvorfor) En fortelling om hvor God testingen var Hva risikoen og kostnaden ved testingen var Hva gjorde testingen vanskelig å gjennomføre Hvor testbart produktet var Hva du trenger videre og hva du anbefaler til neste fase 29
Viktige punkter å tenke på Komme i gang med testing så tidlig som mulig Automatisering Alt som er mulig og hensiktsmessig SKAL automatiseres Skape tillitsforhold Mellom kunde og leverandør Innad i leverandørteamet Hvem som har gjort «feil» er ikke viktig, fokuset er IKKE på skylddeling, men å få en god løsing Bygge kvalitet og gi gode løsninger til kunden 30
Myter om test Du trenger ikke teste: Det er bare en to-linjes endring Du trenger ikke teste: Vi skal ha en pilot Du trenger ikke funksjonelle tester: Brukerne tester dette for oss Du trenger ikke regresjonsteste: Gammel kode virker alltid Vi har ikke tid til å teste: Vi har nok med å fikse feil fra produksjon Du må stoppe å teste: Hvis du finner flere feil nå så rekker vi ikke deadline Ikke test: Det å finne feil lager dårlig stemning i teamet Jeg tester ikke: Det står ikke i min jobb-innstruks Jeg dokumenter ikke test-tilfeller og resultat: Det begrenser kreativiteten og stjeler tid fra tilgjengelig tid til å teste 31
Avsluttende ord Alle kan sjekke at ting fungerer Det krever ferdigheter for å kunne teste 32
Spørsmål? 33