Kvalitetssikring

Kvalitetssikring er det sæt af praksisser, der har til formål at sikre, at et produkt opfylder sine krav og fungerer korrekt, og omfatter de processer, standarder og aktiviteter, der producerer kvalitet, snarere end kun de aktiviteter, der kontrollerer for mangel på kvalitet. Forskellen fra kvalitetskontrol, som er inspektion af det færdige output, er mere end blot terminologisk: sikring handler om at forebygge defekter, kontrol om at opdage dem.

Den traditionelle ordning, hvor et separat team tester færdigt arbejde i en særskilt fase før udgivelsen, har veldokumenterede svagheder. Fejl findes længe efter, at de blev introduceret, når konteksten er blevet glemt, og omkostningerne ved korrektion er højest. Forsinkelsen mellem skrivning og testning betyder, at udviklere ikke modtager rettidig feedback om deres egne fejlmønstre. Og ansvaret for kvalitet overføres til en gruppe uden kontrol over, hvordan arbejdet blev produceret.

Moderne praksis fordeler ansvaret snarere end at koncentrere det. Udviklere skriver automatiserede tests som en del af udviklingen, kodegennemgang fanger problemer, før de når et miljø, kontinuerlig integration udfører verifikation på hver ændring, og kvalitetsspecialister fokuserer på teststrategi, udforskende test og de områder, som automatisering ikke kan nå. Specialistens rolle bliver at muliggøre og designe verifikation snarere end at udføre det hele.

Testpyramiden beskriver den fornuftige fordeling af automatiseret verifikation. En bred base af enhedstest kører hurtigt og identificerer fejl præcist. Et mindre lag af integrationstests verificerer, at komponenterne fungerer sammen. Et smalt øverste lag af end-to-end-tests udfører komplette rejser gennem det virkelige system. At invertere dette, med stor afhængighed af langsomme og skrøbelige end-to-end-tests, producerer suiter, der tager timer at køre, fejler uforudsigeligt og til sidst ignoreres.

Udforskende testning er fortsat essentiel og undervurderes ofte i automatiseringsfokuserede organisationer. Automatiserede tests verificerer, at den specifikke adfærd stadig fungerer; de kan ikke bemærke, at et flow er forvirrende, at en fejlmeddelelse ikke er nyttig, at en kombination, som ingen har overvejet, producerer nonsens, eller at en ændring har forværret noget på en måde, som ingen påstand dækker. Dygtig manuel undersøgelse finder problemkategorier, som ingen testsuite vil.

Kvalitetsforpligtelser rækker langt ud over funktionel korrekthed. Tilgængelighed, ydeevne under realistiske forhold, sikkerhed, adfærd på de enheder og forbindelser, som målgruppen rent faktisk bruger, og korrekt datahåndtering er alle kvalitetsattributter, og organisationer, der kun verificerer funktionel adfærd, leverer produkter, der fungerer korrekt, men samtidig svigter væsentlige dele af deres målgruppe.

Testdatahåndtering er en uglamourøs begrænsning, der bestemmer, hvor meget af dette der er opnåeligt i praksis. Realistiske data er nødvendige for at finde realistiske defekter, mens produktionsdata ofte ikke kan bruges direkte på grund af privatlivsforpligtelser, og syntetiske data, der er for rene, skjuler præcis de problemer, der er værd at finde. Etablering af en forsyning af repræsentative, kompatible testdata er normalt en forudsætning for meningsfuld verifikation snarere end en detalje.

Det økonomiske argument for forebyggelse er veletableret. Omkostningerne ved at rette en defekt stiger kraftigt med hvor sent den opdages, fra triviel, når den opdages under udviklingen, til betydelig, når den findes i produktionen, hvor den også medfører driftsmæssige og omdømmemæssige omkostninger. Investering i tidligere opdagelse er derfor berettiget alene af omkostningsmæssige årsager, uafhængigt af kundeoplevelsesargumentet.

Fordi kvalitet bestemmes af, hvordan arbejdet produceres, snarere end af, hvad der sker til sidst, hører praksisserne hjemme i leveringen snarere end efter den. I praksis etableres dette inden for produktudvikling som en del af definitionen af ​​færdig, med tilgængeligheds- og oplevelseskriterierne hentet fra UX-revision standarder og præstationstærsklerne fra web ydeevne budgetter, så det, der verificeres, stemmer overens med, hvad produktet rent faktisk skal levere.