Hoe kwaliteitsborging de conversieratio in e-commerce in de modesector kan verbeteren

Evenement door Digital Fashion Academy
April 18th 2023

Bekijk hier het webinar:

Overzicht

TITEL: Kwaliteitsborging voor het verbeteren van de conversieratio in mode-e-commerce
DATUM: Dinsdag 18 april om 5:30 uur (CET ROME)
DUUR: 1 uur
TAAL: Engels
REGISTREER U: Het webinar is gratis na registratie

OVERZICHT

Sluit je aan bij Enrico Fantaguzzi (Digital Fashion Academy) en Lorenzo Fanetti (Onraad) zoals ze de 'best practices' besteld, kwaliteitscontrole of e-commerce sites in de mode- en luxesector.

Het webinar zal de belangrijkste concepten voor kwaliteitsborging in e-commerce projecten, van de standaard processen gebruikt in grote bedrijven, tot de Service Level Agreements (SLA) die met ontwikkelingsagentschappen wordt gedeeld tijdens het opstellen van contracten.

• Kwaliteitsborging is de reeks activiteiten die erop gericht zijn ervoor te zorgen dat de resultaat van een project voldoen aan de verwachtingen van de klant eindgebruikers van het product en eventuele normen vereist door de reglement.

• In de mode e-commerceKwaliteitsborging is essentieel voor zowel garantie succes qua locatie Conversie tarief Samen onder controle te houden project kosten.

“Vaak gebeurt er aan het einde van een e-commerce Een veelvoorkomend probleem bij projecten voor terreinontwikkeling is dat er talloze gebreken worden ontdekt die het succes van het project en de relatie tussen ontwikkelaars en opdrachtgevers in gevaar brengen. management Kwaliteitsborging stelt ons in staat om klanttevredenheid, de beste gebruikerservaring en correcte resultaten te garanderen. management van de klant-leverancierrelatie

Enrico Fantaguzzi

ONDERWERPEN

• Definitie van de kwaliteitsnormen van de e-commerce website
• Productgarantie na levering
• Producttestmethodologie en bugoplossing management
• Hulpmiddelen voor het opsporen van bugs en problemen

afschrift

Voordat ik dit e-learningbedrijf oprichtte, heb ik meer dan 20 jaar in de mode- en luxebranche gewerkt, van kleine bedrijven tot grote ondernemingen. brandaan grote multinationale bedrijven en online retailers.

In dit webinar deel ik een aantal dingen met jullie die ik heb geleerd tijdens mijn werk in de mode-industrie. brands, ook al heb ik de ervaring die ik vandaag met jullie deel grotendeels buiten de mode-industrie opgedaan, namelijk in de digitale entertainmentsector.

Vandaag gaan we het dus hebben over de belang van kwaliteitsborging en waarom het cruciaal is voor het succes van mode ecommerce. 

Ik zal je een aantal ideeën en voorbeelden geven van hoe u kwaliteitsborgingsprocessen binnen uw bedrijf organiseert 

En tot slot zullen we een aantal zaken bespreken waar u rekening mee moet houden wanneer u Bespreek opdrachten met uw leveranciers, ontwikkelaars of systeemintegratoren, wat u hen tijdens de onderhandelingen moet vragen en wat u in het contract moet opnemen, zodat het eindresultaat aan uw verwachtingen voldoet. 

Wat is dan het doel van kwaliteitsborging voor mode? e-commerce? 

Wat is het doel van kwaliteitsborging?

Kwaliteitsborging heeft als doel ervoor te zorgen dat het digitale product voldoet aan de verwachtingen van de klant (uzelf) en van de eindgebruikers van het digitale product (uw klanten). 

Enrico Fantaguzzi

Om specifieker te zijn Als we het over verwachtingen hebben, hebben we het over eisen en specificaties, eisen en specificaties verschillen van de verwachtingen omdat ze duidelijk vermeld en gedocumenteerd in een of meer documenten. 

Bovendien moet u zich mogelijk houden aan eisen die voor uw bedrijf bindend zijn vanwege wettelijke beperkingen.

Ten derde is er een reeks verwachtingen die niet op papier staan, maar die u toch als onderdeel van uw project moet beschouwen, omdat sommige van deze verwachtingen mogelijk niet op papier staan. de verwachtingen van uw management of de raad van bestuur of andere belanghebbenden op de een of andere manier bij het project betrokken zijn. 

Wat zijn eisen en wat zijn specificaties?

Laten we nu proberen beter te definiëren wat vereisten en wat specificaties zijn. Dit zijn technische termen die voor sommigen van jullie bekend kunnen zijn, maar ik zal je een paar voorbeelden geven, zodat je ze in je hoofd kunt prenten door middel van voorbeelden.

Voorbeelden Vereisten: 

• Mogelijkheid om een ​​account aan te maken, 
• Mogelijkheid om als gast uit te checken, 
• Mogelijkheid om in termijnen te betalen in plaats van in één enkele transactie, 
• Mogelijkheid om te kiezen uit verschillende verzendopties, 
• Mogelijkheid om alleen specifieke maten te filteren tijdens het zoeken, 
• Mogelijkheid om met een zoektool op trefwoord te zoeken
• Zichtbaarheid van verzendkosten en belastingen tijdens het afrekenproces

Voorbeelden Specificaties: 

• Compatibiliteit met apparaten en besturingssystemen 
• Afmetingen van afbeeldingen, banners 
• Frequentiegegevensuitwisseling tussen systemen
• Het formaat en het aantal resultaten per pagina

Waar worden de specificaties en verwachtingen vermeld?

Deze elementen worden doorgaans in een of meer projectdocumenten vastgelegd. 

Het meest gebruikte document is de Productvereistendocument, ook wel PRD genoemd, die gewoonlijk eigendom is van en geschreven wordt door de manager die verantwoordelijk is voor de e-commerce platform. Als het productvereistendocument niet beschikbaar is We kunnen eisen en specificaties direct in het projectplan schrijven, tenslotte kunnen we een deel van de kwaliteitsspecificaties en -vereisten ook terugvinden in de Kwaliteitsplan. 

Het kwaliteitsplan dient voornamelijk om de kwaliteitstests en het kwaliteitsborgingsproces in het algemeen te organiseren, maar het kan ook specifieke eisen voor de kwaliteit van het digitale product bevatten. Zo kan het kwaliteitsplan bijvoorbeeld verwijzen naar specifieke beveiligingstests die moeten worden uitgevoerd. Een voorbeeld hiervan is mijn werk als dienstverlener voor een grote sportkledingfabrikant. brand en ik was bezig met het ontwikkelen van hun ecommerce website moest ik de beveiligingstests op onze servers coördineren om te voldoen aan de beveiligingsnormen van de klant. 

Tests buiten het toepassingsgebied

Aan de andere kant kan het kwaliteitsplan aangeven welke testen buiten het bereik van het project vallen, bijvoorbeeld als u niet van plan bent om met uw product naar Australië te verzenden. ecommerce, moet u geen tijd en energie besteden aan het ontwikkelen en testen van specificaties voor dat specifieke land. 

Wireframes en comps

Het kwaliteitsplan kan verwijzen naar andere documenten voor specificaties en vereisten. Het kwaliteitsplan kan bijvoorbeeld verwijzen naar Wireframes of Comps-mockups voor alles wat te maken heeft met de ontwerpkwaliteit en de uitstraling van de website in het algemeen.

Deze documenten zijn belangrijk omdat ze door uw ontwikkelaars worden gebruikt als referentie voor wat zij moeten ontwikkelen en bereiken in hun werk. 

Naast de eisen beschrijft het kwaliteitsplan ook welke testen er uitgevoerd moeten worden, wanneer deze tijdens het project en tijdens de oplevering van het product uitgevoerd zullen worden en hoe deze uitgevoerd zullen worden.

GO-LIVE-criteria

Het kwaliteitsplan moet ook de GO-LIVE-criteria bevatten. De GO-LIVE-criteria zijn een reeks voorwaarden waaraan moet worden voldaan om met het project live te gaan. Voorbeelden van GO-LIVE-criteria zijn: maximaal aantal bugs toegestaan ​​op de Live website en hun ernstZo kan het kwaliteitsplan bijvoorbeeld vermelden dat het project pas live gaat als er op het moment van live gaan maximaal 10 bugs in totaal op de website staan.

Ten slotte bevat het kwaliteitsplan de procedures die het projectteam moet volgen tijdens het kwaliteitsborgingsproces. Bijvoorbeeld wie verantwoordelijk is voor wat en testen, hoe de tool voor het bijhouden van bugs moet worden gebruikt en hoe de bugs moeten worden geclassificeerd op basis van hun ernst.

Welke soorten tests moeten we uitvoeren?

Soorten kwaliteitsborgingstests

Laten we nu eens nader bekijken welke tests er zouden moeten worden uitgevoerd. brands focus on

Modebedrijven kunnen verschillende soorten tests uitvoeren om er zeker van te zijn dat het handelsplatform aan de verwachtingen voldoet.

Rook test

Het Rooktest is een eenvoudige test die gericht is op het controleren van de kernfuncties van het digitale product. Deze tests worden meestal door ontwikkelaars tijdens het project uitgevoerd om te controleren of de kernfunctionaliteit van de software werkt. Het is een eenvoudige test die bestaat uit het uitproberen van de kernfuncties van een programma. het simuleren van een gewone gebruiker of potentiële klant die een taak op het platform moet voltooienOm een ​​voorbeeld te geven: als u een tekstzoekfunctie op uw website implementeert, zou de rooktest bestaan ​​uit het intypen van een paar relevante zoekwoorden. brand Bijvoorbeeld: "rode leren tas" en controleer of het resultaat consistent is. In deze fase is het grafisch ontwerp bijvoorbeeld misschien nog niet relevant; het doel is om consistente resultaten te krijgen. Als je zoekt naar "rode leren tas" en je krijgt een blauw T-shirt als resultaat, dan is de rooktest mislukt.    

Integratietest

De integratietest is een specifieke test om de correcte doorgang van gegevens van het ene systeem naar het andere verifiërenBijvoorbeeld van het e-commerceplatform naar het ERP-systeem van het bedrijf, en van het ERP-systeem naar het magazijn. management Systeem of van De ecommerce-platform naar het Business Intelligence-platform. We kunnen deze test als geslaagd beschouwen als de gegevens correct van het ene systeem naar het andere worden doorgegeven, zonder gegevensverlies en binnen het verwachte tijdsbestek. 

Gebruikersacceptatietest

De gebruikersacceptatietest (UAT) wordt doorgaans uitgevoerd in aanwezigheid van de Klant en de Ontwikkelaar. 

Tijdens de UAT voert de klant alle mogelijke use cases uit, bijvoorbeeld zoeken naar een product, een product toevoegen aan de verlanglijst, een product van de verlanglijst naar de winkelwagen verplaatsen en het afrekenproces voltooien. Zo wordt gecontroleerd of alles werkt zoals verwacht. 

Deze tests worden meestal uitgevoerd aan het einde van de ontwikkelingsfase, wanneer het product bijna klaar is om aan de klant te worden geleverd. De output van deze tests bestaat meestal uit een lijst met bugs, aangevraagd door de klant, die door de ontwikkelaar worden opgelost.

Regressietest

Het vierde type test is regressietesten. Regressietesten zorgen ervoor dat een applicatie nog steeds naar behoren functioneert na codewijzigingen, updates of releases van andere functies op het platform. Regressie garandeert de algehele stabiliteit van het platform.

Deze tests moeten door het kwaliteitsteam worden uitgevoerd telkens wanneer er een nieuwe release op de website verschijnt, om er zeker van te zijn dat alle functies die eerder werkten, nog steeds goed werken. 

Stel dat u een nieuw betalingssysteem ontwikkelt, bijvoorbeeld de functie 'Betalen in termijnen' in uw kassasysteem. Tijdens de implementatie van deze nieuwe functie mislukt de functie voor betalingen via creditcards, die eerder prima functioneerde. In dat geval hebben we een bug geïntroduceerd in een functie die eerder wel werkte; in dit geval hebben we het over regressie.

Bugtest- en bugfixprocessen

 We hebben het gehad over de rol van de Quality Assurance Lead. Laten we nu eens kijken hoe alle betrokkenen bij het Quality Assurance-proces met elkaar samenwerken.

De eerste stap vindt plaats wanneer een bug voor het eerst wordt ontdekt; de tester, een projectteamlid of een professionele tester die een testscript volgt, vindt een bug. Het testscript zou bijvoorbeeld kunnen zeggen: voeg een product toe aan de verlanglijst en verplaats het product vervolgens van de verlanglijst naar de winkelwagen. 

Als de tester een product niet aan de verlanglijst kan toevoegen of het product niet van de verlanglijst naar het winkelmandje kan verplaatsen, meldt de tester een bug en opent hij of zij een ticket in de bugtrackingtool. Wanneer een tester een bug in het systeem meldt, moet hij of zij ook enkele specificaties toevoegen, zoals de instructies om de bug te reproducerenDit helpt de ontwikkelaar om snel de omstandigheden te reproduceren toen de bug werd gevonden. De tester zal doorgaans ook rapporteren welk apparaat en welk besturingssysteem werd gebruikt toen de bug werd gevonden. Ik gebruikte bijvoorbeeld Safari op de iPad Pro.

In de tweede stap, de De QA-leider controleert alle beschikbare informatie over de bug en controleert nogmaals of de bug nog niet is gemeld.Dit is belangrijk, anders bestaat de kans dat er dubbele bugs in de bugtrackingtool terechtkomen.

De QA-leider wijst de bug vervolgens toe aan een teamlid om aan het probleem te werken. Let op: ik gebruik momenteel de termen bug en probleem als synoniemen.

In stap 3 lost de ontwikkelaar het probleem op in de ontwikkelomgeving en markeert het probleem als opgelost. 

Houd er rekening mee dat de ontwikkelaar de bug markeert als Opgelost of Verholpen, maar het ticket in de bugtrackingtool niet sluit. Alleen de persoon die de bug heeft gemeld of de QA-manager mag het probleem als gesloten markeren.

In de laatste stap controleert de persoon die de tas heeft gemeld of de QA-manager of het probleem daadwerkelijk is opgelost op het platform. Vervolgens wordt het probleem in de bugtrackingtool gemarkeerd als 'gesloten'.

Samenvatting van UAT-teststappen

1. De tester probeert een taak op de website uit te voeren, bijvoorbeeld een product toevoegen aan de verlanglijst
2. Als de tester de taak niet kan voltooien, meldt hij/zij een bug in de bugtrackingtool
3. De QA-leider verifieert de bug, d.w.z. dat de bug niet al door iemand anders is gemeld.
4. De QA-leider wijst de bug toe aan een teamlid om te repareren
5. Het teamlid werkt aan de bug en markeert deze als opgelost wanneer het probleem is opgelost
6. De QA-leider of de tester test de functie opnieuw om er zeker van te zijn dat deze werkt
7. De bug wordt uiteindelijk gesloten door de QA-leider of tester

SPEAKERS