Hogyan javíthatja a minőségbiztosítás a konverziós arányt a divat e-kereskedelmében?
Esemény: Digital Fashion Academy
Április 18th 2023
Nézze meg a webináriumot itt:
ÁTTEKINTÉS
TITLE: Minőségbiztosítás a konverziós arány javítására a divat e-kereskedelemben
DÁTUM: Április 18., kedd, 5:30 (közép-európai idő szerint, Róma)
IDŐTARTAMA: 1 óra
NYELV: Angol
REGISZTRÁCIÓA webinárium regisztráció után ingyenesen látogatható.
ÖSSZEFOGLALÓ
Csatlakozz Enrico Fantaguzzihoz (Digital Fashion Academy) és Lorenzo Fanetti (Találgatás) ahogyan bemutatják a legjobb gyakorlatok mert minőség-ellenőrzés of e-commerce divat- és luxuscikkek szektorában működő oldalak.
A webinárium bemutatja a kulcsfogalmak a minőségbiztosítási ellenőrzéshez e-commerce projektek, a standard Folyamatok nagyvállalatoknál használják, Szolgáltatási szintű megállapodások (SLA) megosztása a fejlesztési ügynökségekkel a szerződések meghatározása során.
- Minőségbiztosítás azon tevékenységek összessége, amelyek célja annak biztosítása, hogy a eredmények egy projekt találkozik a várakozások az vevő, a végfelhasználó a termék és bármely szabványok megköveteli a előírások.
- A divatban e-commerceA minőségbiztosítás elengedhetetlen mind a garancia siker a helyszín tekintetében átalakítás arány és ellenőrzés program Költségek.
„Gyakran az történik egy végén…” e-commerce weboldalfejlesztési projekt során számos olyan hibát találtak, amelyek veszélyeztetik a projekt sikerét, valamint a fejlesztők és az ügyfelek közötti kapcsolatot. A helyes management A minőségbiztosítás teszi lehetővé számunkra az ügyfél elégedettségének elérését, a legjobb felhasználói élményt és a helyes működést. management az ügyfél-beszállító kapcsolatról”
Enrico Fantaguzzi
TÉMÁK
- A minőségi szabványok meghatározása e-commerce weboldal
- Termékgarancia a kiszállítás után
- Terméktesztelési módszertan és hibaelhárítás management
- Hibakövető és problémakövető eszközök
másolat
Mielőtt elindítottam ezt az e-learning céget, több mint 20 évig dolgoztam divat- és luxuscégeknél, kisvállalkozásoktól kezdve brandnagy multinacionális vállalatoknak és e-kereskedőknek.
Ebben a webináriumban megosztok veletek néhány dolgot, amit a divatvilágban töltött időm alatt tanultam. brandmég akkor is, ha a ma veletek megosztott tapasztalataim nagy részét a divatiparon kívül, a digitális szórakoztatóiparban szereztem.
Tehát ma arról fogunk beszélni, hogy a minőségbiztosítás fontossága és a miért kritikus a sikerhez a divat ecommerce.
Mutatok nektek néhány ötletet és példát, hogyan szervezze meg a minőségbiztosítási folyamatokat a vállalatán belül
Végül pedig áttekintünk néhány dolgot, amire érdemes odafigyelni, amikor megbeszéli a feladatokat a beszállítóival, fejlesztőivel vagy rendszerintegrátoraival, mit kérdezzünk tőlük a tárgyalások során, és mit foglaljunk bele a szerződésbe, hogy a végeredmény megfeleljen az elvárásainknak.
Mi tehát a minőségbiztosítás célja a divatban? e-commerce?
Mi a minőségbiztosítás célja?
A minőségbiztosítás célja annak biztosítása, hogy a digitális termék megfeleljen az ügyfél – saját magad – és a digitális termék végfelhasználóinak, azaz az ügyfeleidnek az elvárásainak.
Enrico Fantaguzzi
Hogy pontosabb legyek Amikor elvárásokról beszélünk, akkor követelményekről és specifikációkról beszélünk.a követelmények és specifikációk eltérnek az elvárásoktól, mert azok egyértelműen megfogalmazva és dokumentálva egy vagy több dokumentumban.
Ráadásul előfordulhat, hogy be kell tartania a következőket: olyan követelmények, amelyek jogi korlátozások miatt kötelező érvényűek a vállalatára nézve.
Harmadszor, vannak olyan elvárások, amelyek nincsenek leírva, de mégis figyelembe kell venni őket a projekt részeként, mert ezek közül néhány elvárás lehet… az elvárásaid management vagy az igazgatótanácsuk, illetve más érdekelt felek valahogyan részt vett a projektben.
Mik a követelmények és mik a specifikációk?
Próbáljuk meg most jobban meghatározni, hogy mik a követelmények és mik a specifikációk. Ezek olyan szakkifejezések, amelyek néhányatok számára ismerősek lehetnek, de adok néhány példát, hogy példákon keresztül emlékezzetek rájuk.
Példák a követelményekre:
- Fiók létrehozásának lehetősége,
- Vendégként történő kijelentkezés lehetősége,
- Részletekben történő fizetés lehetősége egyetlen tranzakció helyett,
- Lehetőség a különböző szállítási módok közötti választásra,
- Lehetőség csak bizonyos méretek szűrésére a keresés során,
- Kulcsszókeresési lehetőség egy keresőeszközzel
- A szállítási költség és az adók láthatósága a fizetési folyamat során
Példák a specifikációkra:
- Kompatibilitás eszközökkel és operációs rendszerekkel
- Képek, bannerek méretei
- Frekvenciaadat-csere rendszerek között
- A formátum és az oldalakonkénti találatok száma
Hol vannak feltüntetve a követelményspecifikációk és az elvárások?
Ezek az elemek általában egy vagy több projektdokumentumba vannak beírva.
A leggyakrabban használt dokumentum a Termékkövetelmény-dokumentum, más néven PRD, amelyet általában az a vezető birtokol és ír, aki felelős a e-commerce platform. Ha a Termékkövetelmények dokumentum nem érhető el A követelményeket és specifikációkat közvetlenül a projekttervbe írhatjukvégül a Minőségi Előírások és Követelmények egy részét is megtaláljuk a Minőségi terv.
A minőségügyi terv elsősorban a minőségtesztek és az általános minőségbiztosítási folyamat megszervezését szolgálja, de tartalmazhat bizonyos konkrét követelményeket is a digitális termék minőségére vonatkozóan. Például a minőségügyi terv vonatkozhat konkrét biztonsági tesztekre, amelyeket el kell végezni. Például, amikor szolgáltatóként dolgoztam egy nagy sportruházat-gyártó cégnél... brand és én fejlesztettem az ő ecommerce weboldalon, nekem kellett koordinálnom a szervereink biztonsági tesztjeit, hogy megfeleljenek az ügyfél biztonsági szabványainak.
Hatókörön kívüli tesztek
Másrészt a Minőségügyi Terv jelezheti, hogy mely tesztek esnek kívül a projekt hatókörén. Például, ha nem tervezi Ausztráliába szállítani a... ecommerce, nem szabad időt és energiát pazarolnia az adott országra vonatkozó specifikációk kidolgozására és tesztelésére.
Drótvázak és összehasonlító modellek
A Minőségterv más dokumentumokra is hivatkozhat a specifikációk és követelmények tekintetében. Például a minőségterv hivatkozhat Wireframe-ekre vagy Comps modellekre minden olyan dolog esetében, ami a weboldal tervezési minőségével és általános megjelenésével kapcsolatos.
Ezek a dokumentumok azért fontosak, mert a fejlesztők referenciaként fogják használni őket a munkájuk során fejlesztendő és megvalósítandó feladatokhoz.
A követelményeken kívül a minőségügyi terv leírja az elvégzendő teszteket, hogy mikor kerülnek elvégzésre a projekt és a termék leszállítása során, és hogyan kerülnek végrehajtásra.
ÉLES ÜZEMELTETÉSI kritériumok
A minőségtervnek tartalmaznia kell az ÉLES ÜZEMELTETÉS kritériumait is. Az ÉLES ÜZEMELTETÉS kritériumai olyan feltételek, amelyeket teljesíteni kell a projekt éles üzembe helyezéséhez, és az ÉLES ÜZEMELTETÉS kritériumaira példaként említhetők a következők: a Live weboldalon megengedett hibák maximális száma és azok súlyosságaPéldául a minőségügyi terv kimondhatja, hogy a projekt csak akkor kerül élesbe, ha a weboldalon az éles indítás pillanatában legfeljebb 10 hiba van.
Végül a minőségbiztosítási terv tartalmazza azokat az eljárásokat, amelyeket a Projektcsapatnak követnie kell a minőségbiztosítási folyamat során, például, hogy ki a felelős a tesztelésért és miért, hogyan kell használni a hibakövető eszközt, hogyan kell osztályozni a hibákat súlyosságuk szerint.
Milyen típusú teszteket kell futtatnunk?
Minőségbiztosítási tesztek típusai
Most pedig nézzük meg részletesebben, hogy milyen teszteknek kellene lenniük brands focus on
A divatcégek többféle tesztet futtathatnak annak érdekében, hogy megbizonyosodjanak arról, hogy a kereskedelmi platform az elvárásoknak megfelelően működik.
Füst teszt
Az A füstteszt egy egyszerű teszt, amelynek célja az alapvető funkciók ellenőrzése a digitális termék. Ezeket a teszteket általában a fejlesztők végzik a projekt során, hogy megbizonyosodjanak arról, hogy a szoftver alapvető funkciói működnek. Ez egy egyszerű teszt, amely a program alapvető funkcióinak kipróbálásából áll. egy átlagos felhasználó vagy potenciális ügyfél szimulálása, akinek feladatot kell elvégeznie a platformonPéldaként említve, ha szöveges keresési funkciót valósít meg a webhelyén, a füstteszt a következő lenne: írjon be néhány, a webhelyéhez kapcsolódó kulcsszót. brand pl. „piros bőrtáska”, és ellenőrizd, hogy az eredmény konzisztens-e. Ebben a szakaszban például a grafikai tervezés nem biztos, hogy releváns, a cél a konzisztens eredmények elérése. Ha a Piros bőrtáska kifejezésre keresel, és egy kék pólót kapsz eredményül, akkor a Füstpróba sikertelen volt.
Integrációs teszt
Az integrációs teszt egy specifikus teszt, amivel ellenőrizze az adatok helyes átvitelét egyik rendszerből a másikbaPéldául az e-kereskedelmi platformról a vállalat ERP-rendszerébe, és az ERP-rendszerből a raktárba. management Rendszer vagy a ecommerce-platformról az Üzleti Intelligencia platformra. Ezt a tesztet sikeresnek tekinthetjük, ha az adatok helyesen, adatvesztés nélkül és a várt időkereten belül kerülnek átvitelre egyik rendszerről a másikra.
Felhasználói elfogadási teszt
A felhasználói elfogadási tesztet, vagy UAT-t, általában az Ügyfél és a Fejlesztő jelenlétében végzik el.
Az UAT során az ügyfél lefuttatja az összes lehetséges felhasználási esetet, pl. termék keresése, termék hozzáadása a kívánságlistához, termék áthelyezése a kívánságlistáról a kosárba, a fizetési folyamat befejezése, hogy megbizonyosodjon arról, hogy minden a várt módon működik.
Ezeket a teszteket általában a fejlesztési fázis vége felé végzik, amikor a termék már majdnem készen áll a megrendelőhöz való eljuttatásra. A tesztek kimenete általában a megrendelő által kért hibák listája, amelyeket a fejlesztő kijavít.
Regressziós teszt
A negyedik teszttípus a regressziós tesztelés. A regressziós tesztelés biztosítja, hogy egy alkalmazás a várt módon működjön a kód bármilyen módosítása, frissítése vagy a platformon található egyéb funkciók kiadása után. A regresszió biztosítja a platform általános stabilitását.
Ezeket a teszteket a Minőségbiztosítási Csoportnak minden alkalommal el kell végeznie, amikor új kiadás jelenik meg a weboldalon., hogy megbizonyosodjon arról, hogy az összes korábban működő funkció továbbra is megfelelően működik.
Például, ha egy új fizetési rendszert fejlesztesz, tegyük fel, hogy a részletfizetést fejleszted a pénztárnál, és ennek az új funkciónak a bevezetése során elromlik a korábban jól működő bankkártyás fizetés, ezért hibát vezettünk be egy korábban működő funkcióban, ebben az esetben a regresszióról beszélünk.
Hibatesztelés és hibajavítási folyamatok
Beszéltünk a minőségbiztosítási vezető szerepéről, most nézzük meg, hogyan hatnak egymásra a minőségbiztosítási folyamatban részt vevő összes szereplő.
Az első lépés a hiba felfedezésekor történik; a tesztelő, akár egy projektcsapat tagja, akár egy profi tesztelő egy tesztszkript után, hibát talál. A tesztszkript például azt mondhatja: adj hozzá egy terméket a kívánságlistához, majd helyezd át a terméket a kívánságlistáról a kosárba.
Ha a tesztelő nem tud egy terméket hozzáadni a kívánságlistához, vagy a kívánságlistáról a kosárba helyezni, hibát jelent, és egy ticketet nyit a hibakövető eszközben. Amikor egy tesztelő hibát jelent a rendszerben, hozzá kell adnia néhány specifikációt is, például a hiba reprodukálására vonatkozó utasításokat., ez segít a fejlesztőnek gyorsan reprodukálni a hiba megtalálásának körülményeit. A tesztelő általában azt is jelenti, hogy melyik eszközt és melyik operációs rendszert használták a hiba megtalálásakor. Például én Safarit használtam iPad Prón.
A második lépésben a A minőségbiztosítási vezető ellenőrzi a hibával kapcsolatos összes elérhető információt, és kétszeresen is ellenőrzi, hogy a hibát még nem jelentették-e.Ez fontos, különben előfordulhat, hogy a hibakövető eszközben ismétlődő hibák vannak.
A minőségbiztosítási vezető ezután kijelöli a hibát egy csapattagnak, hogy dolgozzon a problémán. Kérjük, vegye figyelembe, hogy jelenleg a hiba és a probléma szavakat szinonimaként használom.
A 3. lépésben a fejlesztő kijavítja a problémát a fejlesztői környezetben, és javítottként jelöli meg.
Kérjük, vegye figyelembe, hogy a fejlesztő Javítottként vagy Megoldottként jelöli meg a hibát, de nem zárja le a ticketet a hibakövető eszközben, csak a hibát jelentő személynek vagy a minőségbiztosítási vezetőnek kell lezártként megjelölnie a problémát.
Az utolsó lépésben a hibát jelentő személy vagy a minőségbiztosítási vezető ellenőrzi, hogy a hibát valóban kijavították-e a platformon, és a hibakövető eszközben lezártként jelöli meg a problémát.
Az UAT tesztelési lépések összefoglalása
- A tesztelő megpróbál elvégezni egy feladatot a weboldalon, pl. hozzáadni egy terméket a kívánságlistához.
- Ha a tesztelő nem tudja elvégezni a feladatot, hibát jelent a hibakövető eszközben.
- A minőségbiztosítási vezető ellenőrzi a hibát, azaz a hibát más nem jelentette még.
- A minőségbiztosítási vezető kijelöli a hibát egy csapattagnak a javításra.
- A csapattag a hibán dolgozik, és javítottként jelöli meg, amikor a probléma megoldódott.
- A minőségbiztosítási vezető vagy a tesztelő újra teszteli a funkciót, hogy megbizonyosodjon a működéséről.
- A hibát végül a minőségbiztosítási vezető vagy a tesztelő zárja le.
HANGSUGÁRZÓK
Enrico Fantaguzzi az alapítója Digital Fashion Academy és a divat e-commerce tanácsadó. Dolgozott multinacionális vállalatoknál, többek között Gucci, A Walt Disney Company és a yox.
Lorenzo Fanetti az UNGUESS digitális minőségügyi tanácsadója és értékesítési vezetője, amely a Milánói Műszaki Egyetem spin-off vállalata. Az UNGUESS partnere az olaszországi és európai divat e-kereskedelem területén működő legfontosabb vállalatok digitális optimalizálásában.
Soha ne maradj le egyetlen frissítésről sem