Gör två prov som ska stoppas och ett som ska nå fram. Skriv ned var ett riktigt meddelande ska landa, skicka ett test med en unik markör och sök efter samma markör hos mottagaren. Först när både skärmen och mottagningskanalen stämmer har du provat hela kedjan.
Steg 1: bestäm vart meddelandet ska ta vägen
Öppna formuläret som en besökare skulle göra. Skriv ned vilka fält som krävs, vilken adress eller lagringsplats som ska ta emot meddelandet och vem som kan kontrollera den. Det kan vara en inkorg, en tabell i appens databas eller ett ärendesystem. Välj en testadress som du har tillgång till och använd ett ofarligt exempelmeddelande utan personuppgifter. Om ingen kan visa var inskicken hamnar är formuläret inte färdigprovat.
Bestäm också vad besökaren ska få veta efter sändning. ”Tack, ditt meddelande har skickats” är ett starkare löfte än ”Vi försöker skicka ditt meddelande”. Skriv bara den bekräftelse som appens faktiska sändningsflöde kan stödja. Skilj mellan att appen accepterar ett inskick, att ett brev skickas vidare och att en människa har läst det. Det är tre olika händelser.
Om appen skickar e-post och brevet saknas trots att formuläret accepterade testet, använd artikeln om mejl som inte kommer fram för att felsöka själva leveransen. Den här guiden följer hela formuläret, från första fältet till mottagningen.
Steg 2: prova tomma och felaktiga fält
Tryck på Skicka med alla fält tomma. Om namn, e-post eller meddelande är obligatoriska ska du få veta vilka fält som behöver fyllas i. Skriv sedan ett namn och ett meddelande men använd exempelvis fel-adress i e-postfältet. Prova igen. Facit är att formuläret hindrar ett oavsiktligt inskick och ger en begriplig förklaring vid fältet eller i en tydlig felsammanfattning. Ett ensamt rött streck utan text berättar inte vad du ska rätta.
Kontrollera att fältnamn och instruktioner finns kvar när felet visas, och att det du redan skrev inte försvinner i onödan. W3C:s formulärguide beskriver tydliga etiketter och instruktioner. Deras guide till validering visar bland annat obligatoriska fält och e-postformat. Webbläsaren kan göra en del av kontrollen, men W3C påpekar att kontroll i webbläsaren kan kringgås: ett lyckat manuellt prov visar inte att serverns kontroll eller appens säkerhet är färdig.
Anteckna utfallet konkret: ”Tomt formulär stoppades; e-postfältet visade ’Fyll i en e-postadress’; namn och meddelande låg kvar.” Om appen skickar ändå eller rensar alla fält, spara skärmbild och beskriv exakt vilken inmatning som gav felet. Då kan du beställa en rättning som går att prova igen.
Steg 3: skicka ett giltigt test och hitta det
Fyll i alla obligatoriska fält med testuppgifter. Skriv en unik markör i meddelandet, till exempel FORMTEST-2026-09-29-A, och notera klockslaget. Tryck Skicka en gång. Kontrollera först vad appen visar: en bekräftelse ska vara begriplig och stämma med vad som hände, enligt W3C:s råd om återkoppling. En snurrande ikon som blir kvar utan besked är ett underkänt resultat.
Öppna sedan den mottagningskanal du skrev ned i steg 1. Sök efter markören och jämför namn, avsändaradress och meddelandetext med det du skrev. Finns en logg för formulärets sändning, anteckna status där också. Skärmens ”Tack” och en rad i inkorgen eller databasen är två olika observationer; registrera båda. Om formuläret bara visar en bekräftelse men markören saknas, är provet underkänt tills du hittat meddelandet eller förklarat felet.
Om formuläret lagrar inskick i en databas, kontrollera att raden går att öppna i den vy där den ansvariga personen faktiskt arbetar. En post som bara syns i ett verktygs testlogg kan vara svår att hantera i vardagen. Om formuläret skickar e-post, kontrollera även skräppost och vilken adress brevet kommer från. För en större genomgång av appens data och åtkomst, se guiden om data och inloggning.
Steg 4: prova fel och upprepade klick
Gör ett särskilt felprov i en testmiljö där du kan stänga av eller byta mottagning utan att störa riktiga besökare. Om det inte går, be den som bygger appen visa hur ett sändningsfel hanteras och märk det som ännu inte verifierat. När mottagningen misslyckas ska besökaren få ett begripligt felbesked och veta om hen ska försöka igen. Formuläret ska inte samtidigt påstå att meddelandet nått fram. W3C betonar tydliga fel som säger hur användaren kan gå vidare.
Prova också ett snabbt dubbelklick på Skicka med ett nytt testmeddelande. Kontrollera hur många poster eller brev som skapades. Målet är en tydlig hantering av pågående sändning och ett känt utfall: antingen ett mottaget meddelande eller en förklaring om varför fler än ett skapades. Ett dubbelklicksprov kan inte visa hur appen hanterar alla dubbletter eller om den är skyddad mot spam. Testa igen efter en ändring av formuläret eller mottagningsvägen.
Steg 5: skriv en fellogg och prova om
För varje prov räcker en kort rad med inmatning, förväntat utfall, vad skärmen visade och vad du såg hos mottagaren. Skriv till exempel: ”Tomt formulär → stopp och fältförklaring → stoppades men saknade förklaring → underkänt.” Den giltiga raden behöver både bekräftelsen och den upphittade markören. Lägg raderna i din provlista så att du kan köra dem efter nästa ändring.
Be byggverktyget eller utvecklaren rätta ett avgränsat fel i taget. En användbar beställning är: ”När e-postfältet innehåller fel-adress ska formuläret stoppa inskicket, visa vilket fält som behöver rättas och behålla texten i meddelanderutan. Ändra inte mottagningsvägen.” Kör sedan samma underkända prov igen och kontrollera att det giltiga provet fortfarande når fram. Om du ändrar mottagningsvägen gör du om hela kedjan, eftersom en lyckad fältkontroll inte säger något om leveransen.
Tomt och felaktigt formulär stoppas med begripliga besked, ett giltigt test får korrekt bekräftelse och samma unika markör finns hos den avsedda mottagaren. Ett sändningsfel ger ett ärligt felbesked och du vet vad dubbelklick gav i ditt prov. Spara datum och resultat; det här är en kontroll av din app just nu, inte ett löfte om full tillgänglighet, leverans i alla lägen eller spamskydd.
Råden om märkning, validering och återkoppling kontrollerades 29 september 2026 mot W3C WAI: Forms Tutorial, Validating Input och User Notification. Provrutinen är redaktionell och måste utföras på din egen app.