Како осигурање квалитета може побољшати стопу конверзије у е-трговини моде

Догађај од Digital Fashion Academy
Април КСНУМКСтх КСНУМКС

Погледајте вебинар овде:

ПРЕГЛЕД

ТИТЛЕ: Осигурање квалитета за побољшање стопе конверзије у е-трговини моде
КОЈУ СТЕ: Уторак, 18. април у 5:30 (централноевропско време, Рим)
ТРАЈАЊЕ: КСНУМКС сат
ЈЕЗИК: Engleski
РЕГИСТЕРВебинар је бесплатан уз регистрацију

РЕЗИМЕ

Придружите се Енрику Фантагуцију (Digital Fashion Academy) и Лоренцо Фанети (Унгуес) како представљају najbolje prakse za контрола квалитета of e-commerce сајтови у сектору моде и луксуза.

Вебинар ће илустровати кључни концепти за контролу квалитета у e-commerce пројекти, од стандард Процеси користи се у великим компанијама, до Споразуми о нивоу услуга (SLA) који ће се делити са развојним агенцијама током дефинисања уговора.

• Осигурање квалитета је скуп активности усмерених на осигуравање да Резултати пројекта испуњава Очекивања од купац, крајњи корисници производа и било ког стандарди захтевају прописи.

• У моди e-commerce, Обезбеђивање квалитета је неопходно и за гаранција успех у погледу сајта конверзија стопа и да контрола projekat трошкови.

„Често се оно што се дешава на крају e-commerce пројекат развоја сајта, јесте да се проналазе бројни недостаци који ризикују да угрозе успех пројекта и однос између програмера и клијената. Исправно management Осигурање квалитета нам омогућава да постигнемо задовољство клијента, најбоље корисничко искуство и исправност management односа клијент-добављач“

Енрицо Фантагуззи

ТОПИЦС

• Дефиниција стандарда квалитета e-commerce сајт
• Гаранција производа након испоруке
• Методологија тестирања производа и решавање грешака management
• Алати за праћење грешака и проблема

ПРЕПИС

Пре него што сам покренуо ову компанију за е-учење, радио сам више од 20 година у модним и луксузним компанијама, од малих brandза велике мултинационалне компаније и продавце путем интернета.

У овом вебинару ћу поделити са вама неке ствари које сам научио током времена проведеног радећи за модну индустрију. brandс, чак и ако је искуство које данас делим са вама углавном стечено ван модне индустрије, у сектору дигиталне забаве.

Дакле, данас ћемо говорити о значај осигурања квалитета зашто је то кључно за успех моде ecommerce. 

Представићу вам неке идеје и примере како организовати процесе обезбеђивања квалитета у вашој компанији 

И на крају, обрадићемо неке ствари које треба имати на уму када разговарајте о задацима са својим добављачима, програмерима или систем интеграторима, шта да их питате током преговора и шта да укључите у уговор како би коначни резултат испунио ваша очекивања. 

Па која је сврха осигурања квалитета за моду? e-commerce? 

Која је сврха осигурања квалитета?

Сврха осигурања квалитета је да се осигура да дигитални производ испуњава очекивања клијента – вас самих – и крајњих корисника дигиталног производа, а то су ваши купци. 

Енрицо Фантагуззи

Да будем прецизнији Када говоримо о очекивањима, говоримо о захтевима и спецификацијама, захтеви и спецификације се разликују од очекивања јер су јасно наведено и документовано у једном или више докумената. 

Поред тога, можда ћете морати да се придржавате захтеви који су обавезујући за вашу компанију због законских ограничења.

Треће, постоји скуп очекивања која нису писана, али их ипак треба узети у обзир као део вашег пројекта јер нека од тих очекивања могу бити очекивања вашег management или Управни одбор њихових директора или друге заинтересоване стране на неки начин укључен у пројекат. 

Шта су захтеви, а шта спецификације?

Хајде да покушамо сада боље да дефинишемо шта су захтеви, а шта спецификације. То су технички термини који су некима од вас можда познати, али даћу вам неколико примера како бисте их могли запамтити кроз примере.

Примери захтева: 

• Могућност креирања налога, 
• Могућност одјаве као гост, 
• Могућност плаћања на рате уместо једне трансакције, 
• Могућност избора између различитих опција испоруке, 
• Могућност филтрирања само одређених величина током претраге, 
• Могућност претраживања кључних речи помоћу алата за претрагу
• Видљивост трошкова испоруке и пореза током процеса плаћања

Примери Спецификације: 

• Компатибилност са уређајима и оперативним системима 
• Величине слика, банера 
• Размена фреквентних података између система
• Формат и број резултата по страници

Где су наведени захтеви, спецификације и очекивања?

Ови елементи се обично записују у један или више пројектних докумената. 

Најчешће коришћени документ је Документ са захтевима за производ, такође назван PRD, који је обично у власништву и написао менаџер који је одговоран за e-commerce платформа. Ако документ Захтеви за производ није доступан Захтеве и спецификације можемо директно уписати у план пројекта, коначно, део Спецификација и захтева квалитета можемо пронаћи и у План квалитета. 

План квалитета углавном служи за организовање тестова квалитета и процеса обезбеђивања квалитета уопште, али може да садржи и неке специфичне захтеве за квалитет дигиталног производа. На пример, план квалитета може да се односи на специфичне безбедносне тестове које је потребно урадити. На пример, када сам радио као добављач услуга за великог произвођача спортске одеће brand и развијао сам њихове ecommerce вебсајт, морао сам да координирам безбедносне тестове на нашим серверима како бисмо испунили безбедносне стандарде клијента. 

Тестови ван домета

С друге стране, План квалитета може назначити која испитивања су ван обима пројекта, на пример, ако не планирате да испоручујете у Аустралију са својим ecommerce, не би требало да трошите време и енергију на развој и тестирање било каквих спецификација за ту одређену земљу. 

Вајерфрејмови и компози

План квалитета може да се односи на друге документе за спецификације и захтеве. На пример, план квалитета може да се односи на макете жичаних оквира или композних макета за све што је повезано са квалитетом дизајна и изгледом и доживљајем веб странице уопште.

Ови документи су важни јер ће их ваши програмери користити као референцу за оно што треба да развију и постигну у свом раду. 

Поред захтева, план квалитета описује тестове које је потребно обавити, када ће се обавити током пројекта и током испоруке производа и како ће се спроводити.

Критеријуми за покретање

План квалитета треба да садржи и критеријуме за пуштање у рад. Критеријуми за пуштање у рад су скуп услова које треба испунити да би пројекат био пуштен у рад, а пример критеријума за пуштање у рад су... максималан број дозвољених грешака на веб локацији Live и њихова озбиљностНа пример, план квалитета може да наведе да пројекат постаје активан само ако у тренутку објављивања постоји максималан број од 10 грешака на веб локацији.

Коначно, план квалитета садржи процедуре које ће пројектни тим морати да прати током процеса осигурања квалитета, на пример, ко је одговоран за тестирање и шта, како користити алат за праћење грешака, како класификовати грешке према њиховој озбиљности.

Које врсте тестова треба да спроведемо?

Врсте тестова за осигурање квалитета

Сада, хајде да детаљније погледамо које тестове треба да обликујемо brands focus on

Постоји неколико врста тестова које модне компаније могу да спроводе како би се увериле да платформа за трговину функционише у складу са очекивањима.

Тест дима

Тест дима је једноставан тест који има за циљ проверу основних карактеристика дигиталног производа. Ове тестове обично раде програмери током пројекта како би се уверили да основна функционалност софтвера функционише. То је једноставан тест који се састоји од испробавања основних карактеристика програма симулирање редовног корисника или потенцијалног клијента који треба да заврши задатак на платформиДа вам дам пример, ако имплементирате функцију претраге текста на својој веб страници, тест дима би био да унесете неколико кључних речи релевантних за ваше brand нпр. „црвена кожна торба“ и проверите да ли је резултат доследан. У овој фази, на пример, графички дизајн можда није релевантан, циљ је добити доследне резултате. Ако тражите црвену кожну торбу и као резултат добијете плаву мајицу, тест дима није успео.    

Интеграциони тест

Тест интеграције је специфичан тест за проверити исправан пренос података из једног система у другиНа пример, од платформе за е-трговину до ERP-а компаније и од ERP-а до складишта. management Систем или из ecommerce-платформе на платформу за пословну интелигенцију. Овај тест можемо сматрати успешним ако се подаци правилно преносе из једног система у други, без губитка података и у очекиваном временском оквиру. 

Тест прихватања корисника

Тест прихватања корисника, или UAT, обично се спроводи заједно са присуством клијента и програмера. 

Током UAT-а, клијент покреће све могуће случајеве употребе, нпр. претрагу производа, додавање производа на листу жеља, премештање производа са листе жеља у корпу, завршетак процеса плаћања, како би се уверио да све функционише како се очекује. 

Ови тестови се обично раде при крају фазе развоја, када је производ скоро спреман за испоруку клијенту. Обично је резултат ових тестова листа грешака, које је захтевао клијент, а које ће програмер исправити.

Регресиони тест

Четврта врста теста је регресионо тестирање. Регресионо тестирање осигурава да апликација и даље функционише како се очекује након било каквих промена кода, ажурирања или објављивања других функција на платформи. Регресија обезбеђује укупну стабилност платформе.

Ове тестове треба да спроводи тим за квалитет сваки пут када се појави ново издање на веб-сајту., како бисте били сигурни да све функције које су раније радиле и даље исправно раде. 

На пример, ако развијате нови систем плаћања, рецимо да развијате плаћање на рате у вашој благајни, и током имплементације ове нове функције, прекинете плаћање кредитним картицама које је раније радило исправно, па смо увели грешку у претходно исправну функцију, у овом случају говоримо о регресији.

Процеси тестирања и исправљања грешака

 Разговарали смо о улози руководиоца за обезбеђење квалитета, а сада да видимо како сви актери укључени у процес обезбеђења квалитета међусобно комуницирају.

Први корак се дешава када се грешка први пут открије; тестер, било члан пројектног тима или професионални тестер, пратећи тест скрипту, проналази грешку. На пример, тест скрипта би могла да каже: додајте производ на листу жеља, а затим преместите производ са листе жеља у корпу за куповину. 

Ако тестер није у могућности да дода производ на листу жеља или да премести производ са листе жеља у корпу за куповину, тестер ће пријавити грешку и отвориће тикет у алату за праћење грешака. Када тестер пријави грешку у систему, он или она треба да дода и неке спецификације као што су упутства за репродукцију грешке., ово ће помоћи програмеру да брзо репродукује услове када је грешка пронађена. Тестер ће такође генерално известити који уређај и који оперативни систем је био у употреби када је грешка пронађена. На пример, користио сам Сафари на iPad Pro-у.

У другом кораку, Вођа контроле квалитета ће проверити све доступне информације о грешци и још једном ће проверити да ли је грешка пријављена.Ово је важно, иначе бисмо могли имати дуплиране грешке у алату за праћење грешака.

Водитељ контроле квалитета ће затим доделити грешку члану тима да ради на проблему. Имајте у виду да тренутно користим грешку и проблем као синониме.

У кораку 3, програмер решава проблем у развојном окружењу и означава га као решеног. 

Имајте у виду да програмер означава грешку као Исправљену или Решену, али не затвара захтев у алату за праћење грешака, већ само особа која је пријавила грешку или водитељ контроле квалитета треба да означи проблем као затворен.

У последњем кораку, особа која је пријавила грешку или руководилац контроле квалитета ће проверити да ли је грешка заиста исправљена на платформи и означиће проблем као затворен у алату за праћење грешака.

Резиме корака UAT теста

1. Тестер покушава да заврши задатак на веб локацији, нпр. дода производ на листу жеља
2. Ако тестер није у могућности да заврши задатак, пријављује грешку у алату за праћење грешака.
3. Вођа контроле квалитета проверава грешку, тј. да грешку није већ пријавио неко други.
4. Вођа контроле квалитета додељује грешку члану тима да је поправи
5. Члан тима ради на грешци и означава је као исправљену када је проблем решен
6. Водитељ контроле квалитета или тестер поново тестирају функцију како би се уверили да ради.
7. Грешку је коначно отклонио водитељ контроле квалитета или тестер

ЗВУЧНИЦИ