Staging-miljø til webshop: Sådan tester I ændringer sikkert

En opdatering af et modul kan påvirke checkout, en ændring i designet kan gøre det svært at vælge en produktvariant på mobilen, og nye fragtregler kan betyde, at kunderne får vist forkerte leveringsmuligheder.

Selv mindre ændringer kan få betydning for salget, hvis de påvirker en vigtig del af købsrejsen. Derfor er det en fordel at afprøve dem i et staging-miljø, hvor I kan opdage og rette fejl på en separat version af webshoppen, før ændringerne sættes live.

Hvad er et staging-miljø?

Et staging-miljø er en separat testversion af webshoppen, der så vidt muligt afspejler den aktive shops tekniske opsætning og giver jer mulighed for at afprøve funktioner, moduler, designændringer og integrationer, før de bliver tilgængelige for kunderne. Skal I eksempelvis have en ny funktion til valg af levering, kan I kontrollere, om de rigtige fragtmuligheder bliver vist, om priserne stemmer, og om kunden kan gennemføre købet på både mobil og computer.

Opstår der fejl, kan udviklerne undersøge og rette dem, mens den aktive webshop fortsætter med at modtage ordrer. Staging er dog ikke en garanti for, at alle fejl bliver opdaget, så det er vigtigt at teste de relevante situationer og kontrollere ændringerne igen efter livesætning.

Testmiljøet skal ligne den aktive webshop

Når I etablerer og vedligeholder staging-miljøet, bør I tage udgangspunkt i den aktive webshops opsætning og dokumentere eventuelle forskelle i modulversioner, indstillinger og tilknyttede systemer, så I ved, hvad testen dækker.

Et begrænset produktkatalog kan betyde, at I overser fejl, som kun opstår ved bestemte produkttyper eller prisregler, så brug testprodukter og kundetyper, der afspejler de situationer, ændringen skal håndtere. På en B2B-webshop kan det eksempelvis være kunder med individuelle priser, forskellige adgangsrettigheder og særlige leveringsvilkår, mens ændringer på produktsider kan kræve test med varer, der har flere varianter, forskelle på lagerstatus eller mængderabatter.

Undgå, at testen påvirker den daglige drift

Når I gennemfører et prøvekøb på staging, skal det hverken sætte en forsendelse i gang på lageret eller sende en ordrebekræftelse til en kunde. Betaling og integrationer bør derfor bruge testopsætninger, mens mails bliver opsamlet i testmiljøet eller sendt til adresser, I har valgt til formålet.

Har et tilknyttet system ikke sit eget testmiljø, skal I sammen med udvikleren og systemleverandøren finde en måde at teste på, som ikke påvirker driften. Det kan være at afbryde dataoverførslen under testen eller efterligne systemets svar, men så får I ikke afprøvet hele integrationen og skal derfor dokumentere, hvad der mangler, og aftale, hvordan det bliver kontrolleret senere.

Brug testdata med omtanke

Brug som udgangspunkt fiktive eller anonymiserede kundedata. Hvis det er nødvendigt at anvende rigtige personoplysninger, skal I blandt andet afklare behandlingsgrundlaget, begrænse oplysningerne til det nødvendige og fastlægge adgang og sletning. Sikkerheden skal vurderes ud fra risikoen for de personer, oplysningerne vedrører. Databeskyttelsesreglerne gælder også, når oplysningerne bruges til test.

Beskyt adgangen til staging

Testmiljøet bør være adgangsbeskyttet, eksempelvis med et separat login foran hele miljøet, så det ikke ligger som en ekstra offentlig version af webshoppen.

Adgangsbeskyttelse og søgemaskineindstillinger er ikke det samme. Et noindex-tag kan holde tilgængeligt indhold ude af Googles søgeresultater, men forhindrer ikke andre i at besøge siden. En blokering i robots.txt er heller ikke en adgangsbeskyttelse og er ikke tilstrækkelig til at sikre, at en adresse holdes ude af Googles indeks. 

Afprøv nye moduler og designændringer før lancering

Når I installerer et nyt modul eller opdaterer Magento 2, bør I teste, hvordan ændringerne fungerer sammen med webshoppens øvrige funktioner og integrationer. Ændrer I eksempelvis fragtberegningen, kan I gennemføre prøvekøb, hvor I bruger en rabatkode, skifter leveringsadresse eller vælger produkter med særlige fragtvilkår, så I får kontrolleret, at fragtprisen bliver beregnet korrekt i de forskellige situationer.

Ved designændringer kan I på samme måde afprøve, hvordan en ny menu eller en tilpasning af kurven påvirker kundens vej gennem webshoppen, og om vigtig information stadig er synlig på både mobil og computer. Her handler gennemgangen om, hvorvidt kunden kan finde rundt og gennemføre købet, mens spørgsmålet om, hvorvidt designet forbedrer konverteringen, kræver data fra kundernes faktiske brug af webshoppen efter lanceringen.

Opdag fejl i funktioner, der allerede virker

En ændring kan fungere som forventet ét sted og samtidig skabe problemer et andet sted. Hvis I eksempelvis ændrer rabatberegningen, bør I derfor også undersøge, hvordan den fungerer sammen med fragt, kundegrupper og andre tilbud.

Får en B2B-kunde stadig sin aftalte pris? Bliver rabatten beregnet korrekt, når kunden ændrer antallet af produkter i kurven? Og stemmer det samlede beløb i checkout?

Denne kontrol af, om eksisterende funktioner stadig virker efter en ændring, kaldes regressionstest. Aftal med udvikleren, hvilke funktioner der kan blive påvirket, så testen ikke kun omfatter det nye.

Test hele købsrejsen

Tag udgangspunkt i kundens handlinger, når I planlægger testen, gennemgå de relevante trin fra produktsøgning til ordre, og kontrollér også de oplysninger, der sendes videre til andre systemer. 

Brug følgende punkter som udgangspunkt:

• Produktsider: Kontrollér variantvalg, lagerstatus og købsknapper.
• Navigation og søgning: Afprøv menu, søgning og filtre med konkrete produkter.
• Priser og rabatter: Kontrollér priser, rabatkoder, moms og eventuelle kundepriser.
• Fragt og betaling: Afprøv relevante leveringsmuligheder og gennemfør checkout med testbetaling.
• Mobilvisning: Kontrollér navigation, formularer og købsknapper på mindre skærme.
• Integrationer: Kontrollér, at testordrer og oplysninger lander korrekt i de aftalte testsystemer.

Testens omfang bør passe til ændringen, da en tekstrettelse sjældent kræver samme gennemgang som en opdatering af betalingsløsningen. Beskriv samtidig testscenarierne konkret, så en opgave som »test rabat« eksempelvis bliver til et prøvekøb, hvor en testkunde bruger en rabatkode, ændrer antallet af varer og vælger en bestemt leveringsform. Når I beregner det forventede ordrebeløb på forhånd, har I også et konkret beløb at sammenligne resultatet med.

Gør godkendelsen konkret

Inddrag de medarbejdere, der kender webshoppens daglige arbejdsgange, så løsningen bliver vurderet af dem, der skal bruge den i praksis. Den e-commerceansvarlige kan gennemgå købsrejsen, mens kundeservice vurderer, om leveringsinformationen er forståelig, og medarbejdere med ansvar for ordrebehandling kontrollerer, at de nødvendige oplysninger følger med ordren.

Inden testen bør I aftale, hvilke krav ændringen skal opfylde for at blive godkendt, især når den berører priser eller betaling. Hvis en B2B-kunde eksempelvis ændrer antallet af en vare fra ét til tre, skal det fremgå, hvilken kundepris og eventuel mængderabat der gælder, og hvordan fragt og moms indgår i det forventede ordrebeløb.

Dokumentér testscenariet og det forventede og faktiske resultat sammen med den testede version, datoen og den ansvarlige tester, så der er et tydeligt grundlag for godkendelsen. Opstår der fejl, bør beskrivelsen vise, hvilke trin der førte til problemet, gerne suppleret med et skærmbillede. Aftal også, hvem der står for den endelige godkendelse, og sørg for at teste de berørte funktioner igen, hvis der efterfølgende bliver ændret i løsningen, så godkendelsen gælder den version, der bliver sat live.

Fra staging til live kræver et klart deploymentflow

Når den aftalte version er testet og godkendt, skal ændringerne udgives på den aktive webshop gennem en proces, der kaldes deployment. Her skal ansvaret for både godkendelse, udgivelse og efterfølgende kontrol være fordelt på forhånd, ligesom I skal have aftalt, hvordan eventuelle fejl bliver håndteret.

Hos Conversio bruger vi denne arbejdsgang som en del af Managed Magento, hvor opdateringer og ændringer testes på staging, inden de sættes live. Hvordan ændringerne derefter udgives, afhænger af platformen og hostingopsætningen, og for Adobe Commerce på cloud beskriver Adobes dokumentation eksempelvis, hvordan overgangen fra staging til den aktive webshop håndteres.

Bevar den aktive webshops data

Mens I tester, kommer der fortsat nye ordrer, kunder og produktændringer i den aktive webshop. Kopiér derfor ikke hele stagingdatabasen over på den aktive shop ved en almindelig opdatering. Kode, konfiguration og nødvendige databaseændringer skal håndteres, så aktuelle driftsdata ikke bliver overskrevet af testdata eller ældre oplysninger. 

Aftal, hvad der skal ske ved fejl

Inden ændringerne sættes live, bør I sammen med udvikleren aftale, hvordan eventuelle fejl skal håndteres, og sørge for en sikkerhedskopi, der kan bruges ved en gendannelse. Har opdateringen også ændret i databasen, er det ikke nødvendigvis nok at vende tilbage til den tidligere kode, og det skal planen tage højde for. Hvis databasen skal gendannes fra sikkerhedskopien, skal I samtidig have afklaret, hvordan de ordrer og andre oplysninger, der er kommet til siden, bliver bevaret, så de ikke går tabt under gendannelsen.

Kontrollér webshoppen efter livesætning

Gennemgå de vigtigste berørte funktioner, når ændringen er udgivet. Kontrollér også miljøspecifikke indstillinger, fordi betaling og integrationer ikke nødvendigvis er konfigureret ens på staging og den aktive webshop. Aftal også på forhånd, hvordan eventuelle kontrolordrer på den aktive shop skal håndteres, så betaling, lager, bogføring og forsendelse ikke efterlades med utilsigtede ændringer.

Gør staging til en fast del af webshoppens udvikling

Når I bruger staging som en fast del af udviklingen, bør det være tydeligt, hvem der tester og godkender ændringerne, og hvem der kontrollerer webshoppen efter livesætning. Samler I samtidig testscenarier, resultater og godkendelser ét sted, får både I og udviklerne overblik over, hvad der er afprøvet, og hvad der eventuelt mangler, før en ændring er klar til at blive sat live.

Hos Conversio indgår test og kvalitetssikring i vores arbejde med udvikling og opdatering af Magento-webshops, og vi hjælper gerne med at gennemgå jeres nuværende proces. Kontakt os, og få en gennemgang af jeres proces for test og livesætning, så vi sammen kan afklare, hvordan ansvaret fordeles, og hvordan eventuelle fejl håndteres i en arbejdsgang, der passer til jeres webshop.