Godkend den version, der faktisk skal lanceres

En lancering skal vurderes på den færdige version og de funktioner, der bliver taget i brug. Notér hvilken version, hvilket miljø og hvilke sider der er testet. En tidligere godkendelse af designet dækker ikke automatisk efterfølgende ændringer i kode eller indhold.

Jeg anbefaler en tjekliste med kontrolpunkt, ansvarlig, resultat og eventuel åben fejl. Et punkt skal kun stå som godkendt, når det er undersøgt. “Forventes at virke” og “ikke testet” er nyttige statusser, men de er ikke det samme som bestået.

Lav en testoversigt, du kan bruge ved overdragelsen

Omsæt projektets krav til handlinger, der kan gentages. Notér sidens adresse, dato, den testede version og hvem der har kontrolleret resultatet. Denne oversigt er et eksempel til en firmaside med en kontaktformular. Tilpas den til de funktioner, du faktisk har bestilt.

Opgave Sådan kontrollerer du den Gem som dokumentation
Find en ydelse på mobil Start på forsiden, åbn menuen, og gå til ydelsen og kontaktmuligheden De besøgte adresser og eventuelle forhindringer
Send en forespørgsel Brug aftalte testoplysninger. Kontrollér både kvittering og modtagelse hos den ansvarlige Tidspunkt og bekræftelse fra modtageren
Ret en ydelsestekst Lad den kommende redaktør ændre en aftalt tekst i testmiljøet og se resultatet Hvad redaktøren kunne gøre, og hvor der mangler hjælp
Besøg en tidligere adresse Åbn en relevant gammel URL, og kontrollér den aftalte destination Gammel adresse, endelig adresse og resultat
Kontroller den publicerede side Gentag de vigtigste forløb på det offentlige domæne efter lancering Tidspunkt, resultat og ansvarlig for eventuelle fejl

Skriv et konkret restpunkt, hvis noget fejler: hvilken side, hvilken handling og hvad der skete. Fordel ansvar og aftal, om fejlen skal løses før lancering. En kvittering på skærmen dokumenterer eksempelvis ikke i sig selv, at en forespørgsel er nået frem.

Er du stadig ved at bestille siden, kan du bruge min projektbeskrivelse til en ny hjemmeside. Den hjælper med at afklare, hvilke sider, funktioner og redigeringsmuligheder der senere skal testes.

Indhold og tilbud

Kontrollér virksomhedsnavn, kontaktoplysninger, åbningstider, priser og hvad kunden får. Fjern ufærdige pladsholdere, og få en ansvarlig til at godkende faktuelle oplysninger og juridiske tekster. Cases og citater skal bygge på materiale, virksomheden må bruge.

Gennemgå hovedsider og de sider, som repræsenterer forskellige skabeloner. Kontrollér overskrifter, knapper, billeder, alt-tekster og sprog. En korrekt forside er ikke bevis på, at alle produktsider eller artikler er klar.

Navigation og centrale forløb

Test menu, interne links og tilbageveje på mobil og desktop. En besøgende skal kunne finde tilbud, dokumentation og kontakt uden at kende sidens opbygning på forhånd.

Gennemfør formularer og eventuelle køb eller bookinger under aftalte testforhold. Kontrollér validering, fejlbeskeder, kvittering og den efterfølgende modtagelse i det rigtige system. Undersøg også, hvad der sker ved et afbrudt eller mislykket forsøg. Brug ikke rigtige betalinger eller kundedata uden en særskilt aftale om testen.

SEO og gamle adresser

Hvis siden erstatter en eksisterende hjemmeside, skal de tidligere adresser være kortlagt. Kontrollér relevante redirects, de endelige destinationer og opdaterede interne links. Brug et redirect map som dokumentation.

Gennemgå titler, beskrivelser, canonical, sitemap og regler for crawling og indeksering. En adgangsbegrænsning til et testmiljø må ikke utilsigtet blokere den publicerede hjemmeside. Omvendt skal et privat testmiljø ikke blive offentligt tilgængeligt som en følge af en upræcis opsætning.

Se SEO-migrering for den samlede flytning og SEO-analyse for den tekniske prioritering.

Tilgængelighed og responsivt layout

W3C's indledende tilgængelighedskontrol omfatter blandt andet sidetitler, overskrifter, alternative tekster, kontrast, tastaturadgang og formularer. Den er et udgangspunkt og ikke en fuld tilgængelighedsvurdering. W3C Easy Checks.

Kontrollér synlig tastaturfokus, åbning og lukning af menuer og forståelige fejlbeskeder. Se efter tekst, der skæres af, vandret scrolling og knapper, som bliver dækket af faste elementer. Brug flere skærmstørrelser og de relevante moderne browsere; én mobilvisning er ikke fuld dækning.

Performance, måling og samtykke

Test repræsentative sider på den version, der skal publiceres. En udviklingsserver og en produktionsside kan opføre sig forskelligt. Se Core Web Vitals for forskellen mellem laboratorietest og faktiske brugerdata.

Kontrollér de aftalte analysehændelser og samtykkevalg. En måling skal hverken tælles flere gange eller markeres som vellykket, hvis handlingen fejlede. Beskriv databegrænsningerne i overdragelsen, så de første rapporter ikke bygger på falsk sikkerhed.

Drift og gendannelse

Aftal, hvem der lancerer, hvem der kontrollerer resultatet, og hvem der kan beslutte en gendannelse. Sørg for adgang til den tidligere version og de nødvendige data, og afklar konsekvenserne, hvis nye bestillinger eller ændringer er kommet til efter lanceringen.

Kontrollér den aktive side igen efter publicering. Forbindelser, domæne og eksterne systemer skal vurderes i den faktiske drift. Gem en liste over eventuelle restpunkter med ejer og frist.

Jeg hjælper med hjemmesideudvikling, hvor søgeordsanalyse, implementering og overdragelse kan planlægges som et sammenhængende forløb.

FAQ

Er en bestået byggekontrol nok til at lancere?

Nej. Den viser ikke alene, at tekster, eksterne systemer, formularmodtagelse og alle brugerforløb er korrekte.

Hvem skal godkende hjemmesiden?

Aftal ansvar for indhold, funktioner og den endelige lancering. Den tekniske og den forretningsmæssige godkendelse kan kræve forskellige personer.

Hvornår kan testen afsluttes?

Når de aftalte krav er verificeret på den relevante version, og eventuelle restpunkter er tydeligt accepteret og fordelt. Ukendte forhold bør ikke markeres som bestået.