열린 공간, 누가바닷컴

프로젝트가 시작된 지 어언 1년여 시간이 지났다. 그 동안 분석과 테스트 케이스 개발, 테스트가 충분히 진행되었다고 생각하고 있었다. 발견되는 버그의 개수는 점점 줄어들고 있고, 대부분의 버그가 수정되어 Verification/Regression test를 계속 진행하며 모두 고쳐진 것이 확인되어 버그 닫기를 기다리고 있다. 얼마의 시간이 더 지나고 더 이상 새로 버그를 발견하지 못하고 있고, 이는 나뿐만이 아니라 대부분의 팀들이 그러한 상황이 된 듯 하다. 이러한 상황을 예측하여 프로젝트 관리자들은 ZBB(Zero-Bug Bar)를 정하여 그 날까지 Active Bug(발견은 되었지만 수정되지 않은 버그)가 0인 날짜를 지정한다. (물론 반드시 0이어야 하는 것은 아니다. 인원 대비 버그 개수로 계산을 하여 팀마다 각자 다르게 정하기도 한다) 이후부터는 RTM Mode로 프로젝트가 전환되어 발견되는 버그마다 까다로운 기준으로 수정할 것인지 수정하지 않을 것인지를 결정한다. 그렇다. 우리는 ZBB를 달성했고 이제 RTM모드에서 발견될 수 있는 버그들에 대해 집중하기로 했다.

그런데 신기하게도 ZBB이후 이해할 수 없는 일들이 벌어지곤 한다. 마치 프로젝트 초 중반에 벌어질법한 일들이 발생하는 것이다. 다른 팀에서 개발한 기능이나 프레임워크 통합에서 발생했던 버그들과 유사한 버그들이 하나 둘씩 버그가 발견되기 시작하는 것이다. 이러한 버그들은 몇 가지 유형을 가지고 있다.

• 완전히 새로운 버그
• 예전에 수정되었는데 재발한 버그
• 익숙한 증상인데 재현 과정이 전혀 다르거나 보고된 적이 없는 버그
• 간헐적으로 발생하는 버그
• 환경마다 다른 문제를 보이는 버그

이러한 버그들이 발견될 때마다 테스트 엔지니어는 물론 프로젝트 참여자 모두가 긴장하게 된다. 누구의 잘못인지 따지려는 이들도 있고, 눈으로 보고도 머리로 이해하지 못하는 이들도 있다. 경험이 많은 이들은 당연한 일이려니 생각하기도 하지만, 주니어일수록 내가 무슨 잘못을 한 것이 아닐까 하는 스트레스에 사로잡히곤 한다.

그렇다면 왜 이런 일이 생기는 걸까? 일반적인 말일 수 있지만, 원인을 찾아보고 내 의견을 추가해보고자 한다.

첫 번째, Test Coverage가 부족했다.

그렇다. 내가 담당한 기능은 문제가 없다고 치자. 그러나 모든 기능들은 하나의 프로그램 안에서 유기적으로 맞물려 동작한다. 마치 나비효과처럼 다른 팀의 변경과 수정 내용이 영향을 끼치는 경우가 매우 흔하다. 우리는 누리가 담당한 영역 이외의 부분에 대해서도 Test Coverage를 마련해야 하는 것이다. 추가, 변경된 기능을 항상 주지하고 있어야 하고, 이를 내 업무에 즉각 반영해야 한다.

두 번째, 나 혹은 누군가의 Regression test가 부족한 탓이다.

어떤 팀들은 Regression test의 영역을 기존 테스트 케이스들을 다시 돌려보는 것으로 국한하여 활용하기도 한다. 테스트 케이스가 많을수록 이 Regression test조차도 버거워하는 경우도 흔하게 볼 수 있다. Regression test를 하는 이유는 오류 수정에 의해 새로 발생하는 오류가 없는지 확인하는 테스트이다. 당연히 기존 테스트 케이스는 모두 정상적으로 수행이 되어야 한다. (물론 일부 케이스 수정이 발생할 수도 있다.) 그러나 수정된 기능으로 인해 영향을 받을 수 있는 것이 있는지에 대해 파악하는 것이 소홀할 수 있다. 내가 담당하는 영역에서라면 모르겠으나, 다른 사람의 담당이라면 더욱 놓치기 쉬운 법이다. 때문에 우리는 변경 사항에 대하여 관련 팀들과 정보를 공유해야 하고, 테스트 방향과 Coverage를 공유해야 한다. 그리고 즉각적인 피드백으로 놓치는 부분이 없도록 해야 한다. 현실적으로 지식이 부족하여, 설계가 미흡하여, 환경적인 이유로, 또는 시간과 인력이 부족하여 충분한 Regression test가 힘들다고 한다. 그렇기 때문에 공유와 협업이 더욱 필요한 것이다.

세 번째, 애당초 버그의 분석에 부족한 부분이 있었다.

대부분의 경우 발견한 버그에 대해 재현 경로와 증상, 올바른 기대 결과 등을 기록한다. 이에 대한 더 자세한 포스팅은 이 글(“당신의 버그 리포트에 꼭 들어가야 할 내용)을 참고하기 바란다. 그런데 나는 여기에 두 가지를 더 고려했으면 한다. 바로 User/Business Impact와 Test Impact이다. User/Business Impact는 이 버그로 인해 발생할 수 있는 사용자의 불편이나 비즈니스 로직에서의 문제점을 기록하는 것이다. 이는 단순히 내가 담당하는 기능뿐만 아니라 거시적인 관점에서 버그를 바라볼 수 있는 기회를 제공하고 정확한 상황을 모두와 공유할 수 있기 때문에 모두가 문제를 인지할 수 있게 해주는 중요한 요소이다. 번외적 성격이지만 테스트 엔지니어가 얼마나 정확하게 문제를 인지하고 있는지를 나타내기 때문에 테스트 엔지니어의 역량에도 연관이 있을 수 있다. Test Impact는 이 버그로 인하여 다른 기능 테스트에 영향이 있는 Blocking bug임을 나타낼 수도 있고, Test cost와 추가 테스트가 필요한 영역에 대한 정보를 추가할 수 있는 부분이다. 이 항목을 추가함으로 인하여 보다 높은 Coverage에 다다를 수 있다.

Posted by 갼이