Kvalitetssikring er settet med praksiser som er ment å sikre at et produkt oppfyller kravene og fungerer riktig, og omfatter prosessene, standardene og aktivitetene som produserer kvalitet, snarere enn bare aktivitetene som kontrollerer for mangel på kvalitet. Forskjellen fra kvalitetskontroll, som er inspeksjon av ferdig produkt, er mer enn terminologisk: sikring handler om å forhindre feil, kontroll om å oppdage dem.
Den tradisjonelle ordningen, der et separat team tester ferdig arbeid i en distinkt fase før utgivelse, har veldokumenterte svakheter. Feil oppdages lenge etter at de ble introdusert, når konteksten er glemt og kostnadene for korrigering er høyest. Forsinkelsen mellom skriving og testing betyr at utviklere ikke får rettidig tilbakemelding om sine egne feilmønstre. Og ansvaret for kvalitet overføres til en gruppe uten kontroll over hvordan arbeidet ble produsert.
Moderne praksis fordeler ansvaret i stedet for å konsentrere det. Utviklere skriver automatiserte tester som en del av byggingen, kodegjennomgang fanger opp problemer før de når et miljø, kontinuerlig integrasjon kjører verifisering på hver endring, og kvalitetsspesialister fokuserer på teststrategi, utforskende testing og områdene automatisering ikke kan nå. Spesialistens rolle blir å muliggjøre og designe verifisering i stedet for å utføre alt.
Testpyramiden beskriver den fornuftige fordelingen av automatisert verifisering. En bred base av enhetstester kjører raskt og identifiserer feil presist. Et mindre lag med integrasjonstester verifiserer at komponentene fungerer sammen. Et smalt topplag med ende-til-ende-tester utfører komplette reiser gjennom det virkelige systemet. Å invertere dette, med stor avhengighet av langsomme og sprø ende-til-ende-tester, produserer pakker som tar timer å kjøre, feiler uforutsigbart og til slutt ignoreres.
Utforskende testing er fortsatt viktig og blir ofte undervurdert i automatiseringsfokuserte organisasjoner. Automatiserte tester bekrefter at spesifisert atferd fortsatt fungerer; de kan ikke legge merke til at en flyt er forvirrende, at en feilmelding ikke er nyttig, at en kombinasjon ingen har vurdert produserer tull, eller at en endring har gjort noe verre på en måte som ingen påstand dekker. Dyktig manuell undersøkelse finner problemkategorier som ingen testsuite vil.
Kvalitetsforpliktelser strekker seg langt utover funksjonell korrekthet. Tilgjengelighet, ytelse under realistiske forhold, sikkerhet, oppførsel på enhetene og tilkoblingene publikum faktisk bruker, og korrekt datahåndtering er alle kvalitetsegenskaper, og organisasjoner som kun verifiserer funksjonell oppførsel, sender produkter som fungerer riktig, samtidig som de svikter betydelige deler av publikummet.
Håndtering av testdata er en lite glamorøs begrensning som avgjør hvor mye av dette som er oppnåelig i praksis. Realistiske data er nødvendige for å finne realistiske feil, mens produksjonsdata ofte ikke kan brukes direkte på grunn av personvernforpliktelser, og syntetiske data som er for rene skjuler nettopp de problemene som er verdt å finne. Å etablere en forsyning av representative, kompatible testdata er vanligvis en forutsetning for meningsfull verifisering snarere enn en detalj.
Det økonomiske argumentet for forebygging er veletablert. Kostnaden for å rette opp en feil øker kraftig med hvor sent den oppdages, fra triviell når den oppdages under utvikling til betydelig når den oppdages i produksjon, hvor den også medfører driftsmessige og omdømmemessige kostnader. Investering i tidligere oppdagelse er derfor berettiget utelukkende av kostnadsgrunner, uavhengig av kundeopplevelsesargumentet.
Fordi kvalitet bestemmes av hvordan arbeidet produseres, snarere enn hva som skjer til slutt, hører praksisen hjemme i leveransen snarere enn etter den. I praksis etableres dette innenfor produktutvikling som en del av definisjonen av ferdig, med tilgjengelighets- og opplevelseskriteriene hentet fra UX revisjon standarder og ytelsesterskler fra nettytelse budsjetter, slik at det som verifiseres samsvarer med det produktet faktisk skal levere.