개발자 테스트의 중요성
테스트의 회차 줄이기
'테스트(test)'라는 단어의 사전적 의미는 "널리 사용되기 전에 어떤 것의 품질, 성능, 신뢰성을 수립하기 위한 절차"를 의미한다. 이 글은 Shift-left testing이나 TDD(Test-driven development)와 같은 방법론을 말하고자 하는 것은 아니다. 우리가 집중해야 할 지점은 '테스트'라는 단어의 의미 그 자체이다. 사람들은 간혹 누군가 근사하게 만들어 놓은 단어에만 집중하고 본래 집중해야 하는 부분들을 놓치곤 한다. TDD는 훌륭한 소프트웨어 개발 프로세스이지만, 본질을 해결하기 위한 여러 수단 중 하나일 뿐이다.
'개발자 테스트'란 프로그램을 작성하는 프로그래머가 직접 그 프로그램을 테스트하는 행위를 표현하는 의미로 사용했다. 나는 개발자가 스스로 자신의 프로그램을 테스트하는 것이 매우 중요하다고 생각한다. QA팀이나 테스트 전문조직에서 수행하는 품질 검증 활동은 널리 사용되는 소프트웨어를 만들기 위해서는 필수적이다. QA팀은 프로그램을 효율적으로 테스트하기 위한 전략과 계획을 수립한다. 체계적으로 수립된 전략과 계획은 소프트웨어 생명주기 파이프라인을 효율적으로 운영할 수 있도록 도와준다. 하지만, 그 전략과 계획의 전제가 되는 필수적인 요건이 있다. 그 요건은 개발자가 충족시켜줄 수 있다.
개발자는 QA조직에서 테스트를 하기 전에 프로그램의 품질을 최대한 올려두어야 한다. 모든 부분에서 품질을 미리 올려두는 것은 불가능하다. 그것이 가능하다면 QA팀의 역할이 커야 할 이유도 없다. 전반적인 품질을 사전에 올려두는 것은 힘들겠지만 개발자들이 직접 테스트를 수행하는 것이 유리한 지점들은 분명히 있다. 마찬가지로, 개발자들이 아닌 QA조직에서 테스트를 하는 것이 불리한 지점도 존재한다. 그 두 가지에 대해 이야기하고 싶다.
먼저 개발자가 직접 테스트를 하면 아래와 같은 장점이 있다.
아주 간단한 이슈는 즉시 처리할 수 있다.
'간단한 이슈는 직접 하지 않아도 간단한 거 아닌가?'라고 생각할 수도 있겠지만 그렇지 않다. '전체 이슈의 개수'는 생각보다 중요하다. 이슈의 수가 많아지면 의사결정을 하기가 어려워진다. 숫자가 클수록 프로젝트 구성원 전체의 사기도 저하된다. 큰 숫자를 만났을 때의 사람들의 마음가짐과 작은 숫자를 만났을 때의 마음가짐은 다르다. 이슈의 숫자가 많으면 그것들을 해결해야 하는 개발자들도 지친다. 어떤 것이 값이 싼 이슈인지 비싼 이슈인지 가늠하는데도 에너지를 쏟아야 한다. 부가적으로는 즉시 처리한 문제에서 발생한 사이드 이펙트를 재차 빨리 수정할 수 있다. 물론 사이드 이펙트가 없도록 수정하는 것이 이상적이겠지만 현실은 그렇지 않은 경우가 많다.
재현 절차를 정리하는 시간을 아낄 수 있다.
프로그램의 재현 절차를 코드가 아닌 사람의 언어로 정리하는 작업은 꽤 힘든 작업이다. 작성하는 것 자체도 힘들고 정보의 손실도 크다. 테스트 조직에서는 이슈를 발견하면 그것을 재현하는 스텝을 반드시 설명해야 할 의무가 있다. 재현 스텝을 설명하는 것은 비용이 큰 작업이다. 시간도 많이 들어가고, 정보도 많이 필요하다. 개발자가 필요한 정보가 어떤 것인지 알기 어렵기 때문에 최대한 많은 정보를 한 번에 담아야 한다. 그로 인해 작업시간도 길어지고 써야 할 문자의 양도 늘어날 수밖에 없다.
복잡한 재현 절차를 간소화할 수 있다.
테스트팀에서 프로그램을 테스트하는 경우에 테스트를 하기 위한 초기 조건을 만드는 것이 어려운 경우가 비일비재하다. 개발 초기 단계의 테스트에서는 어렵지 않겠지만, 여러 모듈과 컴포넌트들이 상호작용하기 시작하면 테스트를 하기 위한 상태를 만드는 작업 비용이 점점 커지게 된다. 하지만, 개발자가 직접 테스트를 하다가 이슈를 발견한 경우에는 초기 상태를 만드는데 들어가는 비용을 크게 줄일 수 있다. 개발자들은 코드에서 필요한 부분만 발췌하여 간단하게 동작하는 프로그램을 만들 수 있다. 그 프로그램으로 문제를 빠르게 재현함으로써 테스터의 복잡한 이슈 재현 비용보다 훨씬 저렴한 비용으로 트러블슈팅을 할 수 있다.
개발자 테스트가 미흡해서 생기는 가장 큰 문제는 아마도 QA차수가 증가하는 현상일 것이다. 개발 단에서 해결되지 않고 QA단계로 넘어오는 이슈들은 QA활동에 투입되는 비용을 폭발적으로 증가시킨다. 개발자가 테스트에 시간을 쏟는 작업 비용이 더 클 것 같이 느껴지지만, QA활동 중 앞단에서 걸러지지 못한 이슈를 처리하는 비용이 훨씬 크다. 그것은 마치 우리가 재활용 쓰레기를 분리수거하는 것과 비슷하다. 각 가정에서 재활용 쓰레기를 재활용 쓰레기 처리 지침대로 잘 처리하여 분리수거한다면 쓰레기를 최종적으로 처리하는 곳에서의 효율이 크게 증가할 것이다. 각 가정에서 개별적으로 지침을 지키는 비용은 싼 편이다. 쓰레기의 양 자체가 많지 않기 때문이다. 하지만, 말단에서 쓰레기를 처리하는 작업은 쏟아지는 쓰레기들을 분류하고 정리하는 작업을 거쳐야 하기 때문에 투입되는 인력과 시설비용이 만만치 않을 것이다. 의도치 않게 개발자들이 만들어 낸 산출물을 쓰레기와 비유한 것 같아서 마음이 좋지는 않다. 아마도 좋아하는 사람들도 있겠지만 말이다.
그렇다면 QA차수가 늘어나면 어떤 비효율이 있는 것일까?
매 차수마다 커다란 보고서가 생성되어야 한다.
여기서 말하는 보고서는 여러 종류의 문서 산출물을 모두 아우르는 것이다. 버그 리포트, 품질 검증 활동 결과에 대한 요약과 세부사항, 테스팅 인력 투입에 대한 정리 등등이 있을 것이다. 문서는 템플릿으로 만들어져 있긴 하겠지만 결국 그 템플릿에서 요구하는 내용은 채워야 한다. 여러 경험을 통해 깨달은 바로는 문서작업이 길어지면 질수록 사람들은 쉽게 지친다. 작성하는 사람도 지치지만 그것을 받아보는 사람도 지친다. QA차수마다 커다란 보고서를 전달받는다면 그것을 읽고 검토해야 할 사람들의 피로도도 함께 올라가게 된다.
많은 인력들이 차수마다 투입되어야 한다.
많은 사람을 정해진 기간 안에 투입하는 것은 생각보다 어려운 작업이다. 여러 사람들의 스케줄을 맞춰야 하고, 소통해야 하고, 작업을 분배해야 하고, 나눠서 진행한 작업에 대한 결과를 병합해야 한다. 그나마, QA차수마다 테스트해야 할 빌드라도 제시간에 도착하면 다행이지만 그렇지 않은 경우에는 더더욱 비용이 늘어나게 된다.
시간이 낭비된다.
QA차수의 시작부터 종료까지는 길든 짧든 시간이 걸리게 마련이다. 그 시간 동안 개발자들은 지속적으로 더 빠르게 움직일 수 있는 준비를 해야 하지만 현실은 그렇지 않다. 개발자가 비는 시간이 생기면 새로운 스펙이 그 틈을 비집고 들어온다. 결국, QA를 진행하는 동안 새로운 스펙을 개발하게 되는 경우도 심심치 않게 볼 수 있다. 다음 QA차수가 진행될 때는 기존에는 발견하지 못했던 새로운 결함이 나타나게 될 것이다. 이것이야 말로 밑 빠진 독에 물 붓기가 아닌가 싶다.
QA차수를 줄이는 것은 매우 큰 비효율을 해결하는 것이다. 테스트 차수가 한 차수 증가할 때마다 프로그램을 게시하기까지 드는 전체 비용은 가파르게 증가한다. 비용이 증가할 뿐만 아니라 프로젝트 구성원들과 스테이크홀더(Stakeholder)들도 함께 힘들어진다. QA차수를 줄이는데 가장 효율적인 방법은 개발자 테스트를 하는 것이다.
결론적으로 개발과 테스트라는 행위가 이루고자 하는 최종적인 목표는 동일하다. 좋은 품질로 널리 사용되는 것이다. 작성 중인 프로그램이 널리 사용되기 위한 상태에 도달하게 만드는 것은 개발자가 필수적으로 해야 할 일이다. QA조직이 있건 없건, 테스트를 하는 방법론이 있건 없건, 어쨌든 개발자들은 어떤 수단을 써서 그것이 가능하도록 만들 의무가 있다. 그중에서 개발자 테스트는 꽤 효과가 있는 방법이라고 생각한다.
