00166 20150917 Test 요청 시 Test 진행 방법작성중 - AngryQA/blog GitHub Wiki
Test 요청 시 Test 진행 방법(작성중)
AngryQA | 2015-09-17 목요일 오후 5:36 | QA/QA 프로세스 | 원본
Test 요청 시 Test 진행 방법
현재 우리팀에서 사용하고 있는 방식이 나쁘지는 않은거 같아 기록하려고 합니다.
**검증 요청 > 검증 환경 조사 & 일정 조율> 검증 시작 메일 **
> 테스트 케이스 제작 / 검증 시작 / 이슈보고 > 검증결과 보고 / 특이사항 전달(특이사항은 보고 메일 최상단에 위치)
위와 같은 순서로 작성할 것이며 잘못된 부분은 계속해서 업데이트 예정입니다.
1. 검증 요청
가장 중요한 단계입니다.
개발팀에서 검증을 요청하는 단계인데요
여기서 확식하게 개발팀으로부터 요구사항을 받아야 두번 세번 오가는 의사소통에서 오는 피로도를 줄일수 있습니다.
기본적으로는 검증 요청서를 작성하게 하는것이 좋으나, 모든 개발자들이 그 부분에대해서는 귀차니즘을 느끼는 관계로
최소한의 정보를 명시하도록 요구해야합니다.
※최소한의 정보
검증 목표 / 고객사 / 플랫폼 / 모듈버전 / App 버전 / 요청부서 / 요청자 / 검증자(Me) / 검증 시작일 / 검증 완료일 / 주요 검증 항목
| 사이트 | 플랫폼 | 모듈 버전 | 앱 버전 | 요청 부서 | 요청자 | 검증자 | 시작(예정)일 | 완료(예정)일 | 검증 항목 |
위와 같은 양식을 사전에 전달하면 개발자가 전달하기 편하겠죠? :)
2. 검증 환경 조사 & 일정 조율
최소한의 정보를 받았다면 이중에 모자르는 정보는 메일로 요구하기보다는 직접 컨택하여 수집하도록 합니다.
**※담당자가 자리를 비우는 등 메일로 핑퐁 칠 경우 이 단계에서 매우 많은 시간을 소모할수 있습니다.**직접가서 수집하세요~!
그리고 이 단계에서 일정도 조율하게 되는데
여기서는 개발과 검증의 커뮤니케이션이 중요합니다.
개발일정과 마찬가지로 정답이 없어요 잘 소통해서 서로 만족하는 일정을 맞춰주세요 :)
3. 검증 시작 메일
개발팀에게 검증 시작을 알리는 메일입니다.
어떤 방식으로 작성이되는가 하면 1과 2에서 수집한 정보를 바탕으로 시작 메일을 작성합니다.
ex)
안녕하세요
품질보증팀 xxx입니다.
아래와 같이 검증 시작하도록 하겠습니다.
| ID | 항목 | 프로젝트 | 버전 | 요청 부서 | 요청자 | 검증자 | 시작일 | 완료일 | 검증 목표 | | | | | | | | | | | | |
감사합니다.
**3. 검증 시작 / 이슈보고 / **테스트 케이스 제작
검증을 시작하고 이슈를 보고하는 단계입니다.
이슈를 자세하게 작성하여 개발자의 수정을 도와야하지요
잘못된 이슈보고는 개발자와 테스터간의 불신과 피로도를 증가시킵니다.
최소한 아래의 정보정도는 만들어서 보고를 하도록 합시다.
ex)
증상 작성
[재현절차] 1. 2. 3. 4.
[기대결과]
[현재결과]
확인부탁드립니다 :)
※증상에 대한 스크린샷 or 동영상 첨부
테스트 케이스는 검증 시작전에 작성할수도 있고 시작하면서 작성할 수도 있습니다.
테스트 케이스 작성 요령에는 다들 사용하는 방법이 있을꺼고, 제가 여기서 강조하고 싶은건
테스트 케이스에 이전 결과를 지우지 말고 기록해두자입니다.
전회의 검증결과는 기록해두면 검증대상의 상태를 더 정화하게 파악이 가능하기 때문입니다.
ex)
| 2차 9/4 | 3차 9/9 | 4차 9/11 | 5차 9/16 | | N/A | Pass | Pass | Pass |
4. 검증결과 보고 / 특이사항 전달(특이사항은 보고 메일 최상단에 위치)
테스트가 완료되면 테스트 결과는 보고하도록 합니다.
다들 사용하는 양식이 다르겠지만 제가 생각하는 베스트 보고메일 예를 첨부하면서 글을 마치도록 하겠습니다
**-. 수신 : **
안녕하세요.
품질보증팀 xxx입니다.
하기 검증 완료 되어 결과 전달 드립니다.
| ID | 항목 | 프로젝트 | 버전 | 요청 부서 | 요청자 | 검증자 | 시작일 | 완료일 | 검증 목표 | | | | | | | | | | | | |
※ 검증 특이 사항
1. 삭제 이슈
삭제가 정상진행되지 않습니다.
2. 설치 이슈
설치가 정상진행되지 않습니다.
3. 이슈 재확인
수정 사항은 결과 문서에 Release Note에 추가해두었습니다.
#130 / #25 / #26 / #25 / #30 이슈의 경우 XP에서만 발생하고 있습니다.
Win7에서 Closed 했던 이슈 이므로 다시 한번 확인이 필요합니다.
4. 2015-01-03-발견된 이슈(BTS이슈 페이지 링크)
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| 1. Test Information | | | | | | | | | | | Test Date | | | | | | | Tester | | | | | | | | | | | | | | | | OS | IE | 검증 항목 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2. Summary | | | | | | | | | | | | | | | Pass | Fail | Block | Completion Rate | | | | | | 36 | 4 | 4 | 81.8% | | | | | 36 | 4 | 4 | 81.8% | | | | | | 15 | 0 | 0 | 100.0% | | | | | 15 | 0 | 0 | 100.0% | | | | | | 3 | 0 | 4 | 42.9% | | | | | 3 | 0 | 4 | 42.9% | | | | | | 8 | 7 | 0 | 53.3% | | | | | 12 | 3 | 0 | 80.0% | | | | | | 0 | 1 | 5 | 0.0% | | | | | 3 | 3 | 0 | 50.0% | | -. Completion Rate : 현재까지 진행완료 부분에 대한 완성도 비율 | | | | | | | | | | | | | | | | | | | | | | | | 3. Issue List | | | | | | | | | | | 분류 | ID | 중요도(심각성) | 재발생 가능성 | 요약 | | | 22 | Major | 항상발생 | | | 25 | Major | 항상발생 | | | 24 | Minor | 항상발생 | | | 31 | Major | 항상발생 | | | 28 | Critical | 항상발생 | | | 26 | Trivial | 항상발생 | | | 25 | Major | 항상발생 | | | 30 | Major | 항상발생 | | | | 33 | Major | 항상발생 | | | | 131 | Critical | 항상발생 | | | 132 | Major | 항상발생 | | | 55 | Minor | 비주기적 | | | 53 | Trivial | 항상발생 | | | 50 | Critical | 항상발생 | | | 51 | 추가요구사항 | N/A | | | 54 | Trivial | 비주기적 | | | 60 | Major | 항상발생 | | | | 130 | Critical | 항상발생 | | | 129 | Critical | 항상발생 | | | 56 | Minor | 항상발생 | | | 57 | Minor | 항상발생 | | | 61 | Major | 항상발생 | | | 58 | Minor | 항상발생 | | | | | | | | | | | | | | | | | | | | | 4. Block List | | | | | | | | | | | Block Reason | Total Count | 상세 항목 | | | | 미구현 - 샘플 | 5 | | | | | 미구현 - 도움말 | 0 | | | | | 미구현 - 샘플 및 도움말 | 2 | | | | | 미구현 - 테스트 환경 | 1 | | | | | 기존 이슈로 확인 불가 | 5 | | | | | 확인 불가 | 0 | | | | | 기타 | 0 | | | | | 합계 | 13 | | | | |
-. 샘플에 항목 미구현 : 3차 검증전까지 수정 예정
이상입니다. 감사합니다.
|