12 spørsmål om test Besvarelse på Case – Senior Testleder -Leif Kristian helstad 26.Mai 2015.

Presentasjon om: "12 spørsmål om test Besvarelse på Case – Senior Testleder -Leif Kristian helstad 26.Mai 2015."— Utskrift av presentasjonen:

1 12 spørsmål om test Besvarelse på Case – Senior Testleder -Leif Kristian helstad 26.Mai 2015

2 Kvalitet og betydningen av kvalitet i testarbeidet.  Testing indikerer kvaliteten på en løsning.  Man kan ikke teste inn kvalitet i en løsning og testing garanterer ikke kvalitet.  Skal man kunne gjøre noe med kvaliteten på en løsning må man verifisere kvaliteten underveis.  Måling av kvalitet kan gjøres via mange former for test.  Kvalitet er et relativt begrep i forhold til kundens forventning  Behovet for å sikre kvalitet styrer også hvilket nivå man legger seg på i testingen. 1

3 Testplan for et prosjekt med små og store leveranser (1/2)  Så tidlig som mulig:  En systemoversikt bør være på plass, gjerne både en funksjonell og en teknisk.  Risikoområder må identifiseres og bestillers forventinger til kvalitet avklares.  Hvem som deltar i test underveis og hvem som deltar i avsluttende test må avtales.  Testing underveis i fasene:  Selvstendige oppgaver (Stories) bør testes i løpet av sprinten den utvikles.  Større oppgaver (Epics) bør testes så snart delkomponetene er klare (system- integrasjonstes).  Det kan være en fordel å skrive separate testcase fremfor beskrive for mye rundt test i en Epic. Testcase kan også skrives for Stories, spesielt hvis de er gode regresjonstester som skal automatiseres eller benyttes videre på andre måter. 2

4 Testplan for et prosjekt med små og store leveranser (2/2)  Overordnet testplan Sprint123456789 Utviklings- og testsprint vvvvvv Feilrettingssprint vvv Prodsetting isolerte endringer vvvvv Integrasjonstest vvvvv Tekniske tester vvv Systemtest vvv Aksepttest + Reg.test vv Prodsetting hovedleveranse v 2

5 Planlegge test som inkluderer et system der data kontinuerlig oppdateres  All testing forutsetter et forventet resultat (i motsetning til prøving).  Hvis data forandres innenfor testperioden må testen ta høyde for dette.  Hvis oppdateringene er forutsigbare kan man dra nytte av dette i testen.  Det er viktig at alle som benytter dataene er kjent med eller lett kan gjøre seg kjent med når det er planlagt at data endres.  Hvis det i forbindelse med f.eks. hovedleveranser er behov for å avvike det ordinære kjøremønsteret må dette varsles og informasjon tilgjengeliggjøres.  Som testleder er det nødvendig kjenne til når forutsetningene i testsystemet forandres.  Det er også nødvendig å ta rede på om noen av kjøringene kan skape problemer knyttet til enten data- eller dato-synkronitet med andre systemer.  System som er integrert med hverandre enten via data eller dato må testes samlet i en integrasjonstest. 3

6 Innføring av automatisert test  Uten klar forståelse av løsningen og en god beskrevet manuell test vil en automatisert test kun være hurtig kaos.  Automatiserte tester egner seg best for løsninger der den kan fokusere isolert. (Kun en funksjon, kun en teknisk platform, kun en integrasjon… )  En del automatisering er avhengig av hvordan krav er beskrevet. Særlig automatiserte tester som bygger på TDD og BDD.  Noe som ofte er kan gi raskere gevinst er «Teststøtte-automatisering» fremfor «Test-automatisering». Det vil si systemer for miljøverifikasjon, miljøoppsett, datafangst og gjenopprettelse av data.  Ren test-automatisering kompliseres av antall parameter som kan påvirke testen. I tillegg er subjektive tester som for eksempel test av brukeropplevelse vanskelig å automatisere.  I tilfeller der flere systemer presenteres i ett felles frontsystem (som ett), bør man vurdere å holde den automatiserte testingen innenfor det enkelte system. 4

7 Testobjekter det er uttalt at det ikke finnes testbehov  Utviklingsleder forteller "denne funksjonen/komponenten trenger du ikke teste, - det har vi i utvikling gjort".  En slik komponent må vurderes for test på samme nivå som alle andre komponenter.  En viktig faktor er hvordan utvikling dokumenterer sin testing. Hvis utviklingsteamets valg av testdata og resultatet fra testen er tilfredsstillende så kan det være godt mulig at utviklingslederens anbefaling kan følges.  Dette er en mulighet til å kvalitetssikre testingen til utviklingsteamet. En (velrettet) stikkprøve eller eventuelt en statistisk test kan raskt si noe om kvaliteten på den testen som er gjort.  Teste testen, teste løsningen eller teste begge for sammenlikning. 5

8 Testleders ansvar ovenfor utviklings dokumentasjon og ansvar  I utgangspunktet bør testleder ha tiltro til det utvikling leverer og den kvalitet de rapporterer på det som er levert.  Det er likevel positivt hvis resultater fra byggserver og andre verktøy presenteres kontinuerlig på et lett tilgjengelig sted. (Wiki, skjerm i lokalet, e-post…)  På Story nivå gir det bedre tiltro til det som er levert hvis det refereres til data benyttet i enhetstest eller det finnes referanse til testresultater.  Hvis det avdekkes at enhetstester ikke er tilfredsstillende gjennomført  Det kommer normalt raskt til syne hvis Stories ikke er enhetstestet godt nok. Da må man ta dette med den enkelte utvikler, teamleder, teamet eller utviklingsleder.  Det bør klarlegges ganske raskt om det finnes rutiner som ikke følges eller om det dreier seg om et fravær av rutiner. Er det kun en på teamet som «sluntrer unna» er det teamets oppgave. Er det slik at et helt team har for dårlige rutiner bør testleder involveres mer, kanskje med rådgivning eller via annen oppfølging. 6

9 Prioritering i avsluttende testfaser (System-, systemintegrasjon- og aksepttest)  Prioriterte oppgaver i avsluttende test  Regresjonstest av hovedløpet  Test av synlig funksjonalitet (områder som vil skape overskrifter hvis de feiler)  Test av områder som skaper store kostnader (selv ved et lite antall feil)  Integrasjonspunkter som er nye i løpet av leveransen  Prioritering ved tidsknapphet i avsluttende testfaser  Testingen bør utføres risikobasert. Områder med stor sannsynlighet for feil eller der feil kan gi store konsekvenser må testes først.  Hvis tiden til test plutselig blir vesentlig forkortet bør det varsles at test-teamtes evne til å si noe om leveransens kvalitet er blitt begrenset.  Normalt sett har man likevel en rimelig kjennskap til leveransens kvalitet hvis det har vært testet underveis i hele utviklingsløpet, et kjennetegn på smidig utvikling. 7

10 Test av leveranser som ikke leveres etter plan, men som har låst produksjonsdato.  Selv med fast leveransedato må man vurdere kvalitet og risiko  Testleder må varsle hvis muligheten for å si noe om leveransens kvalitet ikke er tilstede  Mulige tiltak kan være  Begrense leveransen (kun det som er låst til dato, hvis det er mulig)  Manuelle rutiner bør vurderes, noe avhengig av den forventede forsinkelsen 8

11 Test av web-applikasjoner  Løsninger som må støtte ulike nettlesere  Så lenge man ikke har kontroll på hvilke nettlesere som vil bli benyttet må man undersøke hvilke som er de mest aktuelle.  Er det snakk om videreutvikling av eksisterende løsninger bør man kunne hente ut data fra dagens trafikk via for eksempel google analytics  Er det snakk om en ny løsning kan man enten ta utgangspunkt i andre løsninger man har eller mer generell statistikk. (http://www.w3schools.com/browsers/browsers_stats.asp)http://www.w3schools.com/browsers/browsers_stats.asp  I tillegg til nettlesere bør testen også ta høyde for ulike platformer  Nødvendigheten av å test responsivt design og mobile enheter har økt.  Man bør så snart som mulig etablere statistikk på både plattformer og lesere 9

12 Integrasjonstest etter funksjonelle endringer i ett system  Testplan (hvordan)  Under veis i sprintene skal den nye funksjonaliteten testes fortløpende.  Så snart et integrasjonspunkt er ferdig utviklet bør dette testes isolert.  Alt avhengig av de «omliggende» systemene bør regresjonstest av det enkelte system i helheten vurderes.  Teststrategi (hva)  De funksjonelle endringene må testes i sin helhet. Innsatsen per funksjon må vurderes i forhold til kriteriene for risiko.  Hvis de funksjonelle endringene har skapt endringer i grensesnittene mot andre systemer er det prioritert å teste disse. Primært funksjonelt, men også med tanke på ytelse. 10

13 Forsinkelse i fremdrift fordi testere (fag) prioriterer andre aktiviteter  Det er alltid en stor risiko hvis en tester har andre (større) oppgaver innenfor samme prosjekt (nøkkelressurs). Enkeltpersoners prioriteringer går normalt utover test.  Dette er en utfordring som må tas opp med prosjektleder generelt. Og med den det gjelder spesielt. (Typisk en unik kjerneressurs i prosjektet.)  Hvis det er slik at de andre aktivitetene ikke tilhører prosjektet betyr det at ressursen ikke leverer det som er forventet til prosjektet.  Normalt sett vil man i slike tilfeller (i en begrenset periode) kunne få mer kapasitet fra avdelingen fagpersonen representerer. Flere ressurser kan jobbe i parallell eller den resursen som må prioritere andre aktiviteter kan erstattes. 11

14 Planlegging av ikke-funksjonelle tester  Siden et medlemsregister inneholder sensitive data bør sikkerhetstester vurderes.  Siden medlemsregisteret integrerer med flere systemer bør det utføres ytelsestester. Det bør gjøres tester på trafikk (mengde) og samtidighet (locking).  Disse testene krever spesiell fagkompetanse.  Først bør behovet kartlegges.  Deretter bør testene planlegges i samarbeid med personer med kompetanse på sikkerhet og ytelse.  Det er ikke alltid at ressurser med kompetanse på ikke-funksjonell test er like tilgjengelige.  Dette kan delvis løses med at disse kun er rådgivende og at utviklere deltar i det praktiske. 12