I kravspecifikationen
Næsten gratis. En sætning i opgavebeskrivelsen skrives om, før nogen har kodet noget.
En fejl, som testeren finder tirsdag formiddag, koster en halv times rettelse. Samme fejl opdaget af en kunde midt i Black Friday koster ordrer, supporthenvendelser og tillid. Vi tester for at flytte opdagelsen frem i tiden - ikke for at finde syndebukke i udviklingsteamet.
Hver ydelse svarer på sit eget spørgsmål: virker det, holder det til trykket, kan brugerne finde ud af det, og kan en angriber komme ind?
Vi går de vigtige flows igennem som en rigtig kunde: oprettelse, kurv, betaling med MobilePay eller kort, returnering og ændring af profil. Grænsetilfældene får deres eget kapitel, for det er dér, tingene oftest går i stykker.
Vi simulerer mange samtidige brugere og finder det punkt, hvor svartiderne stiger og fejlene begynder. Det er billigere at kende grænsen i oktober end at møde den på selve kampagnedagen.
De centrale scenarier kører af sig selv i jeres CI-pipeline før hver udgivelse. Det fjerner de gentagne klik og gør det mindre nervepirrende at sende en ny version ud en fredag.
Rigtige testpersoner løser opgaver på deres egne telefoner, mens vi følger med via skærmdeling. Vi ser, hvor de tøver, hvad de ikke kan finde, og hvorfor kurven bliver forladt.
Med skriftlig tilladelse angriber vi løsningen, som en ondsindet part ville: injektion, svage rettigheder, lækager i fejlbeskeder og logfiler, sårbar login. Rapporten kan bruges som dokumentation over for kunder og revisor.
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.
Næsten gratis. En sætning i opgavebeskrivelsen skrives om, før nogen har kodet noget.
Lidt dyrere. Udvikleren retter koden, mens den stadig er frisk i hukommelsen.
Mærkbart dyrere. Opgaven sendes retur, og hele runden med review og deploy tages igen.
Dyrt. Der skal laves en hastrettelse uden for planen, ofte om aftenen.
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.
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.
Vi gennemgår brugerrejser, integrationer og de steder, hvor en fejl rammer omsætningen. Ikke alle skærme fortjener samme opmærksomhed.
Vi aftaler scenarier, enheder og browsere ud fra jeres egen trafikstatistik. Planen godkendes af jer og fastlægger timeforbrug og pris.
Hver fejl oprettes i jeres Jira, Azure DevOps eller GitHub med trin, skærmbillede, forventet resultat og alvorlighed.
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.
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.
Skriv, hvad der skal testes, og hvornår det skal i drift. Vi sender en testplan og et prisoverslag baseret på antallet af flows.
Tak for jeres henvendelse
Den ligger nu hos en af vores konsulenter. I hører fra os inden for arbejdsdagen, og hastesager bliver taget op af en tekniker med det samme.
Byen står ikke på listen. Tjek stavemåden, eller vælg den nærmeste større by.