QA 진행과 TC 작성 할 때 어떠한 목적 및 소통 진행해야 할지 들었던 강의 노트 정리 하고자 한다.
왜 QA인가
- 프로젝트 관리란 우리의 계획(일정,리소스)과 기획(해결 방안)이 약속 대로 문제 없이 잘 되도록 챙기는 과정이라면 QA란 기획한 내용과 품질의 제품이 나왔는지, 우리의 목표를 달성하거나 가설을 검증할 수 있는지 확인하는 과정이다.
왜 Test Case인가
Test case란?
- 특정한 프로그램 부분 및 경로를 실행해보거나 요구사항에 준수하는 지를 확인하기 위해 개발된 입력 값, 실행 조건, 예상된 결과 테스트하려는 시스템이 수행해야 하는 Action들로 구성되는 일련의 단계라고 볼 수 있다.
Test case 제작을 하므로써 아래와 같은 이슈 보완 목적이다.
- 다양한 종류, 숫자 사용자
- 다양하고 복합다단한 서비스의 사용 흐름, 시나리오 대비
- 또 만다는 과정에서 휴먼 에러 감안
- 특히나 결제, 주문, 배송 처리 등등 이슈가 생길 시 곤란한 경우 만들지 않고자 하는 경우
Test Case란 무엇인가?
- TC 목적
- 기획의 핵심/주요한 부분
- 복잡한 걸 구조화
- 전부 누락 없이 정리한 문서
= 즉 기획한 제품을 빠짐없이 검수할 수 있게 해주는 문서라고 볼 수 있다.
Test Case 작성시 기준 포인트
- 상/하위 계층 구조(Depth)
1)무엇이 더 큰 ~ 상위 개념인지
2)순서상 무엇이 먼저 or 나중에 발생 - 누락 없이 & 겹침 없이 (MECE)
1)중복된 것은 없나?
2) 충족되었나? 빠트린 건 없나? - 발생해야 하는 결과
1) Case(경우) / When(~할 때)/If(~ 하면)
2) Then 기대하는 발생 결과
개발자와 소통하기 좋은 TC란?
QA는 여러 사람들과 커뮤니케이션이 중요하다. 특히나 이슈가 발생하였을 때 개발자와는 소통이은 필수다. 아래와 같은 항목을 체크해서 서로 소통하는 데에 있어서 문제가 없어야 한다.
- 어디가(언제, 어떤 경우에) 문제인지
- 그래서 구체적으로 뭐가 문제인지
- 어떤 환경에서 문제인지
- 문제 현상을 적어둔 곳 있는지
마지막 문제 현상을 적어둔 곳이 있는지에 대한 포인트는 TC라고 볼 수 있을 것 같다.
TC를 통해서 아래와 같은 항목 체크하여 전달해준다. (물론 TC뿐만 아니라 BTS에도 포함)
- Test case 번호
- 상/하위 계층 구조와 MECE를 잘 고려한 케이스인지
- TC 수행 결과
- TC 내 발생한 이슈
- 기타 테스트 관련 정보(테스트 일정, 수행한 사람, 수행한 환경)
그리고 마지막으로 이슈 제기 하기 전 참고해야 한다.
- 언제 한건지 > 이미 해결 되었는데, 혹시 이전 내역은 아닌지?
- 어떤 환경에서 한건지 > 혹시 진짜 특이한 환경이라서 재현 안되는 건 아닌지?
- 누가 한건지 > 관련해서 공유나 논의는 누구랑 하면 되는 건지?
누구나 QA에 참여할 수 있는 TC란?
아래와 같이 제품 대상에 따라서 각각 구성원들 마다 이렇게 생각할 수 있다.
- 기획자 : 기획한대로 잘 구현되었나?
- 디자이너 : UX/UI 디자인 구현되었나?
- 개발 : 내가 짠 코드 잘 돌아가나?
- 운영 : 제품 사용이 잘 되나?
- CS : 제품 이슈가 없는건가?
그래서 TC 제작을 할 때 이런 점을 고려 해야 한다.
- 누구를 대상으로 어떤 문제를 해결하는 제품 또는 기능(의 개선 또는 추가)인지
- 그 문제를 해결하기 위해 핵심적으로 추가되거나 변경되는 사항은 무엇인지
- 이에 관련된 세부 사항 중 운영, CS 등 QA에 참여하는 이들이 주로 다루거나 궁굼해할 사항은 무엇인지
- 사용자의 입장에서 작성되었는지
- 제품 팀에서만 사용하는 용어나 개념은 아닌지
- 웹/앱 서비스에 대해서 잘 모르는 일반인들도 이해 할 수 있는 용어인지
- 언제, 어디에서, 무엇을 해야하고 + 그 결과가 무엇이어야 하는지 명확해야 한다.
애자일 팀의 TC란?
작성 진행 시 아래와 같은 조건을 생각해봐야 한다.
1. 타깃 고객
2. 타깃 고객의 pain point
3. 제품의 vp
4. 성공의 정의
5. kpi
6. user stroy (when, where, how)
그리고 User story 바탕으로 작성 마무리 되었을 때 이를 공유하고 이에 대해 팀이 함께 검토한 세부사항과 예외사항을 추가해 최종 마무리 될 때까지 TC는 지속 업데이트되어야 한다.
TC 한계
무조건 TC가 다 맞다는 건 아니다. 아래와 같은 단점이 있기 때문에 보완을 해야 한다.
- 기획과 관련 없는 부분은 미작성
- 기획과 관련 없지만 코드/소스 연관 있음
- 인프라, 기술 이슈 모르거나 예측 못 함
- 복잡하고 많아서 작성한 사람 헷갈리거나 빠트림
QA는 왜 킥오프부터 참여를 해야 하는가
- 프로젝트 착수시 이해관계자들과 킥오프를 진행해 프로젝트의 목표와 과업범위에 대한 기대치와 이해도를 맞춘다.
- 제품과 관련된 모두가 참여하는 QA는 제품과 프로젝트에 대한 기대치와 이해도를 일치시켜서 불필요한 오해나 불만을 미리 방지하고 믿을 수 있는 제품을 만드는 데에 함께 기여하게 된다.
- 그렇기에 TC의 제작 또한 중요한 부분이라고 할 수 있다.
QA 진행 전 확인 해야 할 체크 리스트
- TC를 최종 확인 및 정리
- 배경과 목적,제품의 개요에 대해 설명
- 이슈가 있을 때 누구에게 전달해야 할지
= 무엇을 어떻게 테스트 해야 하며 누구와 어떻게 소통해야 하는가 - QA서버와 실서버의 연동/분리 여부 확인
= QA를 하기 위한 가상 제품 > 이상 없음 > 실제 고객에게 제공 제품으로 덮어짐 - 시나리오 맞는 계정 및 환경 세팅
단계적 & 누적하여 QA 진행
- 한번에 테스트 해야 할 것들이 비교적 적음(특정 기능 단위 또는 특정 분량)
- 이미 완료된 기능이 있다면 미리 테스트해 볼 수 있음
- 검수 결과 Fail 항목을 다음 스프린트의 과제로 반영하고 미리 해결해버릴 수 있음
- 1차 마무리 이후의 QA 기간이 줄어들게 됨
- 몇 번 누적해서 QA한만큼 놓친 게 있더라도 다시 발견할 기회가 있음
- 아직 구현되지 않은 부분은 패스 (의존적 성향)
= 구현된 부분에 대해서 단계적으로 N회에 걸쳐 누적으로 QA 진행
기능 외 탐색적 테스팅 진행
- 무조건 TC내에 있는 것만 테스트 하진 말아야 한다. 내가 제품 사용자(고객)이라고 생각해보고 써보면서 TC에서 발생 할 수 없었던 이슈 유형들도 확인 할 수 있다.
- 단, 예외적인 사항들은 확인하기 어려우나, 일부러 틀린 값을 만들어보고 의도와는 정 반대의 경우도 만들어보면서 시나리오 A를 확인하러 진입 및 확인, 구간에서 일부러 다른 요소 B,C,D,E 진행
- 이전에 구현한 것 & 이번 배포에 영향을 줄지도 모르는 것 = 눈에 보이는 대로 랜덤하게 확인해본다.
QA 결과를 바탕으로 프로젝트 관리
1) QA 결과로 프로젝트의 막바지 진척도와 잔여 업무를 파악한다.
- QA 결과 Fail 항목은 잔여 업무 사항
- 이전까지의 구현 일정, 속도를 비추어 봤을 때 QA 대응에 추가로 필요한 일정 짐작 가능
2) 이번 출시일에 무조건 출시되어야 하는 부분과 그렇지 않은 부분을 구분한다.
- 정말 이번 배포 일정에서 배포되어야 하는 항목 맞나
3) QA 후 발견한 Fail 항목에 대한 처리, 관리도 하나의 프로젝트다
- 촉박한 일정 내에서 꼼꼼하고 타이트한 진행을 위해선 QA 결과 대응도 하나의 프로젝트처럼 이해
참고
- 테스트케이스 정의 : http://blog.skby.net/%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BC%80%EC%9D%B4%EC%8A%A4-test-case/
- 초보 기획자/PM을 위한 Test Case 작성 및 QA 노하우 (인프런 강의)
