이번 포스팅은 Quality Assurance와 Testing 영역에 종사했던 필자가 팀원들을 교육하면서, 혹은 공개 교육을 진행하면서 버그 보고 기술에 대해 강의했던 내용들과 노하우들을 공개하기 위한 내용이다.
필자는 기본기를 굉장히 중시하는 성향이다. 그러니 이 글에 검색해서 들어오신 분이시라면 본 포스팅의 내용에 앞서 꼭 1편, 2편, 3편, 4편을 먼저 읽어보시기를 추천드린다.
필자가 해 주는 버그 보고 이야기
필자가 팀원들과 함께 일하면서 버그 보고 관련 훈련을 진행할 때 사용하는 체크리스트와 약간의 설명을 방출한다. 필자와 함께 일한다면 이런 내용들에 더해 추가적인 노하우들을 가이드를 해 줄 수 있겠으나, 인터넷에서 전달할 수 있는 내용들은 다음과 같다. 물론 동의하지 않는 사람도 있을 수 있겠지만, 필자는 이렇게 해 왔었고, 앞으로도 필자의 의견은 크게 바뀌지 않을 듯하다.
1. 버그 보고 활동은 학습이 필요한 전문 기술이다.
• 「버그 보고」는 소프트웨어 개발을 잘하기 위해 수행하는 커뮤니케이션 방법론의 일부이다. (애자일이나 TDD만 방법론인 게 아니다.) 그렇기에 「버그 보고」 역시 심각히 공부하고, 습득해야 할 기술이다.
• 버그 보고를 잘 하기 위해서는 훈련이 필요하다. (누구나 잘 할 수 있다는 생각은 오해다.)
• 인간의 생명을 다루는 특정 분야들(우주항공, 무기, 자동차, 원자력, 의료 등)에서는 버그 보고 기록도 모두 공식 문서이다. 버그 보고 기록들도 감사를 받아야 하며, 문제 발생 시 정부 기관, 감사 기관의 사정(査正) 대상이다. 그래서 반드시 전문성이 필요하다.
2. 버그 보고는 소프트웨어 개발에서 가장 주효한 의사소통 도구 중 하나이다.
• 수많은 소프트웨어 개발방법론자들에게 「의사소통」을 개선하거나 역량을 확보해야 할 주요 키워드로 꼽지만, 그중 하나가 버그 보고임을 말하는 방법론들은 거의 없다.
• 버그 보고라는 것은 소프트웨어 내의 문제에 대해 함께 하는 팀이 「의사소통을 원활하게 하기 위해 작성하는 정보 공유 방법론」이다. 버그 보고는 의사소통 역량에 해당하는 중요 소프트 스킬(Soft skill)이며, 소프트웨어 개발 조직 내 리더들이 갖추어야 할 역량이다.
3. 최대한 내부 개발팀에서 사용하는 친숙한 용어를 사용하여 설명한다.
• 버그 보고를 효율적으로 수행하려면 일단 팀에서 사용하는 용어들을 사용한다.
• 개발팀 내부에서 사용하는 그 용어들이 업계 표준과 맞지 않다고 해도 일단 사용한다. 중요한 건 무슨 용어를 사용하고 있느냐가 아니라, 발생한 문제를 해결하는 바에 개발팀이 집중하도록 하는 것임을 잊지 말자. 사용하는 용어를 고치는 건 나중에 해도 된다.
• 틀린 용어가 회사 밖으로 나가 공식적인 자료로 사용하게 되는 경우는 업계에서 평상시 사용하는 용어가 아님을 알리고 수정하도록 독려하는 건 상관없다. 하지만 굳이 조직 내에 오랫동안 사용한 용어가 있다면, 불필요하게 고치려 들지 말고 그러려니 하자. 그 용어로도 돈 잘 벌고 있었으면 안 고쳐질 가능성이 높기 때문이다.
4. 버그 보고의 가장 중요한 목적은 「정보」 전달이다.
• 버그 보고라는 행위를 왜 하는가에 관해 서술할 때 가장 중요한 목적을 하나만 꼽으라면 그것은 프로젝트 내 필요한 사람들에게 버그에 대한 「정보」를 전달하는 것이다. (그리고 ①필요한 정보를 ②적시에 ③그 정보가 필요한 사람에게 전달하는 것이다)
• 가장 좋은 버그 보고서는 개인의 주관적 감정이나, 개인적인 평가(어떻게 되는게 좋겠다라는) 등 불필요한 정보를 담지 않는게 좋다. 중립적이고 객관적인 관점에서 ‘사실 정보’들을 전달해야 한다.
• 그러므로, 버그 보고 기록은 전달해야 하는 「정보」를 중심으로 기술한다. 불필요하게 평가하거나, 개인의 감정을 담거나, 개선의견을 함부로 담지 않는 게 좋다.
• 사실만 기록한다는 것도 사실 쉽지 않고, 기술 훈련이 필요하다. 왜냐하면 누군가가 사실이라고 느껴 기록한 내용들이, 또 누군가에게는 불편하고 부정적으로 느껴질 수 있기 때문이다. (지나치게 날카로운 Fact의 나열은 그 사실의 대상이 되는 사람에게는 듣기 버거울 수 있다.) 세상 사람 누구나 마찬가지겠지만, 좋지 않은 소식을 전달 받으면서 온통 부정적으로만 말하는 사람의 말은 듣고 싶지 않다. 그러므로, 중립적 입장에서 사실을 나열하는 과정에서 가능하면 부정적인 단어, 표현보다 긍정적인 단어와 표현들을 사용하여 버그를 보고하는게 좋다.
상황에 따라서 보고된 버그의 내용은 누군가에게 절망적이거나, 나쁜 소식일 수 있다.
5. 내용 설명은 최대한 간결하고, 심플하게 기술한다.
• 이는 단순히 짧게 요약해서 서술하라는 이야기가 아니다. 정확히 표현하면 “불필요한 이야기를 주저리 늘어놓지 말라”는 의미다.
• 또한, 굳이 불필요하게 “너무 복잡한 문장을 만들지 말라”는 의미다.
• 간결하고, 명확하게, 단순 명료하게 전달해야 하는 정보들을 전달하면 된다.
• 모호하게 해석될 문장을 만들지 말라. 이렇게도 저렇게도 해석될 수 있는 문장을 만들지 않도록 해야 한다.
• 버그 보고자의 글쓰기 능력이 충분히 훌륭하지 못할 수 있다. 누구나 간결하고, 심플한 보고서를 만들 수 있는건 아니다. 위 1번 전제에서 언급하였지만, 좋은 버그 보고를 위해서는 반드시 심각히 공부하고, 기술을 습득하는 훈련이 필요하다. 그러므로, 더 나은 테스터가 되기 위해 항상 공부하고, 훈련하라.
6. 버그 보고는 창작 글쓰기가 아니다. 테스트 케이스(Test Case)에 담긴 내용들을 적극 활용하라.
• 대부분의 엔지니어링 조직에서 업무상 역할을 구분하는 것은 해당 업을 달성할 수 있는 전문성을 기준으로 나눈다.
• 테스트 전문가(Test Expert)는 프로젝트 내에서 테스트를 설계(Test Design)하고 분석하여 테스트 계획(Test Planning)과 테스트 케이스(Test Case)를 만드는 역할을 수행한다.
• 그렇기 때문에 대부분의 프로젝트 조직에서 테스트 케이스는 그 자체로 전문성을 가진 도구이다.
• 정상적으로 테스트 케이스를 작성할 수 있는 테스트 전문가가 만든 테스트 케이스에는 사전조건(Pre-requisite/Pre-condition), 재현 방법(Steps to reproduce), 현재 상황/결과(Actual result), 예상 결과(Expected result)가 미리 설계되어 있다. 이를 적극 활용하자.
• 버그 보고 시에는 본인이 창작해서 글을 쓰기보다는 미리 설계된 테스트 케이스를 활용하여 ①어떤 상황에 ②무엇이 ③어떻게 작동했어야 정상인데 ④어떤 비정상 결과를 보인다고 작성해야 한다.
• 정황을 기술해야 하는 경우들도 있으나, 그런 경우도 버그 보고자 개인의 창작은 가능한 배제 하고 사실을 기반으로 작성해야 한다. 그리고 그 사실들은 대부분 테스트 케이스에 미리 준비되어 있다.
• 참고 : 테스팅 업계에서는 ‘원래 되어야 하는 결과’로 Designed result라고 사용하지 않고, Expected Result를 사용한다. 기획서에 모든 사용자의 예외 상황을 가정할 수 없기 때문이기도 하고, 프로그램 결과가 언제나 기획한 대로 작동하지 않을 수 있기 때문이다. 그러나, 팀에서 협의가 된다면 “기획서에 있는데 그대로 작동 안하는 경우 Designed result’라고 하고, 그 외 테스터의 판단에 오류라고 판단되는 경우 ‘Expected result’로 나누어서 사용하는 것도 가능하다.
7. 버그 보고는 본인의 지식을 자랑하는 문서가 아니다.
• 버그 보고는 본인이 알고 있는 지식을 자랑하기 위한 문서가 아니다. 불필요하게 지식 자랑하지 마라. 또, 그렇게 하는 사람이 같은 팀에 있다면 말려라.
• 상황에 따라 이론에 관해 설명이 필요한 경우, 혹은 논의가 필요한 경우가 발생할 수 있는데 이런 경우는 그냥 차라리 회의를 열어라.
• 반드시 이론을 동반하여 설명해야 한다면, 별도로 컨텐츠를 제작하거나, 자료를 조사하여 링크/참고자료로 제공한다.
8. 버그 보고 시 지적하지 않는다
• 버그 보고 시 누군가를 지적하듯이 글을 쓰지 않도록 주의한다.
• 중요한 것은 정보의 전달이다. 중요 내용에 집중하자.
• 개발 조직의 상급자가 버그 보고를 하려고 들면 말려라. 특히 조직의 실장급의 Senior, CTO가 버그 보고를 하려고 들면 꼭 말려라. 그들은 업무 평가를 하는 사람들이다. 그들의 버그 보고는 받아들이는 사람들에게 지적처럼 느껴지게 하며, 공포심을 자극할 수 있다.
9. 버그 보고에는 사자성어, 속담, 비속어, 은어, 유행하는 줄임말을 사용하지 않는다.
• 가끔 어떤 회사에서는 경영진들이 사자성어나 일상생활에서 사용하지 않는 옛스런 표현을 사용하는 걸 좋은 문장이라 생각하는 경우가 있을 수 있다. 설득해서 그러지 않도록 하는 게 좋다. 버그 보고는「의사소통을 위한 방법론」이자, 미래의 팀이 과거 팀의 활동을 살펴볼 수 있는 역사적 기록이다. 그러므로, 10년 뒤, 20년 뒤, 언제 보아도 알아볼 수 있도록 명료하게 보고를 작성하는 게 중요할 뿐 아름답고 수려한 문장을 만드는 건 버그 보고에 전혀 중요하지 않다.
• 외국어 표현은 한국어 표현이 있는 지 확인하고 가능한 공통적으로 모든 세대가 이해할 수 있는 표현을 선택하는게 좋다. 필자는 다음의 방법을 추천한다. (사실 이는 국제 표준이기도 하다.)
① 한글명이 있는 경우 한글명을 쓰고 영문명을 기록 : 한글명(English Name)
② 영문 줄임말을 쓰는 경우 전체를 먼저 쓰고, 단축어를 기록: Quality Assurance(QA)
• 버그 보고 작성자는 몇 년 뒤의 자신이 해당 자료를 찾아볼 수 있음을 상기하고, 작성 시 그 당시에 유행하는 용어를 사용하는 우를 범하지 않도록 하자. 그렇기 때문에 유명한 방법론들에 나오는 용어들보다는 국제 표준의 용어, 소프트웨어 공학의 용어를 사용하는 게 좋다.
가장 좋은 버그 보고서는 읽는 사람들이 이해가 잘되고, 또한 끝까지 읽고 싶게 만드는 보고서이다.
10. 구어체를 사용하지 않는다.
• 사실 이 항목은 너무 당연한 거라 훈련 시에 빼먹고 강조하지 않을 때가 많다. 근데 꼭 언급하지 않으면 종종 사고가 발생하곤 하는 항목이다. 자, 이거 중요하다. 그리고 기본이다. 버그 보고를 할 때는 구어체를 사용하지 않는다. 자신과 친분이 있는 프로그래머가 개발한 구간에서 버그가 발생했다고 해서 자기 나름대로는 친분을 표시한다고 구어체로 쓸 수 있는데, 그게 받아들이는 입장에서는 굉장히 공격적으로 느껴질 수 있다.
• 또한, 당사자들 외의 사람들이 보기에는 그런 상황들이 굉장히 불편하거나, 혹은 버그 보고자가 아마추어처럼 보일 수 있다.
11. 메신저를 사용하지 않는다.
• 위 10번의 확장판 이야기다. 개인적인 친분이 있는 프로그래머가 개발한 부분에서 버그가 발생한다고 해서 (단순 문의인척 하며) 메신저를 이용하여 버그에 대한 정보를 개인적으로 전달하고, 개인적으로 버그를 수정하게 해서는 안 된다. 모든 건 가능한 팀 내 기록으로 남겨야 한다. 제품의 품질과 팀 업무 품질의 개선을 위해서 필요한 데이터들을 개인적으로 처리하지 말자.
• DevOps든, QA든, Dev 조직의 Leader이든, 이런 사건을 발생하지 않게 하기 위해서는 개발환경과 테스트 환경을 나누어야 하고, Module 단위의 Test와 System Integration Test 단위의 환경을 나누어 어느 시점이 되면 더 이상 개별적인 판단 후 시스템을 변경할 수 없도록 권한을 막아두는게 좋다.
12. 스크린샷을 이용하여 문제점을 강조할 때 빨간색 사용을 자제한다.
• 빨간색은 전 세계 공통적으로 초등 교육 시 선생님이 누군가의 오답을 교정하는 색상인 경우가 많다. 그래서 버그 보고에 들어가는 스크린샷 작업 시 붉은색 계열을 사용하여 특정 부분을 강조하면, 해당 버그가 발생하는 부분을 개발했던 프로그래머 입장에서는 지적당하는 느낌이 들 수 있다. (이 내용은 절판된 소프트웨어 테스팅 원서들에서 심리학을 언급하며 기재되어 있는 부분을 참고하였다.)
버그 보고는 Software Tester가 하는 Techinical Writing이다.
마지막으로, 너무 당연한 이야기지만 ①문단 나누기를 확실하게 해야 하고, ②맞춤법 검사기를 꼭 돌리는 게 좋다.
필자와 함께 일하거나 취미 프로젝트라도 함께 하는 사람들이면 모를까 블로그 글 몇 개를 소개하는 것으로 누군가의 글쓰기를 교정해주기는 어렵다. 필자는 스스로도 글을 잘 쓰는 편이 아니며, 워낙 오타도 많이내고 단어의 띄어쓰기나 맞춤법도 많이 틀리는 편이다보니 누구를 공개된 장소에서 가르쳐주기도 창피하다.
글쓰기는 학교에 다닌 사람이라면 누구나 최소 1번 이상 점수를 받기 위해 노력했던 구간이다 보니 자신이 잘하지 못한다는 인식을 가지기가 굉장히 어렵다. 글쓰기 관련 내용은 과외를 찾아볼래도 의외로 글쓰기 과외는 다들 잘 받지 않다보니 선생님을 구하기도 쉽지 않다. 필자가 권하는 가장 좋은 방법은 책을 읽는 것이다. 책에는 대부분의 경우 기승전결이 있다. 책에서는 문단 나누기가 잘 되어 있고 좋은 문장들을 읽을 수 있다. 책을 읽으면 책을 구성하기 위해 수 많은 머리 좋은 사람들이 글을 쓰고, 퇴고하고, 읽고, 편집하고, 출판하는 과정에 담긴 지식 체계를 은연 중에 혹은 세세히 익힐 수 있다.
개인적으로 글쓰기 관련 도서를 읽어 훈련하거나, 혹은 전문성을 키우기 위해 Technical Writing에 대해 자료를 찾아보고, 강의에 참석하여 기술 분야의 글쓰기를 공부해 보는 것도 좋은 방법이라 추천하고 싶다.
5편 끝. 6편에서 계속.