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

Digital Fashion Academy의 이벤트
2023년 4월 18일

여기에서 웨비나를 시청하세요:

개요

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

요약

Enrico Fantaguzzi에 가입하세요 (1티피1티) 및 로렌조 파네티(추측하다) 그들이 제시하는 것처럼 모범 사례 ~을 위한 품질 관리 패션 및 럭셔리 부문의 전자상거래 사이트.

이 웹 세미나에서는 다음 내용을 설명합니다. 핵심 개념 전자상거래 프로젝트의 품질 보증 관리를 위해 기준 프로세스 대기업에서 사용되는 서비스 수준 계약 (SLA)는 계약 정의 과정에서 개발 기관과 공유됩니다.

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

• 패션 전자상거래에서는 품질 보증이 필수적입니다. 보장하다 성공 사이트 측면에서 변환 비율 그리고 제어 프로젝트 소송 비용.

"종종 전자상거래 사이트 개발 프로젝트가 끝날 때 발생하는 일은 프로젝트의 성공과 개발자와 고객 간의 관계를 훼손할 위험이 있는 수많은 결함이 발견된다는 것입니다. 품질 보증을 올바르게 관리하면 고객의 만족, 최고의 사용자 경험, 고객-공급업체 관계의 올바른 관리를 얻을 수 있습니다."

엔리코 판타구치

주제

• 전자상거래 사이트의 품질 기준 정의
• 배송 후 제품 보증
• 제품 테스트 방법론 및 버그 해결 관리
• 버그 추적 및 이슈 추적 도구

성적 증명서

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

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

그래서 오늘 우리는 다음에 대해 이야기할 것입니다. 품질 보증의 중요성 그리고 그것이 성공에 왜 중요한가 패션 전자상거래의. 

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

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

그렇다면 패션 전자상거래에서 품질 보증의 목적은 무엇일까요? 

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

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

엔리코 판타구치

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

그 위에, 당신은 다음을 준수해야 할 수도 있습니다. 법적 제약으로 인해 귀사에 구속력이 있는 요구 사항.

셋째, 기록되지는 않았지만 프로젝트의 일부로 고려해야 하는 기대 사항이 있습니다. 이러한 기대 사항 중 일부는 다음과 같을 수 있습니다. 귀하의 경영진 또는 이사회 또는 기타 이해 관계자의 기대 어떤 식으로든 프로젝트에 관여했다. 

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

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

예시 요구 사항: 

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

예시 사양: 

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

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

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

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

품질 계획은 주로 품질 테스트와 품질 보증 프로세스를 전반적으로 구성하는 데 사용되지만 디지털 제품의 품질에 대한 몇 가지 특정 요구 사항을 포함할 수도 있습니다. 예를 들어, 품질 계획은 수행해야 하는 특정 보안 테스트를 참조할 수 있습니다. 예를 들어, 대형 스포츠웨어 브랜드의 서비스 공급업체로 일하면서 전자 상거래 웹사이트를 개발할 때, 클라이언트의 보안 표준을 충족하도록 서버에서 보안 테스트를 조정해야 했습니다. 

범위 밖 테스트

반면, 품질 계획은 프로젝트 범위를 벗어나는 테스트를 나타낼 수 있습니다. 예를 들어, 전자 상거래를 통해 호주로 상품을 배송할 계획이 없다면, 해당 국가에 대한 사양을 개발하고 테스트하는 데 시간과 노력을 허비해서는 안 됩니다. 

와이어프레임과 컴포지션

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

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

요구 사항 외에도 품질 계획에는 수행해야 할 테스트, 프로젝트 진행 중 및 제품 제공 중에 테스트를 언제 수행할지, 테스트를 어떻게 수행할지 설명되어 있습니다.

GO-LIVE 기준

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

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

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

품질 보증 테스트 유형

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

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

연기 테스트

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

통합 테스트

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

사용자 수용 테스트

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

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

이러한 테스트는 일반적으로 개발 단계가 끝나갈 무렵, 즉 제품이 클라이언트에게 전달될 준비가 거의 되었을 때 수행됩니다. 일반적으로 이러한 테스트의 출력은 클라이언트가 요청한 버그 목록이며 개발자가 이를 수정합니다.

회귀 테스트

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

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

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

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

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

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

테스터가 위시리스트에 제품을 추가하지 못하거나 위시리스트에서 쇼핑 카트로 제품을 옮기지 못하는 경우 테스터는 버그를 보고하고 버그 추적 도구에서 티켓을 개설합니다. 테스터가 시스템 버그를 보고할 때 버그를 재현하기 위한 지침과 같은 몇 가지 사양도 추가해야 합니다., 이는 개발자가 버그가 발견되었을 때의 상황을 빠르게 재현하는 데 도움이 됩니다. 테스터는 또한 일반적으로 버그가 발견되었을 때 어떤 장치와 어떤 운영 체제가 사용되었는지 보고합니다. 예를 들어 저는 iPad Pro에서 Safari를 사용하고 있었습니다.

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

그러면 QA 책임자가 버그를 팀원에게 할당하여 문제를 해결합니다. 지금은 버그와 문제를 동의어로 사용하고 있다는 점에 유의하세요.

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

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

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

UAT 테스트 단계 요약

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

스피커