Programvarutestning (QA)

Utvecklare testar vad de byggt, inte vad användare gör

En utvecklare kontrollerar att funktionen fungerar som tänkt. En användare klistrar in ett telefonnummer med mellanslag, trycker tillbaka mitt i betalningen, öppnar sajten på en tre år gammal Android-telefon eller har två flikar öppna samtidigt. Det är de fallen som skapar supportärenden, och de finns sällan i en utvecklares test.

Våra testare går igenom den förväntade vägen först och provar sedan medvetet det oväntade. Varje fel dokumenteras så att en utvecklare kan återskapa det på minuter: enheten, webbläsaren, de exakta stegen, vad som borde ha hänt och vad som hände. En skärmbild eller inspelning bifogas.

Allvarlighetsgrad avgör vad som åtgärdas först

En lång lista över buggar utan prioritering är nästan lika oanvändbar som ingen lista alls. Team fixar de enkla först, och buggen som hindrar folk från att betala väntar bakom en feljusterad ikon. Vi graderar varje bugg efter dess effekt på användare och verksamhet.

Kritiska problem blockerar en central användarresa eller förlorar data. Större problem gör en användarresa svår eller påverkar många användare. Mindre problem är kosmetiska eller sällsynta. Sammanfattningsrapporten avslutas med en tydlig rekommendation: redo att släppas, släpp med kända problem eller inte redo.

För team som släpper ofta behöver samma flöden testas varje gång. Det största paketet automatiserar de viktigaste med Playwright eller Cypress, så de körs vid varje driftsättning och fångar regressioner innan användarna gör det.

• Kritiskt: blockerar betalning, registrering eller annan nyckelresa
• Större: en resa fungerar men är svår, eller många användare påverkas
• Mindre: kosmetiskt eller sällsynt, åtgärdas när det passar
• Lanseringsrekommendation i klarspråk