dev + qa = hq sw dev + qa = hq sw

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 소프트웨어 결함 리포트 과정 분석 리포트 트랙 재테스트 종료(Close) 결함 트래킹 과정을 가지기 결함 리뷰 보드에 의해 다뤄지기 독립적으로 결정을 내리게 한다면, 실수가 생길 수 있는 환경을 만들게 됨 보드에 리드 테스터(또는 모든 테스터)를 포함하기 이해관계자, 개발 및 관리팀, 비지니스 분석과 데이터베이스팀도 포함된다 결함들에 진전이 있는지 확인하기 결함 재테스팅 개발팀이 결함을 가져갔고, 리서치했으며, 해결 표시를 하였다면 → 해결되었는지 재테스트 한다! 재테스트는 3가지의 결과를 가지고 있다 문제가 실제로 해결되었다 종..

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 소프트웨어 결함 리포트 구성요소 정보 식별 문제 설명 다양한 상태 지표(indicator) 주석(comments) 기타 정보 지원 정보 정보 식별 고유 번호 또는 ID 트레킹 시스템이 있을 경우, 자동으로 ID 부여 / 없을 경우, 수동으로 번호 지정 제출자 어떻게 제출자를 트랙할 건지에 따라 결정한다. 오픈 시스템인 경우, 사용자들도 제출자가 될 수 있음 제출 일자 결함이 얼마나 오래 됐는지 알 수 있음 이에 반하는 프로그램 또는 제품 제품 버전 또는 개정(revision) 문제 설명 제목 - 최소한의 단어수로 문제를 이해할 ..

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 테스팅 중 발견한 결함 반드시 기록! 결함은 [코드 작성 중, 정적 분석, 리뷰, 동적 테스팅, 제품 사용 중] 에 보고 가능 결함은 [코드나 운영 중인 시스템 & 요구사항, 사용자스토리 & 인수조건, 개발 문서, 테스트 문서, 사용자 메뉴얼, 설치 가이드]와 같은 문서에서 이슈로 보고 가능 소프트웨어 결함 보고 1. 중복되지 않는지 확인 → 이미 보고된 문제가 아닌지 (검색 가능 결함 트레킹 시스템) 2. 개발자와 상의 → 개발자가 결함 리포트에 입력하지 않도록 설득하지 못 하게 하기! 3. 시스템에 입력 → 결함 트레킹 시스템..

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 소프트웨어 결함에 대한 분석 근본 원인 찾기 누구의 잘못인지 찾기 - 테스트? 테스터? 제품? 테스트가 잘못되었는지? 테스트를 제대로 실행하지 않은 테스터의 잘못인지? 실행 시스템에 관해 잘못 추정했는지? 제품을 잘못 구축했는지? 검증(verification) 실패하면, "올바르게" 구축할 수 있는지? 검증(validation) 실패하면, "올바른" 제품을 구축할 수 있는지? 테스터는 분석 먼저! 개발자는 테스터들이 테스트 결함들을 사전 협의없이 넘겨주게 하지 말 것! 결함에 대한 분석이 포함되어있고, 몇몇의 작업자 오류들은 허용..

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 2가지 핵심적 이해 테스팅의 목적은 오류를 찾는 것만이 아닌 고치는 것이다 결함 리포트의 라이프 사이클과 구성요소를 이해하는 것은 개발과 테스팅 사이의 소통에 있어 도움이 된다 소프트웨어 결함 리포트의 목적 - 발생한 모든 부정적인 이벤트 정보를 개발자 & 기타 관계자에게 제공해 구체적 영향 식별, 재현 테스트로 문제 격리, 잠재 결함 수정, 필요에 따라 다른 문제 해결 방법 구상 - 테스트 관리자에게 작업산출물의 품질과 테스팅 영향을 추적할 방법을 제공 - 개발 & 테스트 프로세스 개선에 대한 아이디어 제공 소프트웨어 결함 리포..