Hvordan kvalitetssikring kan forbedre konverteringsraten inden for e-handel med mode

Arrangement af Digital Fashion Academy
April 18th 2023

Se webinaret her:

OVERSIGT

AFSNIT: Kvalitetssikring til forbedring af konverteringsraten inden for mode e-handel
DATO: Tirsdag den 18. april kl. 17.30 (CET ROM)
VARIGHED: 1 time
SPROG: Engelsk
REGISTRERWebinaret er gratis ved tilmelding

RESUMÉ

Deltag i Enrico Fantaguzzi (Digital Fashion Academy) og Lorenzo Fanetti (Ugæt) når de præsenterer bedste praksis forum kvalitetskontrol of e-commerce websteder inden for mode- og luksussektoren.

Webinaret vil illustrere Nøglekoncepter til kvalitetssikringskontrol i e-commerce projekter, fra standard Processer bruges i store virksomheder, til Aftaler om serviceniveau (SLA), der skal deles med udviklingsagenturer under fastlæggelsen af ​​kontrakter.

• Kvalitetssikring er det sæt af aktiviteter, der har til formål at sikre, at resultater af et projekt mødes forventninger af kunde, slutbrugere af produktet og evt. standarder krævet af regler.

• På mode e-commerceKvalitetssikring er afgørende både for garanti succes med hensyn til webstedet Konvertering sats og at kontrol projekt omkostninger.

"Ofte sker der noget i slutningen af ​​en e-commerce byggepladsudviklingsprojekt, er, at der findes adskillige mangler, der risikerer at underminere projektets succes og forholdet mellem udviklere og kunder. Den korrekte management Kvalitetssikring er det, der giver os mulighed for at opnå kundetilfredshed, den bedste brugeroplevelse og korrekte management af kunde-leverandørforholdet"

Enrico Fantaguzzi

EMNER

• Definition af kvalitetsstandarderne for e-commerce websted
• Produktgaranti efter levering
• Produkttestmetode og fejlløsning management
• Værktøjer til fejlsporing og problemsporing

udskrift

Før jeg startede denne e-læringsvirksomhed, arbejdede jeg i mere end 20 år i mode- og luksusvirksomheder, fra små brandtil store multinationale virksomheder og e-handelsvirksomheder.

I dette webinar vil jeg dele nogle af de ting, jeg lærte i løbet af min tid med modebranchen, med jer. brands, selvom den erfaring, jeg deler med jer i dag, hovedsageligt blev opnået uden for modebranchen, i den digitale underholdningssektor.

Så i dag skal vi tale om vigtigheden af ​​kvalitetssikring og hvorfor det er afgørende for succesen af mode ecommerce. 

Jeg vil præsentere dig for nogle ideer og eksempler på hvordan man organiserer kvalitetssikringsprocesser i sin virksomhed 

Og til sidst vil vi dække nogle af de ting, du skal huske på, når du Diskuter opgaver med dine leverandørers udviklere eller systemintegratorer, hvad du skal spørge dem om under forhandlingerne, og hvad du skal inkludere i kontrakten, så det endelige resultat lever op til dine forventninger. 

Så hvad er formålet med kvalitetssikring inden for mode? e-commerce? 

Hvad er formålet med kvalitetssikring?

Formålet med kvalitetssikring er at sikre, at det digitale produkt lever op til kundens – dine egne – og de endelige brugeres forventninger af det digitale produkt, som er dine kunder. 

Enrico Fantaguzzi

For at være mere specifik Når vi taler om forventninger, taler vi om krav og specifikationer, krav og specifikationer er forskellige fra forventningerne, fordi de er klart angivet og dokumenteret i et eller flere dokumenter. 

Derudover skal du muligvis overholde krav, der er bindende for din virksomhed på grund af juridiske begrænsninger.

For det tredje er der et sæt forventninger, som ikke er nedskrevne, men du skal stadig overveje dem som en del af dit projekt, fordi nogle af disse forventninger kan være dine forventninger management eller bestyrelsen eller andre interessenter på en eller anden måde involveret i projektet. 

Hvad er kravene, og hvad er specifikationer?

Lad os nu prøve at definere bedre, hvad krav og specifikationer er. Disse er tekniske termer, som nogle af jer måske kender, men jeg vil give jer nogle eksempler, så I kan huske dem igen og igen.

Eksempler på krav: 

• Mulighed for at oprette en konto, 
• Mulighed for at tjekke ud som gæst, 
• Mulighed for at betale i rater i stedet for én enkelt transaktion, 
• Mulighed for at vælge mellem forskellige forsendelsesmuligheder, 
• Mulighed for kun at filtrere bestemte størrelser under søgningen, 
• Mulighed for at søge efter nøgleord med et søgeværktøj
• Synlighed af forsendelsesomkostninger og skatter under kassen

Eksempler på specifikationer: 

• Kompatibilitet med enheder og operativsystemer 
• Størrelser på billeder, bannere 
• Frekvensdataudveksling mellem systemer
• Formatet og antallet af resultater pr. side

Hvor er kravspecifikationer og forventninger angivet?

Disse elementer er normalt skrevet ind i et eller flere projektdokumenter. 

Det mest anvendte dokument er Produktkravsdokument, også kaldet PRD, som normalt ejes og skrives af den leder, der er ansvarlig for e-commerce platform. Hvis dokumentet med produktkrav ikke er tilgængeligt Vi kan skrive krav og specifikationer direkte ind i projektplanenendelig kan vi også finde en del af kvalitetsspecifikationer og -krav i Kvalitetsplan. 

Kvalitetsplanen tjener primært formålet med at organisere kvalitetstests og kvalitetssikringsprocessen generelt, men den kan også indeholde specifikke krav til kvaliteten af ​​det digitale produkt. For eksempel kan kvalitetsplanen henvise til specifikke sikkerhedstests, der skal udføres. For eksempel da jeg arbejdede som serviceleverandør for en stor sportstøjsvirksomhed brand og jeg udviklede deres ecommerce hjemmeside, måtte jeg koordinere sikkerhedstestene på vores servere for at opfylde kundens sikkerhedsstandarder. 

Test uden for omfanget

På den anden side kan kvalitetsplanen angive, hvilke tests der ikke er omfattet af projektet. For eksempel hvis du ikke planlægger at sende til Australien med din ecommerce, bør du ikke bruge tid og energi på at udvikle og teste specifikationer for det specifikke land. 

Wireframes og kompositioner

Kvalitetsplanen kan henvise til andre dokumenter for specifikationer og krav. For eksempel kan kvalitetsplanen henvise til wireframes eller comps-mockups for alt, der er relateret til designkvaliteten og webstedets udseende og funktionalitet generelt.

Disse dokumenter er vigtige, fordi de vil blive brugt af dine udviklere som reference for, hvad de skal udvikle og opnå i deres arbejde. 

Udover kravene beskriver kvalitetsplanen de test, der skal udføres, hvornår de skal udføres under projektet og under leveringen af ​​produktet, og hvordan de skal udføres.

GO-LIVE-kriterier

Kvalitetsplanen bør også indeholde GO-LIVE-kriterierne. GO LIVE-kriterierne er et sæt betingelser, der skal være opfyldt for at gå live med projektet, og eksempler på GO LIVE-kriterier er det maksimale antal tilladte fejl på Live-webstedet og deres alvorlighedsgradFor eksempel kan kvalitetsplanen angive, at projektet kun går live, hvis der er et maksimalt antal på 10 fejl i alt på hjemmesiden på det tidspunkt, hvor den går live.

Endelig indeholder kvalitetsplanen de procedurer, som projektteamet skal følge under kvalitetssikringsprocessen, for eksempel hvem der er ansvarlig for testning og hvad, hvordan man bruger fejlsporingsværktøjet, og hvordan man klassificerer fejlene i henhold til deres alvorlighed.

Hvilke typer test skal vi køre?

Typer af kvalitetssikringstest

Lad os nu se nærmere på, hvilke tests der skal udarbejdes brands focus on

Der findes flere typer tests, som modevirksomheder kan køre for at sikre, at handelsplatformen fungerer i henhold til forventningerne.

Røgtest

Røgtest er en simpel test, der sigter mod at kontrollere kernefunktionerne af det digitale produkt. Disse tests udføres normalt af udviklere under projektet for at sikre, at softwarens kernefunktionalitet fungerer. Det er en simpel test, der består i at afprøve et programs kernefunktioner. simulering af en almindelig bruger eller potentiel klient, der skal udføre en opgave på platformenFor at give dig et eksempel, hvis du implementerer en tekstsøgningsfunktion på dit websted, ville røgtesten være at indtaste et par nøgleord, der er relevante for dit brand f.eks. "rød lædertaske" og tjek om resultatet er ensartet. I denne fase er det grafiske design f.eks. måske ikke relevant, målet er at få ensartede resultater. Hvis du søger efter rød lædertaske og får en blå t-shirt som følge heraf, er røgtesten mislykkedes.    

Integrationstest

Integrationstesten er en specifik test til verificere korrekt dataoverførsel fra ét system til et andetFor eksempel fra e-handelsplatformen til virksomhedens ERP, og fra ERP'en til lageret management System eller fra The ecommerce-platform til Business Intelligence-platformen. Vi kan betragte denne test som vellykket, hvis dataene overføres korrekt fra ét system til et andet, uden datatab og inden for den forventede tidsramme. 

Brugeracceptanstest

Brugeracceptanstesten, eller UAT, udføres normalt sammen med klientens og udviklerens tilstedeværelse. 

Under UAT'en kører klienten alle mulige use cases, f.eks. søge efter et produkt, tilføje et produkt til ønskelisten, flytte et produkt fra ønskelisten til indkøbskurven, fuldføre kassen for at sikre, at alt fungerer som forventet. 

Disse tests udføres normalt nær slutningen af ​​udviklingsfasen, når produktet næsten er klar til at blive leveret til klienten. Normalt er outputtet af disse tests en liste over fejl, som klienten har anmodet om, og som udvikleren vil rette.

Regressionstest

Den fjerde testtype er regressionstest. Regressionstest sikrer, at en applikation stadig fungerer som forventet efter eventuelle kodeændringer, opdateringer eller udgivelser af andre funktioner på platformen. Regression sikrer platformens samlede stabilitet.

Disse tests bør udføres af kvalitetsteamet, hver gang der er en ny udgivelse på hjemmesiden., for at sikre, at alle de funktioner, der tidligere fungerede, stadig fungerer korrekt. 

Hvis du for eksempel udvikler et nyt betalingssystem, lad os sige, at du udvikler "Betal i rater" i din kasse, og under implementeringen af ​​denne nye funktion afbryder du kreditkortbetalingerne, der tidligere fungerede fint. Derfor har vi introduceret en fejl i en tidligere fungerende funktion. I dette tilfælde taler vi om regression.

Fejltestning og fejlretningsprocesser

 Vi talte om rollen som kvalitetssikringslederen, og lad os nu se på, hvordan alle aktører involveret i kvalitetssikringsprocessen interagerer med hinanden.

Det første trin sker, når en fejl opdages; testeren, enten et medlem af projektteamet eller en professionel tester, der følger et testscript, finder en fejl. For eksempel kunne testscriptet sige: tilføj et produkt til ønskelisten, og flyt derefter produktet fra ønskelisten til indkøbskurven. 

Hvis testeren ikke kan tilføje et produkt til ønskelisten eller flytte produktet fra ønskelisten til indkøbskurven, vil testeren rapportere en fejl, og vedkommende vil oprette en sag i fejlregistreringsværktøjet. Når en tester rapporterer en fejl i systemet, bør vedkommende også tilføje nogle specifikationer, såsom instruktioner til at reproducere fejlen., dette vil hjælpe udvikleren med hurtigt at reproducere forholdene, da fejlen blev fundet. Testeren vil generelt også rapportere, hvilken enhed og hvilket operativsystem der var i brug, da fejlen blev fundet. For eksempel brugte jeg Safari på iPad Pro.

I det andet trin, den QA-lederen vil kontrollere alle tilgængelige oplysninger om fejlen, og han eller hun vil dobbelttjekke, at fejlen ikke er blevet rapporteret endnu.Dette er vigtigt, ellers kan vi have duplikerede fejl i fejlsporingsværktøjet.

QA-lederen vil derefter tildele fejlen til et teammedlem, der skal arbejde på problemet. Bemærk venligst, at jeg bruger fejl og problem som synonymer i øjeblikket.

I trin 3 løser udvikleren problemet i udviklingsmiljøet og markerer problemet som løst. 

Bemærk venligst, at udvikleren markerer fejlen som Rettet eller Løst, men at han/hun ikke lukker sagen i fejlsporingsværktøjet. Kun den person, der rapporterede fejlen, eller QA-lederen bør markere problemet som lukket.

I det sidste trin vil den person, der rapporterede fejlen, eller QA-lederen kontrollere, at fejlen rent faktisk er blevet rettet på platformen, og problemet vil markeres som "lukket" i fejlsporingsværktøjet.

Oversigt over UAT-testtrin

1. Testeren forsøger at fuldføre en opgave på hjemmesiden, f.eks. tilføje et produkt til ønskelisten
2. Hvis testeren ikke er i stand til at fuldføre opgaven, rapporterer han/hun en fejl i fejlsporingsværktøjet.
3. QA-lederen verificerer fejlen, dvs. fejlen er ikke allerede blevet rapporteret af en anden.
4. QA-lederen tildeler fejlen til et teammedlem, som skal udbedre den.
5. Teammedlemmet arbejder på fejlen og markerer den som rettet, når problemet er løst
6. QA-lederen eller testeren tester funktionen igen for at sikre, at den fungerer
7. Fejlen bliver endeligt lukket af QA-lederen eller testeren

HØJTTALERE