Test og kvalitet To gode naboer Børge Brynlund
To gode naboer som egentlig er tre Kvalitetssikring, kvalitetskontroll og testing
Kvalitet I Betydningen Kvalitet er den viktigste faktoren for å avlede langsiktig verdi fra et programvareprodukt. Kontinuerlig fokus på kvalitet kan bidra til å opprettholde evnen til å levere. Begge disse påstandene bygger i seg et behov som må være definert (prioritering vs kost / omfang / tid) Prosjektleveranser er avhengig av kontinuerlig fokus på kvalitet fra et tidlig tidspunkt
Kvalitet I Bevisst forhold For å kunne sette dette i relasjon til prosjektleveranser så er man avhengig av å skille mellom intern og ekstern kvalitet samt ha et bevisst forhold til teknisk gjeld. Ekstern kvalitet kan sees på som kvalitet som oppfattes av brukerne. Intern kvalitet kan sees på som kvalitet i gjennomføring og arkitektur. Teknisk gjeld og trade-off muligheter
Hvordan oppnå kvalitet? Prioriterte og målbare kvalitetsmål danner grunnlaget for et målrettet kontinuerlig fokus på kvalitet gjennom en prosjektleveranse. I denne grensegangen utøver kvalitetsledelse og testledelse sitt samspill Test er et sentralt virkemiddel verifisere i hvilken grad de definerte kvalitetsmålene oppnås muliggjører for å iverksette nødvendige korrigerende tiltak
Forskjellen mellom kvalitetssikring, kvalitetskontroll og testing Forskjellen mellom kvalitetssikring, kvalitetskontroll og testing kan forvirre selv den mest erfarne. Siden alle tre er nødvendig for å effektivt håndtere risikoen for å utvikle og vedlikeholde programvare, er det viktig å forstå forskjellene Hvem som skal være ansvarlig for kvalitetssikring og kvalitetskontroll aktiviteter? Hva er riktig mengde av kvalitetssikring / kvalitetskontroll?
Kvalitetssikring, kvalitetskontroll og testing QA vs QC QC vs Test Prosess Produkt Produkt Proaktiv Reaktiv Proaktiv Rolle Linje Rolle Forebygge feil Finne feil Forebygge feil
Om kvalitetssikring som virkemiddel for å kunne levere kvalitet i et programvareprodukt
Kvalitetssikring Begrepet kvalitetssikring, beskriver prosessen med å håndheve kvalitetskontrollstandarder og arbeider for å forbedre prosessene som brukes i produksjon av løsningen med komponenter, infrastruktur og innhold. Kvalitetssikring skal fungere som en "stemme" for brukere av løsningen, en påminnelse til designere og utviklere at løsningen er beregnet for brukere interne som eksterne. Hva skal kvalitetssikringen oppnå? Selv de beste designede og utviklede løsninger vil ha problemer og feil - sett tydelige forventninger Kostnader i prosent av omsetning 20% 15% 10% 5% «Vi vet ikke hvorfor vi har kvalitetsproblemer» «Må vi virkelig alltid ha kvalitetsproblemer»? «Våre problemer avsløres og løses gjennom våre kvalitetsverktøy» «Forebyggende tiltak er en naturlig del av virksomheten» «Vi vet hvorfor vi ikke har kvalitetsproblemer» 0% Uvisshet Oppvåkning Forståelse Innsikt Visshet
Kvalitetssikring Fokus på prosessforbedringer Nøkkelen til å forstå kvalitetssikring er å forstå vektingen på prosessen Kvalitetssikring fokuserer både på hva som går inn i prosessen, så vel som på selve prosessen med mål om å forbedre kvaliteten på produksjonen ved å forbedre alt "nedstrøms". Problemområder bør fanges opp før de blir reelle slik at kvaliteten forbedres så tidlig som mulig og reduserer problemer "nedstrøms". Kvalitetssikring bør også involveres i brukernes oppfatning av løsningen - ingenting kan erstatte innspill fra brukere.
Kvalitetssikring Fokus på å spore problemer Kvalitetssikring innebærer en tettere involvering i feil, inkludert løsning på feil. Kvalitetssikring fanger opp problemene som oppdages gjennom bruk av test case i kvalitetskontrollen Kvalitetssikring finner også forbedringsområder som kanskje ikke er feil, men heller må sees på som muligheter Kvalitetssikring må også ta en aktiv rolle i selve problemløsningen
Problemer I Viktigheten av problemets betyding Å bestemme betydningen problemene som oppdages er et viktig steg i kvalitetssikringsprosessen. Viktig å skille subjektiv vurdering av betydningen av et problem fra en objektiv observasjon av omfanget og / eller konsekvenser av et problem i forhold til løsningen sin oppbygging eller funksjonalitet. Ulike team og organisasjoner vil ha forskjellige måter å tilnærme prioritering på; Man trenger en enkel og konsekvent modell som kan håndtere et bredt spekter av situasjoner.
Problemer I Alvorlighetsgrad Alvorlighet Alvorlighetsgrad bør reflektere en kvalitativ vurdering av problemets omfang. Hva er omfanget av problemet - hvor mye av løsningen er berørt? Hvilken viktig funksjonalitet er brutt? Hvem bør håndtere alvorlighetsgrad? Kvalitetssikring bør administrere alvorlighetsgrad for loggede problemer. Kvalitetssikring bør også reviewe feil som logges av andre og sjekke for nøyaktighet, gyldighet, reproduserbarhet, og alvorlighetsgrad. Hvis alvorlighetsgrad endres, må det varsles med forklaring som forklarer årsak til endringen.
Problemer I Prioritet Prioritet Det andre trinnet er å bedømme prioritet av problemet. Prioritet beskriver en vurdering av betydningen av et problem Retningslinjer for prioritet Kritisk prioritet: Håndteres umiddelbart. Kritiske elementer bør håndteres først, fordi effektene av et slikt problem struper ned løsningens funksjonalitet og infrastruktur. Høy prioritet: Dette er problemer som er svært viktig, og som er nødvendig å løse raskt. Alle problem som påvirker viktig funksjonalitet er av høy prioritet. Ethvert problem som påvirker løsningens eller virksomhetens renommé utad er av høy prioritet. Moderat og lav prioritet; Moderate problemer kan vanligvis vente til problem av høy og kritisk prioritet er ryddet opp,
Problemer I Ansvar Kvalitetssikring bør ikke prioritere, av to grunner. Prioritet en subjektiv vurdering. Prioritet er et verktøy for å styre utvikling og vedlikehold.
Om kvalitetskontroll som virkemiddel for å kunne levere kvalitet i et programvareprodukt
Kvalitetskontroll
Kvalitetskontroll Testplanen For at kvalitetskontroll skal være effektiv, så må de samme tingene testes på samme måte hver gang du tester. En testplan er rett og slett en god oppsummering av områdene (funksjonalitet, elementer, regioner, etc.) som skal testes, hvor ofte de skal testes, og hvor i utviklings- eller deploy-prosessen de skal testes. De viktigste fasene i utvikling og vedlikehold av løsninger trenger testplaner, fordi fokus og vektlegging av testing vil endre seg over tid. Man må bestemme seg for hva man vil teste. Forstå hensikten med løsningen, målangivelse, forretningsplan det bør eksistere en konkret forklaring på "visjonen" bak etableringen og ønsket «vei" til målet.
Kvalitetskontroll Viktigheten av test cases Mye testing som del av kvalitetskontroll innebærer fokus på et bredt mønster av brukeradferd For områder som for eksempel funksjonalitet, så må man tenke scenarier som beskriver hvordan en bruker vil samhandle med funksjonaliteten. Scenariene brukes til å lage test cases som består av spesifikke trinn som en bruker ville fulgt for å gjennomføre scenariene. Verdien ligger i å kunne gjenta testene om og om og om igjen.
Kvalitetskontroll Vurderinger Ulike løsninger krever ulik tilnærming og dekning. Hva er målene og kravene til din virksomhets løsninger? Kvalitetskontroll kan være vanskelig ofte er testressursene enten begrenset eller overbelastet. Testing og det å bygge test cases er læring. Kvalitetskontrollprosessen kan fort bli reaktiv til problemer. Kvalitetskontroll setter standarder for løsningen og tester kan plasseres under disse standardene, men gjør ingenting for å forbedre kvaliteten de ulike delene av løsningen.
Om test som virkemiddel for å kunne levere kvalitet i et programvareprodukt
To gode naboer I Knyttes test til kvalitet? Kompetansekrevende aktiviteter Testing krever ferdigheter og må forvaltes av erfarne testledere. Testing gjennomført av andre enn fagfolk er mindre effektiv og effektiv testing innebærer en blanding av tekniske-, og test-spesifikke ferdigheter Kompetanse må etterstrebes og kreves på alle områder gjennom hele livssyklusen
To gode naboer I Knyttes test til kvalitet? Kilder og årsakssammenhenger til feil Et programvareprodukt leveres med de fleste av feilene den kommer til å inneholde. Illusjonen av at test knekker programvareprodukter oppstår på grunn av antallet feil som oppdages gjennom testing. Feil innføres i hele livssyklusen, men først og fremst i de tidlige aktivitetene og fjernes ofte sent i livssyklusen. Et høyt antall feil introduseres tidlig i livssyklusen, deretter fjernes feilene (til en mye høyere pris) senere i livssyklusen. Beste praksis er fokus på tidlig fjerning av feil, slik at senere testfaser kan fokusere på å bygge tillit og redusere risiko
To gode naboer I Knyttes test til kvalitet? Målbare gjenkjenninger av feil Testing har en målbar feilgjenkjenning i form av antall feil som oppdages gjennom test- eller kvalitetsaktiviteter og som kan vises som prosentandel av de feilene som finnes
To gode naboer I Knyttes test til kvalitet? Plan, budsjett og kvalitetsavveininger sent i livssyklusen Fjerning av feil i sluttfasen av testingen vs i krav øker unødvendige kostnader. Disse kostnadene representerer dermed nødvendig avveining mellom kvalitet, tidsplan og budsjett ved at feil tillates å flykte fra tidlige faser til senere i livssyklusen
To gode naboer I Knyttes test til kvalitet? Testing integrert i kvalitetsstyringen Alle testaktivitetene i livssyklusen må ha veldefinerte mål for dekning slik at alle testresultater enkelt kan tydeliggjøre faktisk status for produkt Helhetlig tilnærming med klare mål, eier og mål per testnivå