[테스팅 실무] 더 나은 버그 보고를 위한 테스터의 글쓰기 4편

2022년 05월 05일

글 잘 쓰는 방법, 글쓰기, 맞춤법, 버그보고, 소프트웨어, 실무, 테스팅, 한국어, 한글

이번 포스팅과 다음 포스팅은 Quality Assurance 영역에 종사하는 사람들이 더 나은 버그 보고를 할 수 있도록 돕기 위한 버그 보고 시 Technical Writing하는 방법에 관해 설명한다. 본인이 QA, Tester, Programmer 등 Bug reporting과 관련한 업무를 수행하는 사람이라면 한 번쯤 참고해 볼 만한 내용을 담았다.

필자는 기본기를 굉장히 중시하는 성향이다. 그러니 이 글에 검색해서 들어오신 분이시라면 본 포스팅의 내용에 앞서 꼭 1편, 2편, 3편을 먼저 읽어보시기를 추천드린다.

여러 소프트웨어 테스팅 관련 책에서 참조한 내용 소개

필자가 가진 노하우 전수에 앞서, 필자가 그런 노하우들을 갖추게 된 배경을 먼저 설명해야 할 거 같다. 그래서 몇 가지 책에 나와 있는 내용들을 좀 설명하는 게 좋을 듯하다.

소프트웨어 테스팅 법칙 293가지

Cem Kaner 외 2인 공저, 이주호 역, 정보문화사, 2002년 초판 발행, 2004년 한국어 번역판 발행

법칙55. 버그 보고서의 질이 곧 테스터의 능력을 말해준다.
법칙56. 버그를 보고해야 해당 버그가 고쳐진다.
법칙57. 버그 보고서를 효과적인 세일즈 도구로 만들어라.
법칙58. 버그 보고서는 당신을 대표하는 것이다.
법칙59. 시간을 들여서 버그 보고서의 가치를 높여라.
법칙86. 보고서의 어조를 조심하라.
법칙87. 지치거나 까다로운 사람조차도 쉽게 읽을 수 있도록 가독성이 뛰어난 보고서를 작성하라.
• 한번에 한 단계씩 버그 재현 과정을 진행한다.
• 각 단계별로 번호를 매긴다.
• 문제를 재현하는 데 필요한 모든 단계는 빼놓지 않는다.
• 독자들이 실패할 수 있는 가장 짧은 단계를 표시한다.
• 보고서를 쉽게 쭉 훑어볼 수 있도록 공백을 사용하라.
• 짧으면서 간단한 문장을 사용하라.
• 어떤 일이 일어나며, 어떤 일이 일어나기를 기대하는지를 명시하라.
• 만약 심각한 결과가 발생했음에도 불구하고, 프로그래머가 버그의 심각성을 이해하지 못할 것 같다면 왜 > 그렇게 생각했는지를 설명하라.
• 프로그래머가 문제를 식별하고, 수정 후 버그를 더욱 쉽게 테스트해볼 수 있도록 부연 설명을 포함하라.
• 복잡한 제품이나 문제에 대하여 3줄 정도로 간략하게 문제를 요약하라. 그리고 가급적 상세하게 설명하라.
• 중립적 논조를 유지하라.
• 농담은 하지 마라. 괜한 오해를 만든다.
법칙88. 보고서 작성 기술을 향상시켜라.

Software Testing

류성열, 이남용, 오기성, SAMS글로벌, 2002년 출간

효과적인 버그 보고 설명

최소의 설명 : 버그를 설명하고 재현하는 데 필요한 사실과 세부 사항만을 설명

하나의 보고서에 하나의 버그 : 버그 보고 시 하나의 버그 리포트에 버그 내용 1개만 기술

명백하고 일반적인 설명 : 복잡하고 뒤얽힌 단계로 설명하지 말고, 사용자들에 의해 발견되기 쉬은 일반적인 버그로 설명

버그를 재현할 수 있는 설명 : 재현경로를 명확하게 분석하고 간략하게 기술

버그를 보고할 때는 판단을 피하라 : 버그 보고 시 개인적인 판단 기준을 들이대거나, 감정 표시, 자만, 비난 등을 포함하지 않도록 주의

버그 보고서에 대한 후속 조치를 취하라 : 버그가 무시되거나 방치되도록 두지 말고, 지속적으로 감시한다.

The Testing Practitioner

Erik van Veenendaal, 2002년 출간(번역본 없음)

※ 필자 주1 : 이 책은 번역본이 없는 영문 원판을 필자가 나름대로 번역한 내용을 기재한다. 한국 사람들이 이해하기 쉽게 의역한 부분도 있음을 미리 양지해둔다.

IEEE 표준으로 소프트웨어 문제점 보고에 대한 규정이 문서화 되어 있다.
IEEE 1044-2009 : IEEE Standard Classification for Software Anomalies

※ 필자 주2 : 이 책에 기술된 IEEE 1044는 1993년 버전과 1995년 버전에 대한 이야기이다. 워낙 오래전 나온 책이기 때문에 최근 업데이트된 2009년 버전과 무엇이 다른지 필자도 잘 모르겠다. 일단 그런 부분들은 논외로 하고, 이 책에 나오는 대로 기술하면 다음과 같다.

버그 보고 및 처리는 다음과 같은 개념적 프로세스를 지닌다.

Recognition, 인지/인식

Investigation, 조사/분석

Action 행동/수행

Disposition 처분/조치

누군가 좋은 버그 리포트를 작성한다면 다음이 일반적인 규칙일 것이다.

Structure, 구조 : 좋은 버그 리포트는 확실하고, 구조적인 테스팅 방식을 담고 있어야 한다. 수동 테스팅, 자동 테스팅, 시나리오 기반, 혹은 탐색적 테스팅 등 테스팅 방식은 상관 없다. 즁요한 것은 버그를 어떻게 발견했느냐에 대한 내용을 표현하는 구조이다.

Reproduce, 재현 : 간결하고 정확하게 이슈의 재현 방법을 기술한다.

Isolate, 격리 : 테스트 환경 및 시스템으로부터 버그의 현상을 격리시켜야한다. 그래야 버그의 현상을 명확하게 알 수 있다.

Generalize, 일반화 : 가능하면 버그가 발생하는 상황을 명확하게 일반화하라.

Compare, 비교 : 같은 테스트 케이스로 여러번 테스트를 진행한다면, 이전 버전의 결과와 비교하고 이를 개발팀에 공유하라.

Summarize, 요약 : 버그의 제목은 버그의 성격과 현상을 간결하게 표현하라

Condense, 응축 : 버그 보고서에는 불필요한 표현들이나 단어들을 빼고, 간결하고 명확하게 의미가 전달되도록 기술하라.

Disambiguate, 불명확함 제거 : 불명확하거나 혼동될 수 있는 표현, 단어, 문장 등은 가능한 빼고 명확한 내용을 제공해야 한다.

Neutralize, 중립 : 버그 리포트는 중립적인 관점에서 사실만을 기재해야 한다. (누군가에게는 버그 리포트가 나쁜 소식일 수 있기 때문이다.) 개인적인 내용, 개인의 감정, 혹은 평가하는 표현을 담지 마라.

Review, 검토 : 버그 보고서는 기술 문서 중 하나이다. 프로그래머가 잘 알아볼 수 있도록 리뷰하는 과정을 거치는게 좋다.

※ 필자 주3 : 버그 관리 시스템에 버그 보고를 작성할 때 “로그인 버그입니다”, “메뉴 버그입니다” 하는 식으로 너무 큰 단위로 작성해선 안 된다. “로그인 화면에서 ○○○를 실행 시 □□□ 발생하는 버그” 같은 식으로 세부적이고 구체적으로 제목을 명시해야 한다. 제목과 내용이 같아도 상관없다. 그래야 하는 이유는 나중에 검색을 용이하도록 미래의 나, 미래의 팀원들에게 친절함을 베푸는 것이다.

개발자도 알아야 할 소프트웨어 테스팅 실무

권원일, 박은영, 이현주, 조현길, STA, 2008년 출간

※ 필자 주1 : 이 도서에서는 버그 보고서에 일반적으로 들어가면 좋은 항목들이 잘 정리되어 있다.

결함번호
테스트 항목
결함 형태 : 기능성, 신뢰성… 기획 의도
추적성 (발생시점) : 예) 요구사항의 ID No, 설계기준서, 상세설계, 코드, 등
발견 시점 : 요구사항, 설계, 상세설계, 코딩, 단위/통합/시스템/인수테스팅 단계
처리 상태 : 오픈, 보류, 중복, 수정 대기, 수정 완료, 종료, 재오픈
재현 여부 : 항상 재현, 간헐적, 재현불가
심각도 (사업적/기술적) : Show stopper, Fatal, No Workaround, Workaround, Cosmetic
우선순위 : 즉시 해결, 주의요망, 대기 낮은 순위
보고일
발생버전/빌드
수정일
수정버전/빌드
완료일
확인자/승인자
작성자
수정 담당자
결함 요약
재현 절차
증상
기대 결과
결론/건의사항
시스템 전체적인 이슈 : 인시던트가 수정되면 영향 받은 부분과 그 사업적/기술적 심각도 기술
테스트 환경
결함 등록/변경 History 결함 로그

※ 필자 주2 : 필자의 의견이지만 위 항목 중 “결론/건의 사항”은 빼야 한다고 생각한다. 버그 관리 시스템에 모아두어야 할 기록이 아닌데다, 불필요한 논쟁이 벌어질 수 있고, 미래에 검색 시 불필요한 내용이 검색될 수 있기 때문에 분리하여 별도의 시스템 혹은 커뮤니케이션 도구를 사용하는 게 적합하다.

소프트웨어 테스트 전문가 가이드

한국정보통신기술협회(TTA) 지음, 2019년 출간

※ 필자 주1 : 소프트웨어 테스트 전문가 가이드는 CSTS 자격증을 위한 서적이다.

※ 필자 주2 : 본 포스팅에 소개된 책들 모두 가능하면 한 번쯤 읽어보시기를 권장하는 책들이지만, 이 책은 한국에 출간되지 않은 영어 원서들에 담겨 있는 소프트웨어 테스팅과 관련한 많은 내용이 집대성된 한글로 된 책이므로 가능하면 한 권 사서 읽기를 추천한다.

이 도서에서는 결함 보고 활동 산출물로 ‘결함 보고서’와 ‘결함 추적 보고서’를 소개하고 있다.

결함 보고 시 다음의 성격을 고려해야 한다고 소개하고 있다.

결함의 구체화 : 테스트 데이터, 절차, 환경, 상황, 몇 번의 시도에서 나타나는지 등을 명확히 + 구체화 해야한다.

결함의 고립화 : 어떤 결함이 어떤 상황에서 나타나는 지에 대해 명확하고, 구체적으로 기술한다.

결함의 일반화 : 결함의 발생에 영향을 주는 요소를 최대한 일반적으로 기술. 음수에서만 발생한다던가, 특정 OS에서만 발생한다 등.

결함을 기록 시 고려해야할 사항으로는 다음을 소개하고 있다.

결함 컨텍스트 : 어떤 상황에서 결함이 식별되었는 지 기술

결함 설명 : 재현되고 해결될 수 있도록 상세히 기술

심각도

우선순위

위험 분석

결함 상태

그 외 참고 도서

ISO/IEC/IEEE 29119-2의 Testing Process에서 테스트 인시던트 보고(Test Incident Report)에 대해 소개하고, ISO/IEC/IEEE 29119-3:2021의 Annex R(Informative)에 보면 인시던트 보고(Incident Report)라는 항목이 있는데 필자가 내용을 확인하고 세부적인 내용들을 확인하려고 해보았다. 필자의 개인적인 소견으로 해당 내용들은 본 포스팅에서 테스팅 초심자들에게 참고하라고 소개할 만한 내용이 아니었다. 초보자들은 29119 표준은 스킵하도록 하자.

마무리

위에서 언급했던 도서들에서 발췌한 내용들은 소프트웨어 테스팅을 해봤고, 버그 보고를 일정 기간 이상 해 본 사람들이라면 쉽게 이해할 수 있는 내용이다. 하지만, 혹시 항목에 대한 세부적인 설명이 필요한 분이 계시면 댓글을 남겨주시기를 바란다. 혹여라도 질문이 들어오면 별도의 포스팅을 작성해 보겠다. (필자의 블로그에 댓글을 달기 위해서는 GitHub에 가입해야 한다.)

4편 끝. 5편에서 계속.

참고 자료

각 도서에 대한 정보는 본문에 표시하였으므로 본문 참고

소프트웨어테스팅버그 보고