나의 QA 이야기 - 2 (회고)

[다시 보기] 나의 QA 이야기 - 2

나의 QA 이야기 - 2

---

"첫 회사가 앞으로의 내 커리어를 결정짓는다"라는 말이 있을 정도로 첫 회사는 아주 중요하죠.

그런 의미에서 저는 첫 회사를 잘 들어갔다. 라고 말하고 싶습니다. 

물론 힘든것도 많고 불합리하다고 생각되는 것도 많았지만 업무에 대한 경험을 잘 쌓고 신입으로써 성장할 수 있었던 부분은 높은 점수를 주고 싶습니다. 저는 이곳에서 버그를 등록하는 것에 대한 트레이닝을 수개월 동안 받았습니다. 그 덕분에 지금 버그를 등록하는데 큰 문제가 없는 것일 수도 있습니다.

버그를 등록하는 것은 QA활동에 아주 중요한 부분을 차지합니다.
내가 진행한 테스트에 대한 내용도 남겨야 하고, 문제라고 판단된 상황에 대해 설명을 해야 하고 이것이 어떻게 수정되어야 한다 라는 내용까지 있어야 하기 때문입니다. 

간단히 말하면 이것과 같습니다.

내가 이러이러한 버그를 찾았다.
이것은 이러이러한 방법으로 재현할 수 있다.
이러이러한 이 버그는 저러저러하게 수정되어야 한다.

아마 많은 곳에서 이런 기본적인 양식의 버그 등록을 하시고 계실 텐데요 각 영역을 더 세부적으로 나누어 제가 주로 사용하는 양식과 빗대어 보겠습니다.

---

타이틀(제목): AA 화면에서 BB기능이 CC 처럼 동작하지 않는 현상.

[스크린샷이나 동영상 첨부]

재현방법:
1. AA화면 이동 
2. BB 기능을 요러요러하게 사용
3. CC 처럼 동작하지 않는 것 확인

기대결과:
AA 화면에서 BB기능이 CC처럼 동작해야 합니다.

---

저는 이렇게 크게 3단락으로 나눠서 버그를 등록합니다.
원래는 타이틀, 현재상황, 재현방법, 기대결과였는데 타이틀과 현재상황이 주로 겹치는 내용이었기 때문에 작성 효율을 고려하여 과감히 현재상황 부분을 삭제하여 사용하고 있습니다. 

타이틀의 어미 부분을 보시면 '~현상' 으로 끝나는 것을 보실 수 있습니다. 과거에는 저도 '~버그' 나 '~문제' 이렇게 타이틀을 작성했는데 부정적인 워딩이기도 하고 글을 볼 때마다 담당자가 압박을 느낄 수도 있을 것 같아서 '현상'이라는 중립적인 단어로 바꿔서 사용하고 있습니다. 이미 해당 내용이 '버그'라는 것은 모든 관계자가 알고 있을 것이기 때문에 굳이 한번 더 언급하지 않아도 될 것 같아서 이기도 합니다.

그리고 타이틀에는 정확한 상황의 묘사보다는 기능위주의 내용으로 작성합니다. 

정확한 묘사: 파일 다운로드 사유에 20글자 이상 적고 다운로드 버튼 클릭 시 아무 반응이 없는 현상

기능위주의 내용: 파일 다운로드 사유가 20자 이상 작성되어있을 경우 파일 다운로드가 안 되는 현상

위의 예시에는 정확한 묘사와 기능위주위 내용 글자수가 얼마 차이 나지 않지만 복잡한 기능일수록 정확한 묘사에 많은 글이 쓰이게 되고 재현방법의 내용까지 타이틀에 포함될 가능성이 있습니다.
이런 것들을 방지하기 위해 '어떤 현상에 어떤 문제가 있다'로 간결한 내용으로 이슈파악을 할 수 있게 하고 타이틀 내용에는 재현방법이나 기대결과에 대한 내용이 포함되지 않도록 하는 것이죠.

위의 내용대로 했을 때 '지금 어떤 버그가 있군' -> ' 이 버그는 이렇게 하면 재현되는구나' -> '이렇게 수정되면 되겠네'를 하나의 흐름으로 알 수 있게 되는 것이죠. 중간에 이해를 돕기 위해 스크린샷과 동영상은 본문내용의 가장 상단에 추가해 놓습니다. 그 위치에 있으면 타이틀 문구를 읽고 들어왔을 때 바로 시각적으로 어떤 문제가 있는지 알 수 있기 때문입니다.

물론 이것은 제가 사용하는 방법입니다. 버그 등록 양식은 회사(조직)마다 다를 수 있습니다. 제가 사용하는 방법이 옳은 것이 아니라 하나의 방법이라고 생각해주시면 됩니다.

 BTS(Bug Tracking System) Tool은 굉장히 많습니다. ** ITS(Issue Tracking System)도 있습니다.

(참고)
https://www.softwaretestinghelp.com/popular-bug-tracking-software/

대표적으로 JIRA가 있구요 무료로 사용할 수 있는 Redmine도 있고 요새는 Notion으로 관리하는 곳도 있습니다. 이 외 적으로는 Pivotal Tracker라는 툴도 사용해 봤고 자체개발한 BTS, 엑셀파일로 트래킹 하는 방식도 사용해 봤습니다.
개인적으로는 역시 JIRA가 가장 편한 도구입니다. 저는 추후 버그 분석을 위해 버그 등록 시 입력해야 할 필드를 세분화 해놓는 편입니다. (플랫폼, 재현율, 버전, 카테고리, 서브카테고리 등등) 이렇게 세분화해 놓을 경우 대시보드를 이용해서 현황파악을 할 때 굉장히 유리합니다. 각 필드별로 통계를 볼 수 있기 때문인데요. 사전 작업으로 필터를 만들어놔야 하지만 필터도 JIRA Query를 사용하여 디테일한 설정을 할 수 있기 때문에 내가 원하는 정보를 문제없이 볼 수 있습니다.

버그 티켓을 관리할 때 한가지 더 중요한 것이 있습니다. 바로 워크플로우인데요. 버그 티켓이 어떠한 흐름으로 상태가 변경되면서 최종적으로 완료처리가 될지 그 흐름을 정의하는 것입니다. 아마 일반적으로는 이렇게 사용하실 것입니다.

할일 -> 이슈 확인중 -> 수정확인 -> 완료

최초 티켓 등록 시 '할일' 상태가 되고, 이것을 담당자가 가져가서 수정을 시작했다면 '이슈 확인 중', 그리고 이슈 수정이 끝나서 확인이 필요하다면 '수정확인' 상태가 되고 QA가 확인을 완료했다면 '완료' 상태로 변경하는 것이죠.

이 과정에서 개발자분들이 요구하는 워크플로우가 조금씩 달랐습니다. 
수정과 배포는 다르니 '수정확인' 을 '수정완료', '배포완료'로 해달라는 분도 계셨고  '수정완료', '배포완료'로 운영했지만 단계가 많아서 줄여달라고 하는 분도 계셨었습니다. 
워크플로우도 정답은 없고 조직에 맞춰서 사용하시면 됩니다. 
추천 드리는 것은 처음에는 최소화된 워크플로우로 운영하시다가 필요에 의해서 늘리는 방법입니다. 처음부터 최대화된 워크플로우로 운영하실 경우 추후에 요청에 따라 워크플로우가 삭제, 수정해야 하는데 없다가 있는 것보다 있다가 없는 상황을 더 혼동스러워 하시더군요.

이렇게 버그 등록을 하는 과정을 잘 경험하게 됩니다. 
저는 버그 등록 온보딩을 성공적으로 완료했다고 보고 있습니다. 첫 회사에서 정말 많이 등록했던 것 같습니다. 그 덕분에 훈련도 많이 했고 어떤 문제점이 있었는지도 알게 되었지요. 내가 신입이고 주니어라면 지금 당장은 불만족스럽고 불평불만을 갖는 일이 있을 수 있습니다. 하지만 그것은 언젠가는 나에게 긍정적인 영향을 줄 수 있는 것일 수도 있으니 너무 불평불만만 하기보다는 그것을 어떻게 더 효율적으로 진행할지, 어떻게 더 잘할 수 있을지를 고민하면서 진행해 보시길 추천드립니다. 그것을 바라보는 시각이 달라지면 다른 방향의 더 좋은 해결방안이 생길 수도 있기 때문이지요.

자~ 그럼 오늘도 버그 등록하러 가볼까요?