Как обеспечение качества может повысить коэффициент конверсии в сфере электронной коммерции в сфере моды

Событие по Digital Fashion Academy
Апрель 18th 2023

Смотрите веб-семинар здесь:

О проекте

НАЗВАНИЕ: Обеспечение качества для повышения коэффициента конверсии в сфере электронной коммерции в сфере моды
ДАТА: Вторник, 18 апреля, 5:30 (CET ROME)
СРОК: 1 час
ЯЗЫК: Английский
РЕГИСТРАЦИЯ: Вебинар бесплатный при регистрации.

РЕЗЮМЕ

Присоединяйтесь к Энрико Фантагуцци (Digital Fashion Academy) и Лоренцо Фанетти (Разгадать), поскольку они представляют лучших практик для контроль качества of e-commerce сайты в сфере моды и роскоши.

Вебинар проиллюстрирует ключевые идеи для контроля качества в e-commerce проекты, из стандарт процессов используется в крупных компаниях, Соглашения об уровне обслуживания (SLA), которые будут переданы агентствам развития во время определения контрактов.

• Гарантия качества представляет собой комплекс мероприятий, направленных на обеспечение того, чтобы результатов проекта отвечают ожидания клиент, конечные пользователи продукта и любых стандартов требуется правила.

• Модный e-commerce, Обеспечение качества имеет важное значение как для гарантия успех в плане сайта Преобразование скорость и контроль Проект расходы.

«Часто то, что происходит в конце e-commerce В проектах по разработке сайтов часто обнаруживаются многочисленные дефекты, которые могут подорвать успех проекта и отношения между разработчиками и заказчиками. Правильное решение этой проблемы заключается в следующем: management Обеспечение качества позволяет нам добиваться удовлетворенности клиента, наилучшего пользовательского опыта и правильного решения проблем. management в отношениях между клиентом и поставщиком».

Энрико Фантагуцци

ТЕМЫ

• Определение стандартов качества e-commerce сайте
• Гарантия на товар после доставки
• Методология тестирования продукта и устранение ошибок management
• Инструменты отслеживания ошибок и проблем

расшифровка

До основания этой компании, занимающейся онлайн-обучением, я более 20 лет проработала в компаниях, работающих в сфере моды и предметов роскоши, начиная с небольших предприятий. brandдля крупных транснациональных компаний и интернет-магазинов.

На этом вебинаре я поделюсь с вами некоторыми вещами, которые я узнала за время работы в индустрии моды. brandдаже если опыт, которым я сегодня с вами поделюсь, был получен в основном вне индустрии моды, в секторе цифровых развлечений.

Итак, сегодня мы поговорим о важность обеспечения качества и почему это важно для успеха моды ecommerce. 

Я поделюсь с вами некоторыми идеями и примерами как организовать процессы обеспечения качества внутри вашей компании 

И, наконец, мы расскажем о некоторых вещах, о которых вам следует помнить, когда вы обсудить задания с разработчиками ваших поставщиков или системными интеграторами, о чем спрашивать их на переговорах и что включить в договор, чтобы конечный результат оправдал ваши ожидания. 

Так в чем же цель обеспечения качества в сфере моды? e-commerce? 

Какова цель гарантии качества?

Цель обеспечения качества — убедиться, что цифровой продукт соответствует ожиданиям клиента (то есть вас самих) и конечных пользователей цифрового продукта, то есть ваших клиентов. 

Энрико Фантагуцци

Чтобы быть более конкретным когда мы говорим об ожиданиях, мы говорим о требованиях и спецификациях,  требования и спецификации отличаются от ожиданий, поскольку они четко сформулировано и задокументировано в одном или нескольких документах. 

Кроме того, вам, возможно, придется соблюдать требования, которые являются обязательными для вашей компании из-за юридических ограничений.

В-третьих, существует набор ожиданий, которые не прописаны в письменном виде, но вам все равно необходимо рассматривать их как часть вашего проекта, поскольку некоторые из этих ожиданий могут быть реализованы. ожидания ваших management или совета директоров, или других заинтересованных сторон. каким-то образом участвует в проекте. 

Каковы требования и что такое спецификации?

Давайте попробуем теперь лучше определить, что такое требования, а что такое спецификации. Это технические термины, которые могут быть знакомы некоторым из вас, но я приведу вам несколько примеров, чтобы вы могли закрепить их в своей памяти с помощью примеров.

Примеры Требования: 

• Возможность создания учетной записи, 
• Возможность выезда в качестве гостя, 
• Возможность оплаты в рассрочку вместо одной транзакции, 
• Возможность выбора различных вариантов доставки, 
• Возможность фильтровать только определенные размеры во время поиска, 
• Возможность поиска по ключевому слову с помощью инструмента поиска.
• Видимость стоимости доставки и налогов во время оформления заказа

Примеры технических характеристик: 

• Совместимость с устройствами и операционными системами 
• Размеры изображений, баннеров 
• Частотный обмен данными между системами
• Формат и количество результатов на странице

Где указаны технические требования и ожидания?

Эти элементы обычно записываются в один или несколько проектных документов. 

Наиболее часто используемым документом является Документ с требованиями к продукту, также называемый PRD., который обычно принадлежит и пишется менеджером, ответственным за e-commerce Платформа. Если документ «Требования к продукту» недоступен мы можем записать Требования и Спецификации непосредственно в План проекта, наконец, мы можем найти часть спецификаций и требований к качеству также в План качества. 

План качества в основном служит для организации тестов качества и процесса обеспечения качества в целом, но он также может содержать некоторые конкретные требования к качеству цифрового продукта. Например, план качества может содержать ссылки на конкретные тесты безопасности, которые необходимо провести. Например, когда я работал поставщиком услуг для крупной компании по производству спортивной одежды, это было похоже на ситуацию, когда я работал brand и я занимался их разработкой ecommerce веб-сайта, мне пришлось координировать тесты безопасности на наших серверах, чтобы они соответствовали стандартам безопасности клиента. 

Тесты, выходящие за рамки

С другой стороны, в плане качества может быть указано, какие тесты выходят за рамки проекта. Например, если вы не планируете отправлять в Австралию свой ecommerce, вам не следует тратить время и силы на разработку и тестирование каких-либо спецификаций для этой конкретной страны. 

Варфреймы и композиции

План качества может ссылаться на другие документы для определения спецификаций и требований. например, план качества может относиться к макетам Wireframes или Comps для всего, что связано с качеством дизайна и внешним видом веб-сайта в целом.

Эти документы важны, поскольку они будут использоваться вашими разработчиками в качестве справочника по тому, что им нужно разработать и достичь в своей работе. 

Помимо требований, план качества описывает тесты, которые необходимо провести, когда они будут проводиться в ходе проекта и во время поставки продукта, а также как они будут выполняться.

Критерии GO-LIVE

План качества также должен содержать критерии GO-LIVE. Критерии GO-LIVE — это набор условий, которые должны быть выполнены для запуска проекта. Примером критериев GO-LIVE являются максимальное количество ошибок, разрешенных на веб-сайте Live, и их серьезность, например, в плане качества может быть указано, что проект запускается только в том случае, если на момент запуска на веб-сайте имеется не более 10 ошибок.

Наконец, план качества содержит процедуры, которым команда проекта должна будет следовать в процессе обеспечения качества, например, кто и за что отвечает за тестирование, как использовать инструмент отслеживания ошибок, как классифицировать ошибки в зависимости от их серьезности. .

Какие типы тестов нам нужно провести?

Виды тестов обеспечения качества

Теперь давайте подробнее рассмотрим, какие тесты следует создавать. brands focus on

Модные компании могут проводить несколько типов тестов, чтобы убедиться, что коммерческая платформа работает в соответствии с ожиданиями.

Тест дыма

Smoke Test — простой тест, целью которого является проверка основных функций. цифрового продукта. Эти тесты обычно проводятся разработчиками во время проекта, чтобы убедиться, что основные функции программного обеспечения работают. Это простой тест, заключающийся в проверке основных функций программы. имитируя обычного пользователя или потенциального клиента, которому необходимо выполнить задачу на платформеНапример, если вы внедряете функцию текстового поиска на свой веб-сайт, то для проверки работоспособности системы (smock test) вам нужно будет ввести несколько ключевых слов, относящихся к вашей тематике. brand Например, введите в поиск «красная кожаная сумка» и проверьте, насколько результат соответствует действительности. На этом этапе, например, графический дизайн может быть неактуален, цель — получить согласованные результаты. Если вы ищете «красная кожаная сумка», а в результате получаете синюю футболку, значит, тест на соответствие действительности провален.    

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

Интеграционный тест – это специальный тест, проверить правильность прохождения данных из одной системы в другуюНапример, передача данных с платформы электронной коммерции в ERP-систему компании, а также передача данных из ERP-системы на склад. management Система или из ecommerce-платформа к платформе бизнес-аналитики. Мы можем считать этот тест успешным, если данные передаются корректно из одной системы в другую, без потери данных и в ожидаемые сроки. 

Приемочный тест пользователя

Приемочное тестирование пользователя, или UAT, обычно проводится совместно с присутствием Клиента и Разработчика. 

Во время UAT клиент запускает все возможные варианты использования, например. найдите продукт, добавьте продукт в список желаний, переместите продукт из списка желаний в корзину, завершите процесс оформления заказа, чтобы убедиться, что все работает как положено. 

Эти тесты обычно проводятся ближе к концу этапа разработки, когда продукт почти готов к доставке клиенту. Обычно результатом этих тестов является список ошибок, запрошенных Клиентом, которые будут исправлены Разработчиком.

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

Четвертый тип тестирования — регрессионное тестирование. Регрессионное тестирование гарантирует, что приложение продолжает работать должным образом после любых изменений кода, обновлений или выпусков других функций на платформе. Регрессия обеспечивает общую стабильность платформы.

Эти тесты должны проводиться командой качества каждый раз, когда на веб-сайте появляется новая версия.,  чтобы убедиться, что все ранее работавшие функции по-прежнему работают правильно. 

Например, если вы разрабатываете новую платежную систему, скажем, вы разрабатываете оплату в рассрочку в своей кассе, и во время развертывания этой новой функции вы нарушаете оплату кредитными картами, которая работала нормально раньше, поэтому мы ввели ошибка в ранее работавшей функции, в данном случае речь идет о регрессии.

Процессы тестирования и исправления ошибок

 Мы поговорили о роли руководителя отдела обеспечения качества, теперь давайте посмотрим, как все участники процесса обеспечения качества взаимодействуют друг с другом.

Первый шаг происходит, когда ошибка впервые обнаруживается; тестировщик, либо член проектной группы, либо профессиональный тестировщик, выполняющий тестовый сценарий, находит ошибку. Например, тестовый сценарий может сказать: добавьте продукт в список желаний, а затем переместите продукт из списка желаний в корзину. 

Если тестировщик не может добавить продукт в список желаний или переместить продукт из списка желаний в корзину покупок, он сообщит об ошибке и откроет заявку в инструменте отслеживания ошибок. Когда тестировщик сообщает об ошибке в системе, он или она также должен добавить некоторые спецификации, например инструкции по воспроизведению ошибки., это поможет разработчику быстро воспроизвести условия обнаружения ошибки. Тестер также обычно сообщает, какое устройство и какая операционная система использовались в момент обнаружения ошибки. Например, я использовал Safari на iPad Pro.

На втором этапе  Руководитель отдела контроля качества проверит всю имеющуюся информацию об ошибке и дважды проверит, что об ошибке еще не сообщалось.. Это важно, иначе в инструменте отслеживания ошибок могут появиться дублирующиеся ошибки.

Затем руководитель отдела контроля качества поручит работу над проблемой члену команды. Обратите внимание, что на данный момент я использую ошибку и проблему как синонимы.

На шаге 3 разработчик исправляет проблему в среде разработки и помечает ее как исправленную. 

Обратите внимание, что разработчик помечает ошибку как исправленную или решенную, но он/она не закрывает заявку в инструменте отслеживания ошибок. Только человек, сообщивший об ошибке, или руководитель отдела контроля качества должен пометить проблему как закрытую.

На последнем этапе человек, сообщивший о проблеме, или руководитель отдела контроля качества проверит, действительно ли ошибка исправлена ​​на платформе, и отметит проблему как близкую в инструменте отслеживания ошибок.

Краткое описание этапов тестирования UAT

1. Тестировщик пытается выполнить задачу на веб-сайте, например. добавить товар в список желаний
2. Если тестировщик не может выполнить задачу, он сообщает об ошибке в инструменте отслеживания ошибок.
3. Руководитель отдела контроля качества проверяет наличие ошибки, т. е. об ошибке еще никто не сообщил.
4. Руководитель контроля качества поручает исправить ошибку члену команды.
5. Член команды работает над ошибкой и помечает ее как исправленную, когда проблема решена.
6. Руководитель отдела контроля качества или тестировщик еще раз проверяют функцию, чтобы убедиться, что она работает.
7. Ошибка окончательно закрыта руководителем контроля качества или тестировщиком.

КОЛОНКИ