Automatiseringsstrategi

Repetitiva tester (Regression), kritiska affärsvägar, tester som är svåra att utföra manuellt (t.ex. exakt dataverifiering) och stabila funktioner.

Identifiera orsaken (miljö, race conditions, lokaliserare). Isolera testet. Använd explicita väntetider. Kontrollera exekveringsläge (headless vs headed).

En strategi där testskript läser data från externa källor (CSV, Excel, Databas) istället för att använda hårdkodade värden, vilket gör att samma test kan köras med flera datauppsättningar.

CI (Continuous Integration) integrerar kodändringar ofta i en delad gren med automatisk bygge och tester vid varje integration. Continuous Delivery betyder att koden kan driftsättas automatiskt men en människa godkänner releasen. Continuous Deployment betyder att den driftsätts automatiskt när alla kontroller passerar, utan manuell grind.

Commit, bygge/transpilering, enhetstester, integrationstester, kodkvalitet (lint, täckning), säkerhetsskanning, E2E-tester, driftsättning till staging, smoke-tester, sedan ett manuellt godkännande, driftsättning till produktion och övervakning. Varje steg är en kvalitetsgrind; snabbare och billigare kontroller körs först så att fel upptäcks tidigt.

En modell för att balansera testtyper: många snabba, billiga enhetstester i basen; färre integrationstester i mitten (som testar kommunikation mellan lager som API och databas); och få långsamma, dyra E2E-tester i toppen. Att vända den (mest E2E) ger långsamma, instabila sviter. Den hör ihop med shift-left: fånga buggar så tidigt och billigt som möjligt.

Villkor som koden måste uppfylla för att gå vidare: en lägsta täckningströskel (t.ex. 80%), noll kritiska sårbarheter, noll misslyckade tester och ren linting. De upprätthåller en konsekvent kvalitetsnivå automatiskt och stoppar en dålig ändring innan den når produktion.

Ett flaky-test passerar eller misslyckas oregelbundet utan någon verklig kodändring. Vanliga orsaker: race conditions/timing, beroenden mellan tester, delad data, animationer och nätverksinstabilitet. Lösningar: ersätt fasta sleeps med villkorsbaserade väntningar (waitForSelector, waitForResponse), gör varje test oberoende och mocka instabila externa API:er.

Canary (släpp till en liten andel användare först, bevaka mätvärden och skala sedan upp), blue/green (två identiska miljöer, växla trafik direkt och rulla tillbaka genom att växla åter), feature flags (slå på/av funktioner utan ny driftsättning) och rollback (återgå till föregående version). Smoke-tester körs direkt efter driftsättning för att bekräfta att appen startar.

Ett workflow (en YAML-fil i .github/workflows) körs på triggers (on: push, pull_request, schedule, workflow_dispatch). Det innehåller jobs som körs på en runner (ubuntu-latest), var och en med steps som antingen använder en action (actions/checkout@v4, actions/setup-node@v4) eller kör ett shell-kommando. Jobb kan bero på andra med needs:, köra konfigurationer parallellt med matrix:, cacha beroenden och läsa secrets via ${{ secrets.NAMN }}.

Lägg aldrig autentiseringsuppgifter i kod eller konfigurationsfiler. Lagra dem som maskerade secrets i CI-plattformen (GitHub: Settings -> Secrets) och referera dem vid körning (${{ secrets.NAMN }}). Avgränsa dem per miljö, markera driftsättningssecrets som skyddade och håll dem utanför jobbloggar.

Kör oberoende testtyper som parallella jobb, cacha beroenden (node_modules, webbläsarbinärer) och sharda E2E-körningar över maskiner (t.ex. Playwright --shard=1/4 med en matrix). Kör enhetstester först som en snabb grind, och kör den dyra E2E-fasen först efter att billigare faser passerat.