소프트웨어 결함 리포트: 내용

이어지는 시리즈

• 소프트웨어 결함 리포트
• 소프트웨어 결함 리포트: 분석
• 소프트웨어 결함 리포트: 보고
• 소프트웨어 결함 리포트: 내용
• 소프트웨어 결함 리포트: 트랙, 재시험, 마감

 

소프트웨어 결함 리포트 구성요소

 

정보 식별

문제 설명

다양한 상태 지표(indicator)

주석(comments)

기타 정보

지원 정보

 

 

---

정보 식별

• 고유 번호 또는 ID
  • 트레킹 시스템이 있을 경우, 자동으로 ID 부여 / 없을 경우, 수동으로 번호 지정
• 제출자
  • 어떻게 제출자를 트랙할 건지에 따라 결정한다. 오픈 시스템인 경우, 사용자들도 제출자가 될 수 있음
• 제출 일자
  • 결함이 얼마나 오래 됐는지 알 수 있음
• 이에 반하는 프로그램 또는 제품
• 제품 버전 또는 개정(revision)

---

문제 설명

제목

       - 최소한의 단어수로 문제를 이해할 수 있는 충분한 정보를 전해야한다

       - 어떤 약어든지 일반적으로 인정되거나 설명서에 뜻이 포함되어야한다

       - 예: "ACM: No error messgaes when 'Print on Error' is on" / ACM - Advanced Color Module 

                "고급 컬러 모듈: '프린트 에러'가 떴을 때 에러 메시지가 뜨지 않는다"

 

설명

       - 문제

             - 무엇이 발생했는지 (실제 결과들)

             - 무엇이 발생했어야했는지 (예상된 결과들)

             - 예: "나는 구분문자(delimiter) 레코드를 빼먹었다. 그리고 리포트는 생성되었다. 나는 에러 메시지와 리포트가 생성되지 않기를 예상했다"

       - 사용된 테스트 케이스를 항시 포함할 것

             - 테스트 케이스 번호를 절대 새로 매기지 않기!

       - 무엇이든 다른 유용한 정보

             - 테스트가 실행되는데 있어 영향을 끼칠 수 있는 모든 것들, 첨부된 것은 이름을 꼭 붙이기! 

       - 3 또는 4개의 문장들로 구성할 것

       - 모호하거나 헷갈리는 용어 사용 X (예. 자주, 때때로)

       - 흔하지 않은 약어 사용 X 

       - 표준 용어 사용하기

       - 철자와 문법에 유의하기

---

상태 지표

1. 종합적인 리포트 상태
2. 심각성과 우선순위
3. 현재 해결 상태

• 종합적인 리포트 상태
  • 실행(open)
  • 종료(closed)
• 심각성(Severity) vs 우선순위(Priority)
  • 심각성: 얼마나 상태가 "나쁜지" - 테스팅에 미치는 결함의 영향과 관련 있음
    • 중간(medium)으로 기본 설정되어있으며, 결함 리뷰 보드에 의해 변경될 수 있다
  • 우선순위: 얼마나 긴박한지 - 언제 고쳐져야 하는가?
    • 프로덕트나 개발 매니저를 통해 지정되며, 더 먼저 or 늦게 작업해야할 순서를 알려준다
  • 예. 시작 화면에 나오는 철자가 틀린 회사 이름 -- 매우 높은 우선사항, 매우 낮은 심각성
  • 예. 시스템 충돌 -- 높은 우선순위, 높은 심각성
• 심각성
  • 높음 -- 중대 결함; 테스트가 계속될 수 없음
  • 중간 -- 중대 결함; 테스트는 대안과 함께 계속될 수 있음
  • 낮음 -- 문제가 있으나, 본질적으로 무시할 수 있음
  • 사소함 -- 기록(documentation), 도움 파일, 철자/맞춤법 실수
• 해결(resolution) 상태의 예 (중간 상황)
  • 없음 [보드가 검색하는 것]
  • 절차중(In Process) / 지정된(Assigned)
  • 해결됨(Fixed, 앱 결함에는 "pre-build"라고 함)
  • 테스트를 위해 준비됨("post-build"; 테스트 스위트의 결함에는 사용되지 않음)
  • 재테스트
  • 전형적인 결함에는 위 5개가 쓰이며, '종료'가 추가된다
• 해결 상태의 예 (최종 상황)
  • 반복되지 않음
  • 문제 아님
  • 고치지 말 것
  • 복제
  • 연기됨

---

주석/노트

• 분석 노트
• 해결 노트
• 테스터 노트
• 수정 노트
• 확인 노트
• 원하는대로 노트

---

기타 필드들

•   재생산(reproduce)하기 위한 단계
  • 셋업 정보를 포함
  • 적절하게 셋업하면 누구든지 문제를 재생산할 수 있음
  • "테스트 케이스 ID"만큼 간단해지거나 또는 "긴 절차"만큼 복잡해질 수 있다
  • 재생산되지 않고 그저 반복되는 문제에 주의
• 필드
  • 환경(Environment): 제품 버전, 운영 체제 정보, 연결된 주변 장치, 플랫폼 정보 등 포함
  • 타겟 릴리즈: 대상을 만들지 않으면, 유예됨
  • 종료된 릴리즈, 종료 날짜: 종료 시간에 테스터 또는 시스템에 의해 작성됨
  • 오너: 오너를 잘 알고 있는 경우 외에는, 리뷰 보드에서 지정. 중간, 최종 상태를 업데이트하는 사람이 오너가 되므로, 계속 바뀔 수 있음
  • 테스터
  • 발견된(discovered by/in): by - DVT 또는 SVT와 같이 테스팅 단계 또는 고객이 될 수 있음. in - 서비스 또는 제조가 될 수 있음
  • 결함타입 / 근본원인: 결함 타입은 많은 다른 것들이 될 수 있고, 어떤 것을 찾는지에 근거함. 소프트웨어 또는 하드웨어? 기계 관련? 디자인? 필수요소? 테스트 케이스?
  • 소프트웨어 구성요소
  • 해결시간(fix hours), 테스트 시간: 시간 메트릭에 사용되며, 다음 프로젝트를 추산할 수 있음
  • 해결책(workarounds): 문제를 회피하는 쉬운 방법이 있으면, 포함시킬 것. 문제가 얼마나 심각한지 결정하는데 있어서 도움이 될 수 있음. 이미 알고있는 해결책이 있다면, 포함시키기.

---

지원 정보

• 에러 출력문
  • 모든 에러 메세지들은 화면 캡쳐되고 첨부되어야 함
• 스크린샷
• 테스트 케이스
• 자료와 파일이 담긴 플래시 드라이브
• 추적 파일, 에러 로그 등

---

동적 테스팅에서 작성하는 결함보고서 내용

• 식별 번호, 제목 & 보고하는 결함에 대한 짧은 요약, 결함 보고 날짜 & 보고 주체 조직 및 작성자, 테스트 항목 식별자 & 환경, 결함을 발견한 개발 수명주기 단계, 로그 & 데이터베이스 덤프 & 스크린샷 & 녹화 기록 등의 결함 재현과 해결을 위한 설명, 기대 및 실제 결과, 결함 영향도의 범위와 정도, 수정 우선순위, 결함보고서 상태, 결론 & 의견 & 승인 여부, 글로벌 이슈, 변경이력, 참조

---

결함 보고서에서 각각의 구성요소는 중요하다

- 많은 관계자들은 시스템에 현재 어떤 문제가 있는지/있었는지에 관심있다

- 될 수 있는 한 간결하게 하기

- 결함들을 전달하는 지속적인 방법들을 제공하기

- 템플릿에 맞추어서 구성요소들을 수정하기