QA - Test Case를 통한 QA 테스트

개요

이번에 회사에서 진행하던 프로젝트가 마지막 단계에 왔다. 이제 배포를 하기 전에 QA를 진행해야 했다. 하지만 우리 조직에는 체계화 및 구조적으로 QA를 진행하는 문화가 없었다. 당연히 QA 조직도 없다. 그래서 직접 QA 테스트를 진행하기로 했다. 본 글에 내가 QA테스트를 작성했던 내용을 남겨둔다. 부족한 부분이나 잘못된 내용이 있다면 언제든 댓글을 남겨주세요! 

QA 테스트(Quality Assurance)라고 하면 제조업 분야에서 기계 성능을 테스트하는 QA를 생각할 수 있다. IT에서의 QA는 서비스 기획 단계부터 참여하여 개발, 테스트 그리고 출시까지의 모든 과정에서 잠재적인 품질 리스크를 프로젝트 참여자들과 공유하고 해당 서비스가 사용자의 요구사항에 충족하는지에 대한 관리하는 활동이라고 볼 수 있다.

 

Test Case를 통해 QA를 하는 이유

1. 체계적인 접근
   • Test Case는 테스트를 체계적으로 진행할 수 있도록 구조화된 방법을 제공한다. 테스트할 항목, 입력 값, 기대 결과 등을 정ㅇ의해서 체계적인 테스트를 가능하게 해주기 때문이다. 그리고 각 테스트 케이스가 작성되어 있으면 오류가 발생했을 때도 추적하기 훨씬 쉬워진다.
2. 명확한 기준
   • 테스트 케이스는 명확한 기대 결과를 정의하여 실제 결과와 비교하기 때문에 오류를 쉽게 확인할 수 있다.
3. 효율성 증대:
   • 잘 작성된 테스트 케이스는 추후 테스트 자동화를 해야할 때 사용될 수 있어 테스트 효율성을 높여준다.
   • 기능이 업데이트되거나 수정되었을 때 동일한 테스트 케이스를 사용하여 동일하게 테스트를 진행할 수 있게 해준다.

 

Test Case 작성 방법

1. 기획서를 중심으로 사용자의 시나리오를 구조화한다.
2. 어떤 기능을 테스트할지 결정하고 테스트 시나리오를 작성한다.
3. 테스트 케이스의 액션, 기대 결과 등의 내용을 명확하게 정의한다.
4. 테스트 진행 결과를 작성한다.

 

Test Case 구성 요소

1. 테스트 케이스 ID
   • 각 테스트 케이스의 고유 식별자
   • ex) TC001
2. 화면
   • 화면 경로와 순서를 알려준다.
   • ex) 상품 상세 > 선물하기 > 선물주문
3. 액션
   • 사용자가 취할 행동의 시나리오를 나타낸다. 
   • ex) 선물 메시지 200자 이상 작성
4. 기대 결과
   • 사용자의 액션에 대한 기대 결과를 작성한다.
   • ex) 200자를 초과 후 입력되는 텍스트는 작성되지 않음
5. 성공 여부
   • 테스트 결과를 저장한다. 테스트 결과는 PASS, FAIL, HOLD로 분류했다.
   • MOBILE(안드로이드, IOS), PC 기종 별로 테스트가 진행되어야 하기 때문에 각 기종 별로 성공여부 컬럼을 만들었다.
6. 비고
   • 이슈사항이나 실패했을 때의 정보를 작성하도록 했다.
7. 확인자
   • 테스트를 진행한 사람의 이름을 작성했다.
8. 확인일자
   • 해당 기능을 테스트한 일자를 작성했다.

 

작성된 Test Case 예시

 

마무리

예시는 2개의 케이스지만 실제로는 150개 정도의 테스트 케이스를 작성하여 테스트를 진행했다.

혼자 준비하며 진행하다보니 시간도 많이 들어갔었다. 나중에는 QA테스트 자동화하는 작업을 해보고 싶다. 

 

참조

아기자기한 프로덕트 팀의 Test Case 도입기 | 요즘IT

테스트는 누구나 할 수 있지만, QA는 준비된 자만이 할 수 있습니다.