live project bug tracking
이것은 우리의 ' 라이브 프로젝트에 대한 소프트웨어 테스트 교육 ”시리즈.
결함과 STLC의 테스트 실행 단계 완료를 표시하는 몇 가지 나머지 주제에 대한 내용이 될 것입니다.
에서 이전 기사 , 테스트 실행이 진행되는 동안 테스트 케이스의 예상 결과가 충족되지 않는 상황이 발생했습니다. 또한 탐색 테스트 중에 예상치 못한 동작을 확인했습니다.
이러한 편차가 발생하면 어떻게됩니까?
우리는 분명히 그것들을 기록하고 추적하여 이러한 편차가 처리되고 결국 AUT에서 수정되는지 확인해야합니다.
#1) 이러한 편차를 결함 / 버그 / 문제 / 사건 / 오류 / 결함이라고합니다.
#두) 다음 모든 경우는 결함으로 기록 될 수 있습니다.
- 누락 된 요구 사항
- 잘못 작동하는 요구 사항
- 추가 요구 사항
- 참조 문서 불일치
- 환경 관련 문제
- 개선 제안
#삼) 결함 기록은 대부분 Excel 시트 또는 결함 관리 소프트웨어 / 도구를 사용하여 수행됩니다. 도구를 통해 결함을 처리하는 방법에 대한 정보는 다음 링크를 사용해보십시오.
- HP ALM
- Atlassian JIRA
- 또한이 게시물을 참조하여 가장 인기있는 버그 추적 도구 마트에서.
학습 내용 :
- 효과적으로 결함을 기록하는 방법
- 버그 추적시 몇 가지 포인터
- 완벽한 결함 수명주기
- OrangeHRM 라이브 프로젝트 테스트를위한 종료 기준
- 테스트 지표
- 테스트 사인 오프 / 완료 보고서
- 추천 도서
효과적으로 결함을 기록하는 방법
이제 이전 기사에서 발생한 결함을 Excel 시트에 기록하는 방법을 살펴 보겠습니다. 항상 그렇듯이 표준 형식이나 템플릿을 선택하는 것이 중요합니다.
mysql 대 SQL 서버 대 오라클
일반적으로 다음 열은 결함 보고서의 일부입니다.
- 결함 ID : 고유 한 식별을 위해.
- 결함 설명 : 문제를 간략하게 설명하는 제목과 같습니다.
- AUT의 모듈 / 섹션 : 문제가 발생한 AUT 영역을 더 명확하게 나타 내기 위해 선택 사항입니다.
- 재현 단계 : 버그를 재현하기 위해 AUT에서 수행 할 정확한 작업 순서는 여기에 나열됩니다. 또한 입력 데이터가 문제에 특정한 경우 정보도 입력해야합니다.
- 심각성: 문제의 강도와 궁극적으로 이것이 AUT의 기능에 미칠 수있는 영향을 나타냅니다. 이 필드에 할당하는 방법과 할당 할 값에 대한 지침은 테스트 계획 문서에서 찾을 수 있습니다. 따라서 기사 3의 테스트 계획 문서 .
- 상태: 기사에서 더 자세히 설명합니다.
- 스크린 샷 : 오류 발생시 오류를 보여주는 애플리케이션의 스냅 샷입니다.
다음은 '필수'필드 중 일부입니다. 이 템플릿은 확장 (예 : 문제를보고 한 테스터의 이름 포함)하거나 계약 ( 예를 들어, 제거 된 모듈 이름) 필요에 따라.
위의 지침에 따라 위의 템플릿을 사용하면 샘플 결함 로그 / 보고서는 다음과 같습니다.
OrangeHRM Live 프로젝트에 대한 샘플 결함 보고서 :
=> 라이브 프로젝트 결함 보고서를 다운로드하려면 여기를 클릭하십시오.
다음은 qTest 테스트 관리 도구에서 생성 된 샘플 결함 보고서입니다. (확대하려면 이미지를 클릭하십시오)
결함을 기록하고 우리 자신에게만 보관할 때 결함은 좋지 않습니다. 관련 팀이 조치를 취하기 위해 올바른 순서로 배치해야합니다. 프로세스 – 할당 할 사람 또는 따라야 할 순서는 테스트 계획 문서에서도 찾을 수 있습니다. 대부분 유사합니다 (확대하려면 이미지를 클릭하십시오)
결함주기 :
위의 과정에서 버그는 수정을 위해 식별되는 과정에서 다른 사람과 다른 결정을 거치는 것을 알 수 있습니다. 특정 버그의 상태를 정확히 추적하고 투명성을 설정하기 위해 버그 보고서에 '상태'필드가 사용됩니다. 전체 프로세스를 '버그 수명주기'라고합니다. 모든 상태와 의미에 대한 자세한 내용은 다음을 참조하십시오. 버그 라이프 사이클 튜토리얼 .
버그 추적시 몇 가지 포인터
- 창의적인 팀 / 프로젝트 / AUT를 처음 사용하는 경우 항상 우리가 만난 문제에 대해 토론 동료와 함께 결함의 실제 원인에 대한 우리의 이해가 올바른지 확인하십시오.
- 에 모든 정보를 제공 문제를 재현하는 데 필요합니다. 상태가 '정보가 충분하지 않음'으로 설정된 테스트 팀으로 돌아 오는 결함은 우리에게 그다지 긍정적으로 반영되지 않습니다. 이 게시물을 확인하십시오 – '잘못된 버그'레이블없이 모든 버그를 해결하는 방법 .
- 새 문제를 만들기 전에 유사한 문제가 발생했는지 확인하십시오. '중복'문제 QA 팀에게도 안 좋은 소식입니다.
- 문제가있는 경우 무작위로 표시되고 문제를 재현 할 수있는 정확한 단계 / 상황을 알 수 없습니다. 문제를 모두 동일하게 제기합니다. 문제가 발생할 위험이 있습니다. '재현 불가능 / 충분하지 않은 정보' – 가능한 모든 오작동을 가능한 한 최대한 처리해야합니다.
- 일반적인 관행 QA 팀은 하루 동안 Excel 시트에 각 결함을 만들고 하루가 끝나면 통합합니다.
완벽한 결함 수명주기
라이브 프로젝트의 경우 결함 1에 대한 결함 수명주기를 따르면
eps 파일을 여는 방법
- 내가 (테스터) 만들 때 상태는 '새로운”. QA 팀 리더에게 할당 할 때 상태는 여전히 '신규'이지만 소유자는 이제 QA 리더입니다.
- QA 리드는 문제를 검토하고 유효한 문제인지 판단하면 문제가 개발자 리드에게 할당됩니다. 이 단계에서 상태는 '할당 됨' 소유자는 개발 책임자입니다.
- 그런 다음 개발 책임자는이 문제를 해결하기 위해 작업 할 개발자에게이 문제를 할당합니다. 이제 상태는 '진행중인 작업' (또는 그 효과와 비슷한 것) 소유자는 개발자입니다.
- 결함 1의 경우 개발자는 오류를 재현 할 수 없으므로이를 QA 팀에 다시 할당하고 상태를 다음과 같이 설정합니다. '재현 할 수 없음”.
- 또는 개발자가 작업하고 문제를 해결할 수있는 경우 상태가 다음으로 설정됩니다. '해결' 문제는 QA 팀에 다시 할당됩니다.
- 그런 다음 QA 팀에서 문제를 선택하고 다시 테스트하고 문제가 해결되면 상태를 다음으로 설정합니다. '닫은' . 문제가 여전히 존재하는 경우 상태는 다음으로 설정됩니다. '다시 열다' 그리고 그 과정은 계속됩니다.
- 다른 상황에 따라 상태를 다음과 같이 설정할 수 있습니다. '연기 됨' ,“정보 부족”, '복제' , '의도 한대로 작동' , 등 개발자에 의해.
- 결함을 기록하고,보고하고, 할당하고, 관리하는이 방법은 테스트 실행 단계에서 QA 팀 구성원이 수행하는 주요 활동 중 하나입니다. 특정 테스트주기가 완료 될 때까지 매일 수행됩니다.
- 사이클 1이 완료되면 개발 팀은 모든 수정 사항을 통합하고 다음 사이클에 사용할 다음 버전으로 코드를 다시 빌드하는 데 하루나 이틀이 걸립니다.
- 사이클 2에서도 동일한 프로세스가 계속됩니다. 주기가 끝날 때 응용 프로그램에 '열림'또는 수정되지 않은 문제가 여전히있을 수 있습니다.
- 이 단계에서 우리는 여전히 사이클 3을 계속합니까? 그렇다면 언제 테스트를 중단합니까?
OrangeHRM 라이브 프로젝트 테스트를위한 종료 기준
이것이 우리가 '종료 기준'이라고 부르는 것을 사용하는 곳입니다. 이것은 테스트 계획 문서에 미리 정의되어 있습니다. 그것은 우리가주기 2 후에 테스트를 마칠 지 아니면 한주기 더 진행할지를 결정하는 체크리스트의 형태입니다. OrangeHRM 프로젝트와 관련된 다음 질문에 대한 몇 가지 가설 적 답변을 고려하여 작성했을 때 다음과 같습니다.
위의 체크리스트를주의 깊게 살펴보면 앞에서 언급하지 않은 메트릭과 사인 오프가 언급되어 있습니다. 지금 그들에 대해 이야기합시다.
테스트 지표
테스트 실행 단계에서 보고서가 다른 모든 프로젝트 팀 구성원에게 전송되어 QA 실행 단계에서 일어나는 일 . 이 정보는 최종 제품의 전반적인 품질에 대한 유효성을 확인하기 위해 모든 사람에게 중요합니다.
10 개의 테스트 케이스가 통과했거나 100 개의 테스트 케이스가 실행되었다고보고한다고 상상해보십시오.이 숫자는 원시 데이터 일 뿐이며 상황이 어떻게 진행되고 있는지에 대한 좋은 관점을 제공하지 않습니다.
메트릭은이 격차를 메우는 데 중요한 역할을합니다. 메트릭은 간단한 단어로, 테스트 팀이 수집하고 유지하는 지능적인 숫자 . 예를 들어, 테스트 케이스의 90 %가 통과했다고 말하면 150 개의 테스트 케이스를 통과했다고 말하는 것보다 더 의미가 있습니다. 그렇지 않나요?
테스트 실행 단계에서 수집되는 여러 종류의 메트릭이 있습니다. 정확히 어떤 측정 항목을 수집하고 어떤 기간 동안 유지해야하는지-이 정보는 테스트 계획 문서에서 찾을 수 있습니다.
다음은 대부분의 프로젝트에 대해 가장 일반적으로 수집되는 테스트 지표입니다.
- 테스트 케이스의 합격률
- 결함 밀도
- 심각한 결함 비율
- 결함, 심각도 현명한 숫자
확인 이 기사에 첨부 된 상태 보고서 이러한 측정 항목이 어떻게 사용되는지 확인하세요.
테스트 사인 오프 / 완료 보고서
모든 이해 관계자에게 테스트가 시작되었음을 알려야하기 때문에 모든 사람에게 테스트가 완료되었음을 알리고 결과를 공유하는 것도 QA 팀의 의무입니다. 따라서 일반적으로 QA 팀 (일반적으로 팀 리드 / QA 관리자)에서 테스트 결과와 미결 / 알려진 문제 목록을 첨부하여 제품에 서명했음을 알리는 이메일이 전송됩니다.
샘플 테스트 사인 오프 이메일 :
에: 클라이언트, PM, 개발 팀, DB 팀, BA, QA 팀, 환경 팀 (및 포함해야하는 기타 모든 사람)
이메일: 안녕하세요 팀,
QA 팀은 웹 사이트의 기능 테스트 2주기를 성공적으로 완료 한 후 OrangeHRM 버전 3.0 소프트웨어를 승인합니다.
테스트 케이스와 실행 결과는 이메일에 첨부됩니다. (또는 그들이있는 위치를 언급하십시오. 또는 테스트 관리 소프트웨어를 사용하는 경우 이와 관련된 세부 사항을 제공하십시오.)
알려진 문제 목록도 이메일에 첨부됩니다. (다시 말하지만, 의미있는 다른 참조를 추가 할 수 있습니다.)
감사,
QA 팀장.
첨부 : 최종 실행 보고서, 최종 문제 / 결함 보고서, 알려진 문제 목록
QA 팀에서 테스트 승인 이메일이 발송되면 공식적으로 STLC 프로세스가 완료됩니다. 이것이 반드시 SDLC의 '테스트'단계의 완료를 표시하는 것은 아닙니다. 이를 위해 UAT 테스트를 완료해야합니다. 찾기 UAT 테스트에 대한 자세한 내용은 여기 .
UAT가 완료되면 SDLC는 배포 단계로 이동하여 라이브로 전환되고 고객 / 최종 사용자가 사용할 수 있습니다.
그게 다야!
이것은 독자들에게 QA 프로젝트와 같은 가장 생생한 경험을 제공하기위한 우리의 노력이었습니다. 이 무료 온라인 소프트웨어 테스트 QA 교육 시리즈에 대한 의견과 질문을 알려주십시오.
추천 도서
- 소프트웨어 테스트 교육 : 라이브 프로젝트에 대한 종단 간 교육 – 무료 온라인 QA 교육 1 부
- SRS 문서에서 테스트 케이스 작성 (라이브 프로젝트 샘플 테스트 케이스 다운로드)
- 소프트웨어 테스팅 QA 교육 과정 FAQ
- 2021 년 번거 로움없는 교육을위한 11 가지 최고의 온라인 교육 소프트웨어
- 키워드보기 작업-QTP 교육 자습서 2
- 소프트웨어 테스트에서 결함 / 버그 수명주기는 무엇입니까? 결함 라이프 사이클 튜토리얼
- JIRA 버그 추적 도구 튜토리얼 : JIRA를 티켓팅 도구로 사용하는 방법
- SRS 문서 검토 및 테스트 시나리오 생성 방법 – 라이브 프로젝트에 대한 소프트웨어 테스트 교육 – 2 일