리포팅

우리는 하루에도 열심히 Jira나 Mantis나 우리가 관리하는 Bug Tracking System에 많은 티켓들을 생성한다.
이렇게 생성된 버그나 결함 티켓에는 많은 정보를 갖고 있으며, 다른 사람들에게 공유되고, 판단하게 하는 기준이 되기도 한다.

 

쓰다 보면 개발자와, 기획자와 디자이너와 사담이 많아지는 경우가 더러 많더라.

그 당시에는 쓴다고 썼는데, 또다시 읽어보면 오탈자라든지, 내용이 맞지 않다던지 산으로 가고 있더라지?

간단하지만 중요한걸 왜 이리 넘겼나 싶다. 

 

생각해보면, 우리가 등록한 버그나 결함 티켓에는 이슈에 대한 기본 정보부터 릴리즈를 할 수 있냐 없냐의 정보까지 갖고 있는 엄청난 녀석이다. 

 

그렇지만 우린 바쁘다는 핑계로 항상 대충 적고 있진 않았을까? 반성을 해보자.

 

• 내가 쓴 글을 관련된 사람이 읽고 업무를 진행하게 된다는 것을 잊지 말아야 한다.
  • 필요한 내용이 빠지거나, 불필요한 내용이 없는지 확인한다.
  • 반드시 수정되어야 하는 내용으로 판단이 안된다면, 그걸 판단할 수 있는 Stackholder에게 할당하는 것도 방법이다.
• 작성을 완료하기 전에 한번 다시 Review 후에 가독성을 확인한다.
  • 문장이 매끄러운지, 읽기 쉬운지, 문제 되는 내용이 명확한지 다시 한번 읽어본다.
• 재현하기에 좋은지 내용을 다시 확인한다.
  • 개발자 또는 관련자들이 보고 쉽게 재현할 수 있는가? 만약 제대로 적혀 있지 않다면 설명을 위해 커뮤니케이션 비용이 다시 발생할 것이다. 
    
  • 재현이 어려운 것이라면 빈도수 즉, 10회 중 몇 번 발생 등으로 판단하기 쉬운 수치상의 정보를 제공한다.
• 용어 설명이 적절한지 다시 한 번 확인한다. 
  • 기능 또는 화면을 지칭하는 용어들이 나만 알고 있는 것인지, 팀에서 공용으로 사용되는 것인지? 표준으로 사용되는 용어인지? 한번 확인은 하고 사용을 하자.
    • ex) Popup, Alert의 차이를 모르고 같이 사용을 하는 경우나 클릭, 선택 등 비슷한 용어를 남발하지 말자.

가장 기본이 되는 일인데, Bug Reporting에서부터 구멍이 난다면, 누가 QA를 신뢰하겠는가?