Guide til softwarekvalitetssikring

Kvalitetssikring

Kvalitetssikring (almindeligvis kendt som QA) er det middel, hvormed et produkt under udvikling kontrolleres for at sikre, at det fungerer, som det skal. De faktiske metoder, der anvendes i QA-processer, varierer meget afhængigt af produktets størrelse og art.

For et personligt projekt vil du sandsynligvis bare teste, mens du går, og bede andre om at give feedback på passende stadier. Derimod skal en bankapplikation have alle aspekter af hver funktion udtømmende kontrolleret og dokumenteret for at sikre, at den er både funktionel og sikker.

Uanset hvor formel eller detaljeret en QA-proces er, er dens mål at identificere fejl, så de kan løses, inden produktet frigives.

Metoder

Adræt

I en agil tilgang til udvikling er målet, at hver arbejdscyklus ('sprint') producerer arbejdssoftware, der kan føjes til og forbedres iterativt. Dette gør QA-processerne til en iboende del af udviklingscyklussen.

Ved at teste softwarekomponenter på hvert trin i deres produktion reducerer du risikoen for, at der er fejl ved frigivelsen.

Terminologi

Automatiseringstest

Test udført med foruddefinerede scripts designet til at kontrollere udførelsen af ​​test.

Sort kasse

Disse test ser ikke ind i systemet under test, men behandler det som 'lukket' på samme måde som slutbrugeren vil opleve det.

Defekt

Enhver afvigelse fra applikationens specifikationer ofte omtalt som en “bug”.

Undersøgende test

En uskrevet tilgang til test, der er afhængig af testers unikke kreativitet i et forsøg på at finde ukendte bugs og identificere regressioner.

Integrationstest

Test af individuelle komponenter / moduler sammen for at sikre, at de forbinder og interagerer godt med hinanden.

Test af negativ sti

Et testscenarie designet til at producere en fejltilstand i en funktion / applikation og kontrollere, at fejlen håndteres yndefuldt. Et eksempel på dette er at indtaste en række numre i e-mail-feltet i en brugerregistreringsformular og kontrollere for at sikre, at registreringen ikke accepteres, før der er angivet en egentlig e-mail-adresse.

Regressionstest

Test udført på en ny build for at sikre, at ny funktionalitet ikke utilsigtet har brudt tidligere testet funktionalitet.

Røgtest

En minimalistisk tilgang til test, der skal sikre grundlæggende funktionalitet, fungerer, før der foretages mere dybtgående test. Opstår typisk i begyndelsen af ​​testprocessen.

Test sag

Specificerede forudsætninger, trin og forventede resultater, der henvises til af en QA-tester / ingeniør for at bestemme, om en funktion udfører sin opgave som forventet.

Hvid kasse

Henviser til tests udført på et strukturelt niveau inden for kodebasen. Programmører, der kontrollerer, at indgange til og udgange fra specifikke funktioner eller komponenter er test af hvidboks.

Også kendt som 'Glass Box', 'Clear Box', 'Transparent Box', fordi testeren kan 'se inde' i det testede system.

Hovedkategorier er

  • Enhedstest (individuelle kodeenheder gør, hvad de skal)
  • Integrationstest (enheder / komponenter interagerer korrekt med hinanden)
  • Regressionstest (genanvendelse af test på senere udviklingsstadier for at sikre, at de stadig fungerer)

Der er tre hovedteknikker:

  • Ækvivalenspartitionering (de testede inputværdier er repræsentative for større inputdatasæt)
  • Grænseværdianalyse (systemet testes med valgte input, hvor adfærd og derfor output skal ændres)
  • Årsag-effekt grafning (test er designet ud fra en visualisering af input-output relationer)

Andre ressourcer

  • Sådan skriver du QA-dokumentation, der rent faktisk fungerer
  • Testdrevet udvikling
  • Enhedstest