Testdata: Undgå faldgruberne

Der er mange ting, man som webudvikler ikke lærer på sit studie, men først når man kommer ud i felten, og skal udvikle løsninger til kunder.

Den mest optimale brug af testdata er én af de ting.

For nylig stod jeg i den situation, at jeg skulle overtage og videreudvikle på en kodebase, der var påbegyndt af en anden udvikler. Det i sig selv, kan være en svær proces at skulle igennem, da udviklere jo som bekendt kan have ret forskellige tilgange til arbejdet.

Jeg var dog ganske positivt overrasket over kvaliteten og strukturen af koden. Udvikleren havde virkelig gjort sig umage. Så jeg var helt optimistisk stemt, lige indtil jeg begyndte at oprette mærker, og layoutet faldt fra hinanden, da jeg kom over otte.

#1: Siden skal tilpasse sig indholdet; ikke omvendt

Der er en tendens til at man som udvikler, ønsker størst mulig kontrol over strukturen på en side. Men sandheden er, at det bare ikke altid er muligt.

Brugerne kan finde på hvad som helst, givet muligheden. Hvis de kan ændre farver og skriftstørrelser selv, så kommer du før eller siden til at se regnbuefarvet Comic Sans. Hvis de selv kan oprette varianttyper – så kommer du før eller senere til at se lige så mange varianttyper som der er produkter på en side (også selvom de alle hedder størrelse og gør det samme…) Og hvis de kan give et produkt et navn på 1.000 karakterer, der overlapper alt andet på siden – jamen, så kommer du til at få en vred support ticket fra en frustreret kunde, der ikke kan forstå, at siden ikke bare kan tilpasse sig indholdet.

Og i stedet for at blive irriteret, så bør man indse, at kunden jo faktisk (langt hen ad vejen) har ret. Siden SKAL kunne tilpasse sig til indholdet. Siden er jo ingenting uden indholdet, når alt kommer til alt.

Men hvad betyder det egentlig? Og hvordan kan du få siden til at tilpasse sig indholdet, uden at layoutet falder fra hinanden i de værre tilfælde?

#2: Du ved ikke, hvad du koder til

Du ved ikke, om brugeren opretter otte eller 800 brands. Se lad være med at oprette en struktur i CSS Grid, der tager udgangspunkt i otte, og ikke tager hensyn til resten.

Du ved ikke om produktnavnene pludselig bliver over 1.000 karakterer. Så sørg for, at linjerne enten wrapper, eller blive skåret af med “…” efter X antal karakterer, der er plads til.

Du ved ikke, hvor mange produktbilleder, der bliver uploadet. Så sørg for at der er plads til alle thumbnails – enten med en horisontal slider, eller ved at de kan komme til at stå på flere linjer.

Du ved ikke, hvor mange menupunkter en kunde opretter. Så sørg for, at der er plads til dem. Lav for eksempel en ekstra hamburger menu, der kan opsamle de overskydende menupunkter, der ikke er plads til at have liggende horisontalt.

Listen kan i princippet fortsætte i det uendelige. Pointen er bare, at siden ikke må falde fra hinanden, uanset hvad og hvordan kunden finder på at uploade / kalde ting / strukturere indholdet. Validering af dataen hjælper dig kun et stykke af vejen. Resten skal du tage højde for med layout og design.

#3: Du har ikke set resultatet, før der er “ægte” indhold på siden

Du kan ikke tænke dig til alt i udviklingsfasen. Men kunden skal nok lede dig på rette vej, når der er noget du har overset, eller slet ikke overvejet at man burde teste for.

Du vil lære noget nyt for hver eneste side, du sætter op, og til sidst vil du sidde med et helt lille bibliotek af edge cases og mærkelige datatyper, du klog af skade ved, at du skal tage i betragtning. Men til at starte med, må du acceptere at kunderne kommer til at guide dig – uden at de egentlig selv er klar over, at det er hvad der sker. Fejl er muligheder for at forbedre sig og lære nyt – så accepter, at det er en del af processen.

Et godt råd: Test altid siden igennem igen, efter at den er gået live, og se om der er behov for tilretninger. Det er nemlig først dér, du ved præcis hvilken side, du har at gøre med, og hvad den skal kunne – uagtet at du har siddet og nærstuderet en projektbeskrivelse hidtil. For det er bare ikke det samme som den ægte vare.

Og, som jeg har lagt op til i hele indlægget, så husk på følgende: Test data er IKKE rigtig data. Du skal ikke kode siden op, så den passer til din testdata – for du risikerer at siden kun passer til din testdata.

Siden skal passe til al data, brugeren har mulighed for at oprette. Så lad være med at stirre dig blind på de otte brands, 10 menupunkter og tyve produkter du har at teste med. Det er ikke sandheden om siden. Og hvis du bygger strukturen op omkring dem, så risikerer du, at den ikke kan holde i det virkelige liv.

Er du interesseret i et samarbejde?