Automatiserad testning

Du tror att webbplatsen fungerar, har du bevisat det?

Du har byggt din webbplats. Den ser bra ut i Chrome, den webbläsare du hittills testat i. Allt är på rätt plats. Ändå, hur kan du veta att HTML-koden är giltig? Att en tangentbordsanvändare kan navigera? Att sidan laddas rimligt snabbt?

Magkänslan är subjektiv. Ett testprotokoll är objektivt.

Vi har använt WAVE och Validator.nu hela kursen som enstaka kontroller. Nu gör vi det systematiskt och dokumenterat.

Tre verktyg, tre frågor

Varje verktyg svarar på sin egen fråga om webbplatsen. Tillsammans täcker de det som går att mäta automatiskt.

Validatorn: är koden giltig?

Du känner Validator.nu från HTML-trädet, där den granskade dina första HTML-sidor. Den parsar HTML mot standarden och listar fel och varningar, och samma motor driver W3C:s officiella validator.

Typiska fel att hålla utkik efter:

Saknade avslutningstaggar (</li>, </section>)
Element på fel ställe (<p> inuti <ul> utan <li>)
Ogiltiga attribut (stavfel, uppfunna attributnamn)
Dubbla id-värden (ska vara unika per sida)

En valid HTML-bas är grunden för allt annat. Skärmläsare, sökmotorer och webbläsare tolkar strukturen utifrån den.

Validatorn granskar bara HTML. CSS har en egen: W3C:s CSS-validator. Kursen har inte krävt den, men minns från CSS, selektorer och färg att webbläsare ignorerar ogiltig CSS helt tyst. Misstänker du att en regel aldrig slår igenom är CSS-validatorn ett snabbt sätt att utesluta stavfel.

WAVE: är sidan tillgänglig?

WAVE introducerades i Innehållshierarki & struktur och du har kört tillägget som löpande kontroll genom kursen. Nu när webbplatsen ligger live fungerar för första gången även webbversionen: klistra in din publicerade URL på wave.webaim.org. Målet är noll röda ikoner vid inlämning.

WAVE granskar tillgänglighet: kontrast, aria-attribut, landmärken, formuläretiketter, alt-texter.

Röda ikoner = fel som måste åtgärdas
Gula ikoner = varningar att granska
Gröna ikoner = korrekt implementerat

Lighthouse: är den snabb och välbyggd?

Lighthouse är inbyggt i Chrome DevTools: öppna DevTools och leta reda på fliken Lighthouse. Det är Googles eget testverktyg och används av webbutvecklare världen över för att mäta och förbättra webbplatskvalitet. Lighthouse finns också som webbversion, PageSpeed Insights, om du inte har Chrome.

Fyra kategorier:

Kategori	Vad det mäter
Performance	Laddningstid, bildstorlek, render-blockerande resurser
Accessibility	Alt-texter, kontrast, knappar med namn, form-labels
Best Practices	HTTPS, säkra libraries, console-fel
SEO	Meta-taggar, läsbara URL:er, robots.txt

Kör Lighthouse i inkognitoläge för att göra din testning så neutral som möjligt. Tillägg och cache påverkar annars siffrorna.

Pröva i DevTools: kör en Lighthouse-audit

Öppna din webbplats i ett inkognitofönster.
Tryck F12 och klicka på fliken Lighthouse.
Välj Navigation, ställ in enhet på Mobile, bocka i alla kategorier och klicka på Analyze page load.
Du får ett betyg 1-100 per kategori. Klicka på varje ikon för att se exakt vilka problem som drar ner poängen.

Testprotokoll

Testerna dokumenteras i en fil testprotokoll.md i repot, eller som en sektion i README. Så här ser mallen ut, ifylld med exempelrader:

## Testprotokoll

| Verktyg                  | Testad URL  | Datum      | Fel hittade                             | Åtgärdade | Kvarstående |
| ------------------------ | ----------- | ---------- | --------------------------------------- | --------- | ----------- |
| Validator.nu             | https://... | 2026-05-15 | 3 fel (saknad </li>, dubbel id)         | Ja        | 0           |
| WAVE                     | https://... | 2026-05-15 | 2 röda (kontrast hero, saknad alt)      | Ja        | 0           |
| Lighthouse Accessibility | https://... | 2026-05-15 | Score: 78 (saknad aria-label på toggle) | Ja        | Score: 95   |
| Lighthouse Performance   | https://... | 2026-05-15 | Score: 61 (bilder okomprimerade)        | Delvis    | Score: 74   |

Läs exempelraderna som facit för nivån: verktyg, URL, datum, vad som hittades och vad som hände sedan. “Åtgärdade: Ja” kräver att koden faktiskt är ändrad, inte att du sett felet och ignorerat det. Att “Delvis” och kvarstående poäng får stå kvar är ärlighet, inte misslyckande. I uppgiften kopierar du mallen och fyller i den för din egen webbplats.

Uppgift: Bevisa kvaliteten

Kör ett fullständigt testprotokoll på företagswebbplatsen du byggde och publicerade i Projekt: Företagssida.

Kör Validator.nu, lista alla fel, åtgärda dem, kör igen tills du har 0 fel.
Kör WAVE, lista alla röda ikoner, åtgärda dem.
Kör Lighthouse i inkognitoläge, notera score i alla fyra kategorier.
Kopiera testprotokoll-mallen ovan till en fil testprotokoll.md i ditt repo. Fyll i alla rader.
Åtgärda minst tre fel (inte räknat W3C-felen). Kör om testerna efter åtgärd.
Checka in protokollet med ett semantiskt commit-meddelande.

Målet: validatorn 0 fel, WAVE 0 röda, Lighthouse Accessibility ≥ 90.

Vad händer om…

Åtgärda exakt det WAVE och Lighthouse pekar ut, och inget mer. Stäng sedan av musen och försök navigera din sida med bara tangentbordet. Hittar du problem som inga av verktygen flaggade? Det är skillnaden mellan att klara ett test och att faktiskt vara tillgänglig.

Motivera & reflektera

Skriv en rad i ditt testprotokoll för varje fel du åtgärdade: inte bara vad du ändrade, utan varför felet var ett problem för en verklig besökare. “Lade till alt-text” säger mindre än “en skärmläsaranvändare fick tidigare bara höra filnamnet uppläst”. Det tvingar dig att förstå felet, inte bara tysta verktyget.

Nästa nivå

“Inga röda ikoner” är golvet, inte taket. Sikta högre: noll gula WAVE-varningar också (Alerts, inte bara Errors), och Lighthouse Accessibility på 100, inte 90. Installera dessutom axe DevTools som webbläsartillägg, det hittar problem WAVE missar och är verktyget många proffs faktiskt kör. Varje varning du släcker tvingar dig att förstå ett tillgänglighetskrav på riktigt. Det är den delen av kvalitetsarbetet som skiljer proffsen från resten.