En softwareleverance er færdig, når den opfylder kriterier, som I og leverandøren har aftalt på forhånd, når den er testet i et miljø, I selv kan betjene, og når den dokumentation, der hører til, er afleveret. Kan leverandøren demonstrere noget, er det et tegn på fremdrift, og den kan stadig være langt fra færdig. Uden fælles kriterier ender godkendelsen i et skøn, og det er der, mange tvister om regninger og forsinkelser begynder. Tre ting løser det: skriftlige kriterier, jeres egen test og et bevidst ja.
Hvorfor “færdig” betyder forskellige ting
For en udvikler betyder færdig ofte, at koden er skrevet og virker på egen maskine. For en projektleder kan det betyde, at den er afleveret til test. For jer betyder det, at kunderne kan bruge den, og at den ikke falder fra hinanden. Når alle tre taler om det samme ord, kommer der overraskelser.
Softwarefolk bruger udtrykket definition of done: en fælles liste over, hvad der altid skal være opfyldt, før en opgave kaldes færdig. Bed om at se leverandørens liste. Findes den ikke, så lav en sammen.
Fælles kriterier for alle opgaver
Følgende er en brugbar grundliste til en lille virksomhed:
- Funktionen gør det, der blev beskrevet, og beskrivelsen er opdateret, hvis noget blev ændret.
- En anden udvikler har gennemgået koden.
- De vigtigste forløb er dækket af automatiske test, og testene kører igennem.
- Funktionen er prøvet i et testmiljø, der ligner det rigtige.
- Den virker på de browsere og enheder, I har aftalt.
- Fejlbeskeder giver mening for en bruger.
- Sikkerhed og rettigheder er overvejet, fx hvem der må se hvad.
- Dokumentation og driftsvejledning er opdateret.
Listen kan se lang ud, men de fleste punkter er vaner frem for ekstra arbejde. Læg den ind i aftalen, se de tekniske krav i udviklingsaftalen.
Ud over den fælles liste skal hver opgave have sine egne kriterier, der beskriver, hvad brugeren skal kunne. Skriv dem konkret: “En bruger kan nulstille sin adgangskode via mail, og linket virker i en time.” Så kan I bagefter svare ja eller nej. Formuleringer som “brugervenlig” eller “hurtig” kan ikke testes, før de er oversat til noget, der kan måles.
Accepttest i jeres eget miljø
En accepttest er den prøve, I som kunde laver for at se, om det leverede svarer til det bestilte. Den skal gennemføres af jer og ikke af den, der byggede løsningen. Lad det være en person, der tænker som en bruger, fx en supportmedarbejder eller stifteren selv.
Få adgang til et testmiljø, altså en kopi af produktet, hvor der kan prøves frit, uden at kunderne mærker det. Det skal I kunne åbne selv, når det passer jer, og det skal indeholde data, der ligner de rigtige. Brug opdigtede data frem for rigtige kundedata. Se også persondata i produktet.
Skriv testen som små forløb:
- Opret en ny kunde og gennemfør et køb.
- Log ind som en bruger med få rettigheder, og se, hvad vedkommende må.
- Prøv at gøre noget forkert, fx at uploade en forkert fil.
- Prøv det samme på en mobil.
- Tjek, at eksisterende funktioner stadig virker.
Det sidste glemmes ofte. Regressionstest kaldes det, når I sikrer jer, at det nye ikke har ødelagt det gamle.
Sig ja bevidst
Hold godkendelsen som en særskilt handling. Læs, hvad aftalen siger om frister. Nogle aftaler betragter en leverance som godkendt, når I har haft den et bestemt antal dage uden at reagere, så reagér skriftligt og til tiden. Betydningen af sådanne vilkår er et spørgsmål til advokat.
Sortér fejl i tre grupper:
- Stopper godkendelsen: funktionen virker ikke, data går tabt, eller der er et sikkerhedsproblem.
- Rettes inden en aftalt dato: tydelige fejl, som kan leves med i en kort periode.
- Bemærkninger og ønsker: ændringer, der ikke var bestilt. Dem tager I som nye opgaver.
Hold især fast i den sidste gruppe. Blander I fejl og nye ønsker sammen, bliver samtalen uklar for begge parter. Omvendt er det også en fair regel, at leverandøren ikke kan kalde en mangel for et nyt ønske.
Giv svaret skriftligt, og skriv punkterne ned. Er leverancen knyttet til betaling, så lad betalingen følge godkendelsen.
Spørgsmål ved den store leverance
Ved en større leverance eller første version skal I se ud over funktionerne. Spørg:
- Kan produktet sættes op igen fra bunden ud fra dokumentationen?
- Findes der sikkerhedskopier, og er de prøvet?
- Hvem får besked, når noget går galt?
- Har vi modtaget kode, adgange og nøgler?
- Hvad er der af kendte fejl, og er de skrevet ned?
Vejen videre fra første version er beskrevet i første version er leveret. Bliver leverancerne ved med at komme for sent eller med for mange fejl, er det et ledelsesspørgsmål, se sådan styrer I en udviklingsleverandør.
Næste skridt er at tage den næste planlagte leverance og skrive kriterierne ned, før arbejdet går i gang. Del dem med leverandøren, og juster dem sammen.
Det skal I lade være med
- At godkende på en demonstration · prøv selv produktet i et miljø, I kan betjene.
- At lade leverandøren teste for jer · den, der byggede det, ser det samme, som blev bygget.
- At blande fejl og nye ønsker · hold dem adskilt, og hold listen skriftlig.
- At lade fristen løbe ud · læs, hvad aftalen siger om tavshed.
Det skal I kræve af den eksterne
- ☐ En fælles liste over, hvornår en opgave er færdig.
- ☐ Kriterier, der kan testes, for hver større leverance.
- ☐ Et testmiljø, som I selv kan åbne.
- ☐ En enkel metode til at sortere fejl.
- ☐ Skriftlig godkendelse med dato og åbne punkter.
Senest gennemgået: november 2026.
Næste skridt
Læs også: De tekniske krav, der skal med i udviklingsaftalen · Sådan følger I fremdriften, når I ikke selv kan læse koden
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
