Erfaring med funksjonell testing i en integrert ALM prosess Forutsetninger for å kunne gjennomføre effektiv test Høy testdekning ved hjelp av regresjonstesting Feilhåndtering gjennom hele livssyklusen Fordeler for hele virksomheten med effektive funksjonelle tester Praktisk eksempel Oslo 08.06.12
Eiere Norsk Byggtjeneste er et kommersielt drevet AS som eies av industri og handel BGF 34% Virke 16% BVI 40% 50% Byggevareindustriens Forening (BVI) Bygningsartikel-Grossisternes Forening s Fond (BGF) Virke (Tidl. HSH Byggevare, TBF Trelast- og Byggevarehandelens Fellesorganisasjon)
Gevinster med EDI? Reduserer kostnader (mindre manuelle prosesser) Bedre arbeidsprosesser Visjon Økt presisjon (feil ved manuell registrering) Norsk Byggtjeneste AS skal være Norges klart ledende aktør innen produktbasert og Tettere kunde/leverandørforhold kunnskapsbasert informasjonsformidling og Krav fra kunder og samarbeidspartnere tilhørende tjenester i byggenæringen Ingen kostnader til porto, pakking, konvolutter og fakturagebyr Oppleves som profesjonell samarbeidspartner
Forretningsidé Norsk Byggtjeneste AS skal formidle produktbasert og kunnskapsbasert informasjon mellom aktører i byggenæringen og til bygginteresserte, samt yte relaterte tjenester som bidrar til verdiskapning både for kunder og selskapet
Forutsetninger for å kunne gjennomføre effektiv test - 1 Brukbare krav og testbare testcases Kravene (Requirements) skrives av Byggtjeneste sammen med prosjektleder på utviklersiden Kravene (Requirements) er ofte funksjonelle testcases med input testdata som kan byttes ut etter behov for å kjøre de samme testene med ulike datasett De funksjonelle testcasene er enkle og tydelige slik at alle parter som er involvert i test og utvikling har lik forståelse av kravene
Forutsetninger for å kunne gjennomføre effektiv test - 2 Vedlikehold av krav og testcases Ny funksjonalitet beskrives alltid av en user story eller en change request Alle change requests er alltid knyttet til en user story Testcases må oppdateres etter behov der en ny change request reintroduserer en user story til pågående utvikling Bugs er knyttet til User stories for traceability
Høy testdekning ved hjelp av regresjonstesting Forhåndsutvalgte testcases kjøres for regresjonstesting " For regresjonstestingen finnes det ferdige testsuiter for hver enkelt user story (et område består av 1 user story) " Testene er allerede skrevet " Testene er valgt ut basert på erfaring i forhold til der det er høyest sannsynlighet for å finne feil samt der eventuelle feil gjør mest skade. Mye tid og ressurser spares " Fokuset er på å lage gode testcases for den nye funksjonaliteten slik at testdekningen opprettholdes. " De nye kan testene etter release også legges til en testsuite for fremtidig regresjonstest
Feilhåndtering gjennom hele livssyklusen Bugs som finnes i utviklingsfasen " fikses og følges opp ved re testing frem til de er løst " Dersom det finnes bugs utenom funksjonell test opprettes det en ny testcase eller en eksisterende testcase utvides for å dekke opp bugen " Dersom bugen er kosmetisk kan den fikses og deretter closes ved udokumentert test ( uten å kjøre en testcase) Bugs som finnes etter release " Det spesielt kritisk å regresjonsteste områder som påvirkes av en evt endring bugfixingen påvirker " Ved hjelp av allerede etablerte tester kan en bugfix ofte testes ved å kun kjøre regresjonstester som allerede finnes tilgjengelig I ALM systemet.
Vedlagt screenshot fra step 2 Bug funnet - eksempel
Fordeler for hele virksomheten med effektive funksjonelle tester Integrasjonstesting med end to end tester " Dette er testcases som raskt og effektivt finner bugs fordi de ofte er kjørt flere ganger og forbedret over tid. " End to end testcasene er ofte uavhengige av endringer i funksjonalitet fordi de kun fokuserer på å kontrollere output data som ikke endres selv om noe funksjonalitet endres. Når de funksjonelle testene er skrevet bra " Testeren vil forstå hva som skal testes og beskrive bugen godt. " utvikleren vil forstå hva som er feil og rette bugen effektivt. Fordeler for virksomheten " Bugs funnet i produksjon som ikke har blitt regresjonstestet med integrasjonstester har ofte gitt betydelige følgefeil " Brukerne har blitt skadelidende " supportavdelingen og andre må bruke ressurser på misfornøyde kunder som ofte er helt unødvendig
Praktisk eksempel - Case En endring av funksjonalitet for pålogging til www.nobb.no (Portal for byggevaredata) " Brukere kan logge seg på med ulike profiler " Ulike profiler har ulike rettigheter. a)se alle data med alle priser, b)se kun egne priser, c)ikke se priser. " Endringen burde i utgangspunktet ikke ha påvirkning på rettighetene men det kjøres likevel regresjonstester på rettigheter
Praktisk eksempel ny funksjonalitet
Praktisk eksempel - regresjonstest
Det var det hele Les mer om Byggtjeneste på våre hjemmesider: www.byggtjeneste.no www.nobb.no Oslo 08.06.12