Review er som nævnt en statisk testtype, som gennemgår et dokument eller kode. Dokumenter kan være alt fra kravspecifikation over design- og testdokumenter til skreven kode eller drifts- og brugsvejledninger. Der findes flere typer review, som har forskellige grader af formalisme og forskellige formål.
De uformelle reviews er kendetegnet ved, at de ikke følger en foruddefineret proces og ikke har krav om formelt og dokumenteret output.
Formelle reviews er kendetegnet ved team-deltagelse, dokumenterede resultater af reviewet og dokumentation af processen.
Formål: Finde defekter.
Et uformelt review følger ikke en formel og dokumenteret proces.
Eksempler på oplagte uformelle reviews:
Formål: Finde defekter, evaluere kvaliteten, opbygge tillid til produktet, vidensdele, overveje alternative implementeringer, opnå enighed.
Også en uformel reviewtype, som ledes af ”forfatteren”. Forfatteren kan også være udvikleren, hvis det er kode, som skal reviewes. Forfatteren gennemgår et dokument (eller andet produkt) med en eller flere interessenter. Forfatteren gennemgår produktet og de tanker, der ligger bag. Interessenter/reviewere deltager med deres viden og baggrund, men metoden kræver ikke nødvendigvis forberedelse.
En walkthrough er et møde, der ledes af forfatteren selv og det kan indeholde flere af faserne i et formelt review, hvis det er hensigtsmæssigt. Bl.a. kan man bede en referent deltage i walkthrough'en, så forfatteren kan koncentrere sig om walkthrough-mødet og ikke skal spekulere på at nedfælde kommentarer. Alle beslutninger skriftliggøres.
Eksempler på oplagte walkthrough reviews:
Formål: Finde defekter, evaluere kvaliteten, opbygge tillid til produktet, generere nye idéer, motivere og gøre det muligt for skabere at forbedre fremtidige arbejdsprodukter, overveje alternative implementeringer, opnå enighed
En mere formel reviewtype, som bør bruges ved høj risiko opgaver.
Ved et teknisk review følges en dokumenteret review proces, som også står beskrevet her: Reviewprocessen for det formelle review.
Det er vigtigt at få de rigtige reviewere med og evt. uddele specifikke fokusområder til de enkelte reviewere. Processen ved denne type review er følgende.
Formål: Finde defekter, evaluere kvaliteten, opbygge tillid til produktet, at forhindre lignende defekter i opstå i fremtiden og analyse af rodårsager, at motivere og gøre det muligt for forfattere at forbedre fremtidige arbejdsprodukter og softwareudviklingsprocessen.
Inspektion følger en foruddefineret proces med formelle, dokumenterede outputs, baseret på regler og tjeklister. Metoden er meget struktureret og typisk en gennemgang linje for linje. Langsommelig. Grundig. Denne metode anvendes i høj risiko systemer med kritiske funktioner.
Vi har ikke nogle kendte eksempler i AU IT, hvor inspektion har været et krav.
Typisk eksterne audits, hvor der ses på om vi overholder specifikke standarder. Fx sikkerhedsaudit o.l. Eller processer fx CMMI. Et audit kan initieres udefra, og vil være drevet af specialister. F.eks. medarbejdere i Informationssikkerhed eller Økonomi.