품질 보증이 패션 전자상거래에서 전환율을 개선하는 방법

이벤트 Digital Fashion Academy
4월 18th 2023

웹 세미나보기:

개요

제목 : 패션 전자상거래 전환율 향상을 위한 품질 보증
날짜: 4월 18일 화요일 오후 5시 30분(CET 로마)
DURATION : 1 시간
언어: 영어
바이낸스(BINANCE) 가입하기: 웨비나는 등록 시 무료입니다.

개요

Enrico Fantaguzzi에 가입하세요 (Digital Fashion Academy) 및 로렌조 파네티(추측하다) 그들이 제시하는 것처럼 모범 사례 을 통한 품질 관리 of e-commerce 패션 및 럭셔리 부문의 사이트.

이 웨비나에서는 다음 내용을 설명합니다. 주요 컨셉 품질 보증 관리를 위해 e-commerce 프로젝트에서 품질 프로세스 대기업에서 사용 서비스 수준 계약 (SLA)는 계약 정의 과정에서 개발 기관과 공유됩니다.

• 품질 보증: 는 다음을 보장하기 위한 활동 세트입니다. 결과 프로젝트의 충족 기대 의 고객Walk Through California 프로그램, 최종 사용자 제품과 모든 기준 에 의해 요구되는 규정.

• 인 패션 e-commerce, 품질 보증은 다음 두 가지 모두에 필수적입니다. 보증 성공 사이트 측면에서 변환 율 및에 제어 프로젝트 비용.

“종종 어떤 일이 끝날 때 일어나는가 e-commerce 현장 개발 프로젝트에서 발견되는 수많은 결함은 프로젝트의 성공과 개발자와 고객 간의 관계를 저해할 위험이 있습니다. 품질 보증의 올바른 관리를 통해 고객 만족, 최상의 사용자 경험, 그리고 고객-공급업체 관계의 올바른 관리를 달성할 수 있습니다.

엔리코 판타 구지

토픽

• 품질 기준의 정의 e-commerce 대지
• 배송 후 제품 보증
• 제품 테스트 방법론 및 버그 해결 관리
• 버그 추적 및 이슈 추적 도구

성적 증명서

이 e러닝 회사를 시작하기 전에 저는 소규모 브랜드부터 대규모 다국적 기업과 전자 소매업체에 이르기까지 패션 및 명품 기업에서 20년 이상 근무했습니다.

이 웨비나에서는 제가 패션 브랜드에서 일하면서 배운 것 중 일부를 여러분과 공유하려고 합니다. 오늘 여러분과 공유하는 경험은 대부분 패션 업계가 아닌 디지털 엔터테인먼트 부문에서 얻은 것입니다.

그래서 오늘은 다음에 대해 이야기해 보겠습니다. 품질 보증의 중요성 그리고 그것이 성공에 왜 중요한가 패션의 ecommerce. 

나는 당신에게 몇 가지 아이디어와 예를 제시할 것입니다 회사 내에서 품질 보증 프로세스를 구성하는 방법 

마지막으로, 여러분이 염두에 두어야 할 몇 가지 사항을 다루겠습니다. 공급업체 개발자 또는 시스템 통합자와 과제에 대해 논의하세요.협상 중에 무엇을 물어봐야 할지, 그리고 최종 결과가 기대에 부응하도록 계약서에 무엇을 포함해야 할지 알아보세요. 

그렇다면 패션의 품질 보증의 목적은 무엇인가? e-commerce? 

품질 보증의 목적은 무엇입니까?

품질 보증의 목적은 디지털 제품이 클라이언트(자신)와 디지털 제품의 최종 사용자(고객)의 기대에 부응하는지 확인하는 것입니다. 

엔리코 판타 구지

좀 더 구체적으로 말하자면 우리가 기대에 대해 이야기할 때 우리는 요구 사항과 사양에 대해 이야기합니다., 요구 사항 및 사양은 기대 사항과 다릅니다. 하나 이상의 문서에 명확하게 명시되고 기록됨. 

그 외에도 다음을 준수해야 할 수도 있습니다. 법적 제약으로 인해 회사에 구속력이 있는 요구 사항.

셋째, 작성되지 않은 기대사항이 있지만 이러한 기대사항 중 일부는 프로젝트의 일부로 간주해야 합니다. 경영진이나 이사회 또는 기타 이해 관계자의 기대 어떻게든 프로젝트에 관여했다. 

요구사항은 무엇이고, 사양은 무엇입니까?

이제 요구 사항과 사양이 무엇인지 더 잘 정의해 보겠습니다. 이는 일부 여러분에게 익숙할 수 있는 기술 용어이지만 예를 들어 여러분이 예를 통해 이를 기억할 수 있도록 몇 가지 예를 들어 드리겠습니다.

예시 요구 사항: 

• 계정을 생성할 수 있는 기능, 
• 게스트로 체크아웃 가능 
• 한 번의 거래 대신 분할 지불이 가능한 기능 
• 다양한 배송 옵션 중에서 선택할 수 있는 기능 
• 검색 중 특정 크기만 필터링하는 기능 
• 검색 도구를 사용하여 키워드를 검색하는 기능
• 결제 과정에서 배송비 및 세금 표시

예시 사양: 

• 장치 및 운영 체제와의 호환성 
• 이미지, 배너 크기 
• 시스템 간 주파수 데이터 교환
• 페이지당 결과의 형식과 수

요구사항 사양과 기대사항은 어디에 명시되어 있나요?

이러한 요소는 일반적으로 하나 이상의 프로젝트 문서에 기록됩니다. 

가장 자주 사용되는 문서는 다음과 같습니다. 제품 요구 사항 문서(PRD라고도 함)일반적으로 책임이 있는 관리자가 소유하고 작성합니다. e-commerce 플랫폼. 제품 요구 사항 문서를 사용할 수 없는 경우 우리는 요구 사항과 사양을 프로젝트 계획에 직접 작성할 수 있습니다.마지막으로 우리는 품질 사양 및 요구 사항의 일부를 다음에서도 찾을 수 있습니다. 품질 계획. 

품질 계획은 주로 품질 테스트 및 품질 보증 프로세스를 전반적으로 구성하는 데 사용되지만, 디지털 제품 품질에 대한 구체적인 요구 사항을 포함할 수도 있습니다. 예를 들어, 품질 계획은 수행해야 하는 특정 보안 테스트를 참조할 수 있습니다. 예를 들어, 저는 대형 스포츠웨어 브랜드의 서비스 공급업체로 일하면서 그들의 보안 솔루션을 개발하고 있었습니다. ecommerce 웹사이트를 운영하면서 클라이언트의 보안 기준을 충족시키기 위해 서버의 보안 테스트를 조정해야 했습니다. 

범위 밖 테스트

반면에 품질 계획은 프로젝트 범위를 벗어나는 테스트가 무엇인지 나타낼 수 있습니다. 예를 들어 호주로 배송할 계획이 없는 경우 ecommerce, 해당 국가에 대한 사양을 개발하고 테스트하는 데 시간과 에너지를 낭비해서는 안 됩니다. 

와이어프레임과 컴포지션

품질 계획은 사양 및 요구 사항에 대한 다른 문서를 참조할 수 있습니다. 예를 들어, 품질 계획은 전반적인 웹사이트의 디자인 품질 및 모양과 느낌과 관련된 모든 것에 대해 와이어프레임이나 컴포지션 모형을 참조할 수 있습니다.

이러한 문서는 개발자가 업무에서 개발하고 완수해야 할 사항에 대한 참고 자료로 사용되므로 중요합니다. 

품질 계획에는 요구 사항 외에도 수행해야 할 테스트, 프로젝트 진행 중 및 제품 제공 중에 테스트를 수행할 시기, 테스트를 수행하는 방법 등이 설명되어 있습니다.

GO-LIVE 기준

품질 계획에는 GO-LIVE 기준도 포함되어야 합니다. GO LIVE 기준은 프로젝트를 라이브로 진행하기 위해 충족해야 하는 조건 세트이며 GO LIVE 기준의 예는 다음과 같습니다. 라이브 웹사이트에서 허용되는 버그의 최대 수와 심각도예를 들어, 품질 계획에서는 웹사이트에 총 버그 수가 최대 10개 이하인 경우에만 프로젝트가 시작된다고 명시할 수 있습니다.

마지막으로 품질 계획에는 프로젝트 팀이 품질 보증 프로세스 동안 따라야 할 절차가 포함되어 있습니다. 예를 들어, 누가 무엇을 테스트할 책임이 있는지, 버그 추적 도구를 사용하는 방법, 버그를 심각도에 따라 분류하는 방법 등이 포함됩니다.

어떤 유형의 테스트를 실행해야 합니까?

품질 보증 테스트 유형

이제 패션 브랜드가 어떤 테스트에 집중해야 하는지 자세히 살펴보겠습니다.

패션 회사에서는 상거래 플랫폼이 기대에 맞게 작동하는지 확인하기 위해 여러 유형의 테스트를 실행할 수 있습니다.

연기 테스트

The 스모크 테스트는 핵심 기능을 확인하는 것을 목표로 하는 간단한 테스트입니다. 디지털 제품의 테스트입니다. 이러한 테스트는 일반적으로 개발자가 프로젝트 중에 소프트웨어의 핵심 기능이 제대로 작동하는지 확인하기 위해 수행합니다. 프로그램의 핵심 기능을 시험해 보는 간단한 테스트입니다. 플랫폼에서 작업을 완료해야 하는 일반 사용자 또는 잠재 고객을 시뮬레이션합니다.예를 들어, 웹사이트에 텍스트 검색 기능을 구현하는 경우, 스모크 테스트는 브랜드와 관련된 몇 가지 키워드(예: "빨간 가죽 가방")를 입력하고 결과가 일관성을 유지하는지 확인하는 것입니다. 이 단계에서는 그래픽 디자인이 관련성이 없을 수 있으므로, 일관된 결과를 얻는 것이 목표입니다. "빨간 가죽 가방"을 검색했는데 파란색 티셔츠가 검색 결과에 표시된다면 스모크 테스트는 실패한 것입니다.    

통합 테스트

통합 테스트는 특정 테스트입니다. 한 시스템에서 다른 시스템으로 데이터가 올바르게 전달되는지 확인합니다.예를 들어 전자상거래 플랫폼에서 회사의 ERP로, ERP에서 창고 관리 시스템으로 또는 ecommerce-플랫폼에서 비즈니스 인텔리전스 플랫폼으로. 데이터가 한 시스템에서 다른 시스템으로 데이터 손실 없이 예상 시간 내에 올바르게 전달되면 이 테스트가 성공한 것으로 간주할 수 있습니다. 

사용자 수용 테스트

사용자 수용 테스트 또는 UAT는 일반적으로 클라이언트와 개발자가 함께 참여하는 상태에서 수행됩니다. 

UAT 동안 클라이언트는 제품 검색, 위시리스트에 제품 추가, 위시리스트에서 장바구니로 제품 이동, 결제 프로세스 완료 등 가능한 모든 사용 사례를 실행하여 모든 것이 예상대로 작동하는지 확인합니다. 

이러한 테스트는 일반적으로 개발 단계의 마지막 단계, 즉 제품이 고객에게 인도될 준비가 거의 다 되었을 때 수행됩니다. 일반적으로 이 테스트의 결과는 고객이 요청한 버그 목록이며, 개발자가 이를 수정하게 됩니다.

회귀 검정

네 번째 유형의 테스트는 회귀 테스트입니다. 회귀 테스트는 플랫폼의 코드 변경, 업데이트 또는 다른 기능의 출시 후에도 애플리케이션이 예상대로 작동하는지 확인합니다. 회귀 테스트는 플랫폼의 전반적인 안정성을 보장합니다.

이러한 테스트는 웹사이트에 새로운 릴리스가 있을 때마다 품질 팀에서 수행해야 합니다.이전에 작동하던 모든 기능이 여전히 올바르게 작동하는지 확인합니다. 

예를 들어, 새로운 결제 시스템을 개발 중이라고 가정해 보겠습니다. 예를 들어, 결제 시스템에서 할부 결제 기능을 개발 중이고, 이 새로운 기능을 배포하는 동안 이전에는 잘 작동하던 신용카드 결제가 중단되었습니다. 이는 이전에 잘 작동하던 기능에 버그가 발생한 것이며, 이 경우 회귀에 대해 이야기하고 있는 것입니다.

버그 테스트 및 버그 수정 프로세스

 품질 보증 책임자의 역할에 대해 이야기했으니, 이제 품질 보증 프로세스에 참여하는 모든 주체가 서로 어떻게 상호 작용하는지 살펴보겠습니다.

첫 번째 단계는 버그가 처음 발견될 때 발생합니다. 테스터(프로젝트 팀원 또는 테스트 스크립트를 따르는 전문 테스터)가 버그를 발견합니다. 예를 들어, 테스트 스크립트는 "위시리스트에 제품을 추가한 다음 위시리스트에서 장바구니로 이동"이라고 할 수 있습니다. 

테스터가 위시리스트에 제품을 추가하거나 위시리스트에서 쇼핑 카트로 제품을 옮길 수 없는 경우 테스터는 버그를 보고하고 버그 추적 도구에서 티켓을 엽니다. 테스터가 시스템 버그를 보고할 때 버그를 재현하기 위한 지침과 같은 몇 가지 사양도 추가해야 합니다.이를 통해 개발자는 버그가 발견된 상황을 신속하게 재현할 수 있습니다. 테스터는 일반적으로 버그가 발견되었을 당시 사용 중이었던 기기와 운영 체제도 보고합니다. 예를 들어, 저는 iPad Pro에서 Safari를 사용하고 있었습니다.

두 번째 단계에서는 QA 책임자는 버그에 대해 사용 가능한 모든 정보를 확인하고 버그가 아직 보고되지 않았는지 다시 한 번 확인합니다.. 이 부분이 중요하지 않으면 버그 추적 도구에 중복된 버그가 나타날 수 있습니다.

QA 책임자는 해당 버그를 팀원에게 할당하여 문제를 해결합니다. 현재 저는 버그와 이슈를 동의어로 사용하고 있습니다.

3단계에서 개발자는 개발 환경에서 문제를 해결하고 문제가 해결되었다고 표시합니다. 

개발자는 버그를 수정됨 또는 해결됨으로 표시하지만 버그 추적 도구에서 티켓을 닫지 않습니다. 버그를 보고한 사람이나 QA 책임자만 문제를 닫힘으로 표시해야 합니다.

마지막 단계에서는 버그를 신고한 사람이나 QA 책임자가 플랫폼에서 버그가 실제로 수정되었는지 확인하고 버그 추적 도구에서 해당 문제를 종료로 표시합니다.

UAT 테스트 단계 요약

1. 테스터는 웹사이트에서 작업을 완료하려고 시도합니다(예: 위시리스트에 제품 추가)
2. 테스터가 작업을 완료할 수 없는 경우 버그 추적 도구에서 버그를 보고합니다.
3. QA 리더는 버그를 확인합니다. 즉, 버그가 다른 사람에 의해 보고되지 않았는지 확인합니다.
4. QA 리더는 버그를 팀원에게 할당하여 수정합니다.
5. 팀원은 버그를 처리하고 문제가 해결되면 수정된 것으로 표시합니다.
6. QA 리더 또는 테스터는 기능이 제대로 작동하는지 확인하기 위해 기능을 다시 테스트합니다.
7. 버그는 마침내 QA 리더 또는 테스터에 의해 닫혔습니다.

스피커