UXUI 디자인 입문 디자인 QA 3-5

QA란?

Quality assurance

 

제품이 출시되기전에 기능을 테스트.

기획한대로 잘 구현되었는지, 회사에서 원하는 품질을 충족하였는지.

기능을 만든 담당자는 QA를 한다.

 

☑️ QA의 목적

• 사용자가 제품을 이용할 수 없을 만큼의 치명적인 결함은 없는지 확인합니다.
• 조직 전체에서 기대하는 수준의 품질이 갖춰졌는지 확인합니다.
• Product Spec 문서에서 작성했던 명세대로 잘 구현되었는지 확인합니다.
• 특수한 상황에서 예상하지 못한 대로 동작하지는 않는지 확인합니다.
• 전반적인 UX가 사용하기 편리한지 확인합니다.

QA 문서

체크리스트(CL) 가장 간단한버전의  QA문서

• 예/아니요, 혹은 Pass/Fail로 답변할 수 있는 확인 성격의 항목을 나열한 목록입니다.
• 기능이나 개선 범위가 넓지 않을 때 사용합니다.

💡 예를 들어볼게요

→ 다음과 같이 가벼운 질문으로만 확인할 수 있는 작은 배포 때 쓰기 좋아요.

• 버튼을 눌렀을 때 색상이 변하나요?
• 버튼을 눌렀을 때 A 페이지로 이동하나요? 

 

테스트 시나리오(TS)

• 기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서입니다.
• 사용자가 기능을 사용하면서 경험하게 되는 과정을 상세하게 적습니다.

 

💡 예를 들어볼게요

→  회원가입 flow를 테스트하는 상황

• 회원가입은 카카오톡, 네이버, 일반 회원가입 3가지가 있다.
• 일반 회원가입의 경우 이메일, 비밀번호, 이름을 입력한다.
• 올바르지 않은 정보를 입력할 경우 텍스트 필드 아래에 얼럿 메시지가 노출된다.
• CTA 버튼을 누르면 회원가입 요청을 보낸다. 

 

테스트 케이스(TC)

• 특정 조건에서 요구 사항을 충족하는지 확인하기 위해 여러가지 케이스를 작성한 문서입니다.
• 특정 조건 아래의 환경을 테스트하는 것이기 때문에 특정 조건, 테스트 범위, 케이스, 기댓값, 테스트 환경 등을 상세하게 적어야 합니다.

💡 예를 들어볼게요

→  회원가입 flow를 테스트하는 상황

 

디자인 QA

QA는 기능QA와 디자인QA가 있다.

디자인화면과 개발화면을 비교해서 보게됨.

담당엔지니어에게 수정 요청.

디자인 QA에서 발견한 이슈 공유하기

업무티켓 지라. 담당자 업무배정

 

이슈의 중요도 정의하기

**HIGHEST**

• 당장 대응이 필요할 정도로 주요 기능에 문제가 있는 경우

**HIGH**

• 사용자가 행동을 완수할 수 없는 이슈
• 기능상 사용성에 치명적인 문제가 될 수 있는 것

**MEDIUM**

• 사용자가 행동을 완수하는 데 어려움을 겪을 수 있는 문제
• 단계를 넘어가는 데에 어려움이 없으나 기획이나 피그마 디자인 화면과 다르게 적용된 것
• 사용자가 상황을 제대로 이해하기에 어려움이 있는 것 (예시: 네트워크 오류로 팝업이 떠야 하는 상황에서 알 수 없는 오류 팝업이 뜨는 이슈)
• 시각적으로 오류가 난 것처럼 보이는 것

**LOW**

• 기능상 문제가 없는 것
• 피그마 화면과는 다르지만, 맥락상 과정을 이해하기에 어려움이 없는 것
• 오픈 후 수정되어도 문제없는 디테일한 부분

**LOWEST**

• 단순 의견 정도의 레벨로 급하게 반영되지 않아도 될 이슈

 

업무의 효율성을 위해서 난이도를 정함.