Hvornår fejlen bliver dyr

Den samme fejl har vidt forskellig pris afhængigt af, hvornår den bliver fundet. Derfor giver løbende test mere end én stor gennemgang dagen før overtagelsen.

I kravspecifikationen

Næsten gratis. En sætning i opgavebeskrivelsen skrives om, før nogen har kodet noget.

Under udviklingen

Lidt dyrere. Udvikleren retter koden, mens den stadig er frisk i hukommelsen.

I testfasen

Mærkbart dyrere. Opgaven sendes retur, og hele runden med review og deploy tages igen.

Efter udgivelsen

Dyrt. Der skal laves en hastrettelse uden for planen, ofte om aftenen.

Hos kunden

Dyrest. Oven i rettelsen kommer tabte ordrer, anmeldelser på Trustpilot og ekstra pres på kundeservice.

Automatisering betaler sig først, når en test er kørt mange gange. Derfor automatiserer vi de stabile flows, som skal virke ved hver release. Skærmbilleder, der designes om hver anden uge, tester vi manuelt - ellers går budgettet til at vedligeholde testene i stedet for produktet.

Sådan forløber en testopgave

I får ikke en generel vurdering af kvaliteten, men konkrete fejlrapporter med prioritet, som en udvikler kan tage fat på med det samme. Alt foregår remote via testmiljø, VPN eller delt adgang.

01

Vi lærer produktet at kende

Vi gennemgår brugerrejser, integrationer og de steder, hvor en fejl rammer omsætningen. Ikke alle skærme fortjener samme opmærksomhed.

02

Testplan og omfang

Vi aftaler scenarier, enheder og browsere ud fra jeres egen trafikstatistik. Planen godkendes af jer og fastlægger timeforbrug og pris.

03

Test og fejlrapporter

Hver fejl oprettes i jeres Jira, Azure DevOps eller GitHub med trin, skærmbillede, forventet resultat og alvorlighed.

04

Gentest

Når rettelsen er klar, tester vi den igen og kigger på naboområderne, så en løsning ét sted ikke har skabt en ny fejl et andet sted.

Spørgsmål og svar

Jo, og det skal de blive ved med. Men en udvikler tjekker, at koden gør det, den er bygget til. En tester leder efter det modsatte: hvad sker der, når brugeren gør noget uventet? De to roller trækker i hver sin retning, og det er svært at se sine egne blinde vinkler.

Ja, det er en af de hyppigste opgaver - typisk lige før overtagelsen fra en leverandør eller som del af et udbud. Vi har ingen interesse i at skjule fejl, så vurderingen er uvildig. Det giver mest mening at teste, før overtagelsesprotokollen underskrives.

Ja. Til offentlige hjemmesider og løsninger omfattet af webtilgængelighedsloven tjekker vi mod WCAG 2.1 AA: tastaturnavigation, kontraster, alternativ tekst og skærmlæser. Resultatet kan bruges som grundlag for jeres tilgængelighedserklæring.

Tre konkrete svar: hvor mange samtidige brugere løsningen klarer uden problemer, hvornår svartiderne begynder at stige, og hvilken del der giver op først - CPU, disk, database eller selve koden. Med de tal kan I vælge mellem at købe mere kapacitet og at optimere.

Vi anbefaler anonymiserede eller syntetiske testdata. Skal vi arbejde med rigtige persondata, indgår vi en databehandleraftale efter GDPR, og data bliver på servere i EU.

Find fejlene, før jeres kunder gør det

Skriv, hvad der skal testes, og hvornår det skal i drift. Vi sender en testplan og et prisoverslag baseret på antallet af flows.

Vi arbejder
I hele Danmark via fjernadgang

Vi bruger kun nødvendige cookies, så siden fungerer og husker den by, du har valgt. Læs mere i vores privatlivspolitik.