Produksjons-QA · nettleser
Nettsiden virket – men var fortsatt feil.
Alle knappene fungerte. Innholdet var riktig. Likevel lå den nye App Studio-siden klemt i en 620 piksler bred kolonne på store skjermer. Det er derfor vi tester mer enn funksjoner.
En automatisert test kan bevise at en knapp endrer riktig visning. Den beviser ikke nødvendigvis at siden ser riktig ut. Under publiseringen av App Studio besto interaksjonene, metadataene og de tekniske kontrollene. Produksjonsnettleseren avslørte likevel en tydelig feil på desktop.
Feilen lå utenfor den nye komponenten
App Studio var bygget som en bred arbeidsflate med kontrollpanel og telefonforhåndsvisning ved siden av hverandre. I den isolerte forhåndsvisningen brukte den tilgjengelig bredde. I WordPress-produksjonen arvet siden en begrensning fra temaets innholdsstruktur: den ytterste beholderen stoppet ved omtrent 620 piksler.
Selve App Studio-koden gjorde det den skulle. Problemet oppsto i møtet mellom ny side, WordPress-mal og nettleserens ferdige layout. Det er nettopp slike feil en ren komponenttest lett overser.
Vi hadde sett samme familie av feil før
Noen uker tidligere hadde WordPress automatisk satt inn et tomt avsnitt i en innholdsgrid. Det usynlige elementet tok den brede kolonnen, mens selve artikkelteksten ble presset ned til rundt 220 piksler. Innholdet var der, lenkene virket og serveren svarte 200. Lesbarheten var likevel ødelagt på desktop.
De to feilene hadde forskjellige årsaker, men samme lærdom: serverstatus, tekstkontroll og klikkbare knapper beskriver bare deler av brukeropplevelsen.
Vår minste produksjonsmatrise
- 01
Innhold
Riktig tekst, riktig H1, forventede lenker og ingen kunde- eller testdata i offentlig kilde.
- 02
Funksjon
Knapper, tilstander og navigasjon må gi forventet resultat – også etter cache og ny sidelasting.
- 03
Layout
Faktiske elementbredder, overflyt, lesbarhet og plassering kontrolleres på mobil, nettbrett og desktop.
- 04
Nettleserfeil
Konsollfeil, mislykkede forespørsler og sidefeil må være tomme i den avgrensede reisen.
- 05
Gjenoppretting
Releasekilden, førtilstanden og en eksakt rollback må være tilgjengelig hvis sluttkontrollen feiler.
Hvorfor vi tester etter publisering
En staging-side er nyttig, men den deler ikke alltid samme mal, cache, pluginrekkefølge og URL-adferd som produksjon. Derfor er en grønn forhåndstest bare ett stopp. Etter en kontrollert publisering åpner vi den offentlige adressen i ekte Chromium og kjører den viktigste brukerreisen på nytt.
I App Studio-tilfellet gjorde denne siste kontrollen jobben sin: vi oppdaget breddebegrensningen, oppdaterte den avgrensede stilen og cacheversjonen, og kjørte hele produksjonsmatrisen på nytt før leveransen ble kalt ferdig.
Fire viewport-størrelser kan ikke representere alle telefoner, nettlesere, hjelpeverktøy eller nettverksforhold. De reduserer en kjent risiko og gjør regressjoner synlige. De erstatter ikke målrettet tilgjengelighets-, ytelses- eller enhetstesting når produktet krever det.
«Det virker» må ha et subjekt
Når vi sier at noe virker, bør vi også si for hvem, hvor og under hvilken kontroll. App Studio virket funksjonelt før breddefeilen ble rettet. Etter rettelsen kunne vi i tillegg si at den avgrensede reisen passerte på de fire navngitte visningene uten horisontal overflyt eller nettleserfeil.
Den setningen er litt lengre. Den er også langt mer verdt.
Se sluttresultatet