00131 20150429 결함 처리 프로세스 - AngryQA/blog GitHub Wiki
결함 처리 프로세스
AngryQA | 2015-04-29 수요일 오후 3:9 | QA/QA 프로세스 | 원본
참고 문헌 : 조대협의 서버 사이드 소프트웨어 개발과 테스트
테스트 팀과 개발팀의 협업에서 가장 중요한 결함 처리 프로세스에 대해 포스팅하도록 하겠습니다 :D
전체적인 프로세스 예시 > 각 스텝 설명 순
결함 처리 프로세스 예시
**결함 보고 → 결함 접수 → 결함 지정 → 결함 수정 **
→** 결함 상태를 '해결됨'으로 변경 → 확인 테스트&테스트 케이스 추가 ****→ **결함 처리 종료
아마 대부분의 회사에서 위와 같은 방식으로 진행하고 있을 것으로 생각됩니다.
가장 일반적인 프로세스니까요 ㅋㅋ
각각의 스텝을 설명하기 이전에 간단히 좋은 프로세스에 대해서 설명하도록 하겠습니다.
좋은 프로세스는 복잡하지 않아야 합니다.
왜?
복잡한 프로세스는 적용이 어려우며, 다수의 사람을 교육 & 적응 시키는데 너무 많은 시간을 소모하기 때문입니다 -_-;;
저 같은 경우에도 여러 번.. 이런저런 프로세스를 만들고 도입하려다 조용히 사라진 경우가 몇 있습니다...
단순한 프로세스를 만들기 위해서는 먼저 제품, 회사의 성격, 사용자, 서비스의 형태 등을 고려 후
위 프로세스의 흐름에 맞춰 변형해서 프로세스를 다시 수립하기 바랍니다 :D
다음은 각 스텝을 설명하도록 하겠습니다.
Ⅰ. 결함 보고
테스터가 발견한 이슈를 BTS에 등록하는 단계 입니다.
프로세스의 시작 부분이죠
기본적으로 발생 이슈에 대한
재현 절차 / 기대 결과 / 현재 결과 / 특이사항 / 로그 / 스크린샷 / 동영상을 개발자에게 전달하는 스텝입니다.
**※가장 중요하게 생각하는 단계입니다. **
이 단계에서 정보가 충분하게 개발자에게 전달되지 않을 경우
**여러 번 대화가 핑퐁 치면서 딜레이가 발생하게 됩니다. **
이슈를 보고할 경우에는 개발자가 한 번에 보고 이해 가능하도록 작성합시다!!
↓나쁜 이슈 보고의 예 ㅋㅋㅋ
ⅱ. 결함 접수
개발팀 리더가 자신의 팀에게 할당된 결함을 확인!
ⅲ. 결함 지정
개발팀 리더가 결함을 일정과 리소스에 따라, 개발자에게 할당합니다 :D
ⅳ. 결함 수정
결함을 할당받은 개발자는 테스트 엔지니어와 함께 결함을 재현하고 추적하여 수정합니다
ⅴ. 결함 처리 상태를 '해결됨'으로 변경
결함의 상태를 '해결됨'으로 변경 후, 테스트 엔지니어에게 다시 할당합니다.
ⅵ. 확인 테스트 & 테스트 케이스 추가
테스트 엔지니어는 해결된 이슈를 다시 테스트하여 확인하고, 테스트 케이스를 보강합니다.
※테스트 케이스 보강!!!
다음 차 테스트에서 유사한 이슈를 발생 시 바로 발견할 수 있는 아주 좋은 수단(?)입니다.
전 보강을 하지 않아서 자주 비슷한 이슈를 놓치는 경우가 있습니다 ㅠ_ㅠ
다들 테스트 케이스 보강하여 유사 이슈 모두 잡으시기 바랍니다 ㅋㅋ
ⅶ. 결함 처리 종료
문제가 없을 경우 해당 결함을 닫는다.
문제가 있다면 결함 담당자에게 재할당 후 결함 수정 단계부터 다시 수행합니다:D
이상 결함 처리 프로세스였습니다.
모두 멋진 프로세스 만드세요~:)