SDET는 테스터와는 다른 직책이다.
이전에도 여러번 언급했었습니다만, 마이크로소프트에는 SDET라는 직책과 STE라는 직책이 있습니다. SDET는 Software Design Engineer in Test이고 STE는 Software Test Engineer입니다. 직책의 역할(Job Role)이 둘간에 확실히 구분되어있는데, SDET는 우리나라에서 이야기하는 프로그래머와 같은 선상에 있는 직책을 이야기합니다.
오늘은 외부에 나가서 거기서 뭘하냐는 질문에 테스터다라고 대답한다는 사실에 대해 꾸중을 들었습니다. 그건 니 자신을 깎아내리는 짓이라고. 회사에서 그냥 일반적인 테스터는 STE를 이야기합니다. SDET가 아닌 테스터라는 역할이 작다거나 하는 뜻이 아니고, 또한 일반적인 테스터 이야기가 아니라 Sofware Test이기 때문에 더더욱 그렇습니다. 제가 하는 변명은 그것을 이해해줄 사람이 얼마나 있겠느냐는 것이었지만, 아무튼 저는 제 자신을 위해서 SDET라는 것을 널리 홍보해야하는 상황이기도 한 것은 맞는 것 같습니다. 이전에도 적은 적이 있지만 또 한번 이야기해봅니다.
Software를 테스트하는데 있어서 Software의 모든 전반에 대해 이해 정도가 있는데, 그 이해의 깊이에 따라서 STE냐 SDET냐로 옮겨가게 됩니다. 요는 Software의 Design에 대해서 얼마나 이해를 하고 있느냐는 것이고, Software의 Design을 이해하기 위한 요소 중 큰 부분 한가지가 프로그래밍이라는 사실입니다. 참고로 이해를 위해 이야기를 하면, 마이크로소프트에서는 개발자를 SDE(Software Design Engineer)라고 합니다. 말그대로 Software의 디자인에 관여하는 엔지니어라는 뜻이겠죠.
테스터의 역할은 테스팅이라고 하겠지만, SDET인 저의 정확한 역할은 잘못 혹은 엉터리 혹은 미비하게 짠 코드/기획으로 인한 버그를 찾고 그 원인을 밝혀서 어떻게 고쳐야할 것인지를 판단하고 이를 제시하는 것입니다. 이 말은 단순해보이지만 사실은 여간 복잡한 것이 아닙니다. 여러가지 요소에 대해서 쭉 나열을 해보죠. 첫째로, 그 이면에는 “문제”라는 것이 문제인 딜레마가 있습니다. 항상 그런 것은 아니지만, “문제”를 들이대면 좋아할 사람은 별로 없다는 것이죠. “문제”임에도 불구하고 “문제”가 아닌 것으로 해결하려는 경우도 굉장히 많습니다. 그래서 직접 남의 코드를 노가다로 들여다보고 디버깅하고 증거(?)로 들이대야하는 작업도 계속 생깁니다. 디버깅이라면 재미있겠지만, 증거찾을라고 남의 코드 분석/디버깅하는 일은 좀 그렇죠.
둘째로, 문제를 찾는 방법적인 것이 하나의 학문화되고 있는 부분입니다. 학문이라고 할 정도로 큰 영역이 되었다는 것이 새삼스러운 것은 아니지만, 그만큼 방대한 영역이고 어려운 영역이며 부각이 되는 영역이라는 것이기도 합니다. 테스트에 관한 논문들도 계속해서 나오고 있고, 책들도 계속해서 나오고 있죠. 그리고 테스트의 방법론은 분야만 바꿔도 적용이 안되는 경우가 허다하기도 한 영역이기도 합니다.
셋째로, 또하나는 가장 중요한 스케줄/리소스/예산등과의 밸런스입니다. 이것들이 무한대라면 모든 것을 테스트하고 완벽한 제품을 낼 가능성이 높아질 수 있다고 하겠지만, 그렇지가 못합니다. 우선순위를 매겨서 낮은 것들은 눈물을 흘리면서(?) 포기해야하는 것이 개발자들과 마찬가지로 SDET의 고충이기도 합니다. 더더욱이 작은 업체 작은 팀이라면 오히려 이런 리소스들이 영역에 비해 더 작기 때문에 더 무시하면 안되는 이유가 됩니다. 이런 문제들을 해결하는 것도 테스팅의 역할에는 들어가 있다고 하겠습니다.
넷째로, 문제(쉽게 버그라고 생각하면 좋을 것 같습니다)라는 것은 그 영역이 방대합니다. 어제 댓글에서도 언급한 내용이기도 한데, 한때는 마이크로소프트 내부에서도 SDE들이 TDD를 하는 것이 SDET의 영역과 겹치지 않느냐는 이야기가 있던 적이 있습니다. 하지만, 실제 테스팅을 하면 Unit Test나 BVT 정도로 잡는 버그로는 택도 없다는 수치적인 결과가 나옵니다. TDD는 개발자가 자신의 코드를 자신이 생각할 수 있는 만큼만 ensure하는 것이지, 실제 제품의 영역에 있어서는 큰 커버리지를 감당할 수 없습니다. 마이크로소프트에서도 SDE들이 TDD로 제품을 개발하기 시작한지 꽤 되었습니다. 표준 준수를 검사하는 Test Kit도 한 예일 것입니다. 수천개의 TestCase를 두지만, 그것을 통과한 다른 제품이라고 해도 무조건 서로 연동이 가능하지 않고, 연동/준수를 해결하기 위해서 또 무던히 테스트를 해야합니다. 다운되는 것만을 문제라고 하지 않고, 사용자가 불편해하는 사용성 부분도 문제 영역에 포함됩니다. 기획자가 잘못 기획했다면, 그것을 raise하는 것도 역할이라고 하겠습니다.
다섯째로, 노력에 비해서 성과가 작아 보일 수 있습니다. 버그 하나 고치는 것이 쉬울때는 행복하지만, 몇달/몇년이 걸릴 정도로 어려운 것들도 있습니다. 그렇게 본다면, 버그 하나 고치기 위해서 엄청난 비용을 들이는 것입니다. 버그의 경중을 떠나서 갯수로만 보면 그 역할이 필요하기나 한지 의심될 수도 있겠죠. 하지만, 그 버그의 수정으로 창출되는 부가가치를 보는 것이기 때문에 SDET라는 직업이 있는 것이기도 하겠습니다.
여섯째로, 반복되는 작업들은 자동화한다는 것입니다. 자동화라함은 테스팅을 위해서 테스트를 하는 프로그램을 짠다는 뜻인데, 이 말을 잘 살펴보면 재미있는 결과가 나옵니다. 테스팅을 하는 프로그램도 Software이기 때문에 문제가 발생한다는 것입니다. 결국 테스트를 하는 프로그램 자체도 일의 연장선이 되는 것이죠. 테스트를 위한 프로그램은 다양한 상황에서 동작해야되기 때문에 다양한 상황을 위한 수정을 하는 Robustness를 보장하는 기간이 따로 존재하기도 합니다. 저는 한국에서 한국 제품을 테스트하기 때문에, 원격 테스트의 편의를 제공하고, 다양한 한글OS에서 동작하도록, 한글 제품에 맞는 프로그램으로 만들어 주거나 직접 수정해서 사용 해야합니다. 반대로 자동화가 불가능한 것들은 시간을 들여서 직접 테스팅(Manual Testing)을 해야합니다. 아주 쉬운 예가 “게임” 테스팅이겠죠. 그냥 게임을 하면 되는 것이 아니냐는 이야기는 절대 틀립니다.^^ 게임을 즐기는 것이 아니라, 모든 상황을 구석구석 본화면 보고 또보고 해가면서 시간을 많이 사용해야하는 작업을 짧은 시간내에 하는 일입겠습니다.
일곱째로, 이런 테스트와는 별도로 제품에 익숙해지기 위해서 공부를 따로 해야한다는 것입니다. 제품을 사용하여 높은 생산성을 발휘하는 것은 다른 역할이기에 잘 써야되는 것은 아니지만, 어떤 기능이 있는가, 어떤 것이 되는가 안되는가를 알아야합니다. 어떤 문제가 있을때 이에 효과적으로 대처하기 위한 필수 사항이라고 하겠죠. 자기도 모르는 제품을 테스트한다는 것은 어불성설이겠죠.
여덟째로, 일반 Software의 플랫폼이 굉장히 다양 다분화되었습니다. OS 뿐만 아니라 Browser도 플랫폼이 되었고 하드웨어 아키텍쳐도 여러가지입니다. 저는 솔직히 98 지원이 중단된다고 했을때 좋아한 직업 중 한 직업입니다. 98은 이제 테스트 안해도 되는구나! x64 아키텍쳐가 보편화되고 있는 상황이 미운 직업이기도 합니다. 하나를 테스트해도 XP/2003/Vista와 x86/x64(or ia64)의 조합으로 해야합니다. 조만간 나올 롱혼 서버도 또하나의 플랫폼이겠죠.
아홉째로, 저(저희 팀)한테 국한된 이야기지만(현재 SDET 2명 총 6명), 제품이 한두개가 아니라는 것입니다(여러서비스를 하는 온라인 회사들도 그런 예가 되겠죠^^). 제가 테스트하는 비주얼 스튜디오 제품군을 위한 PU(Product Unit)는 30개가 넘습니다. 근자에는 Team Foundation Server라는 서버 제품도 만들었죠. 요즘 자주 회자되는 Expression 제품군도 4개의 제품으로 나뉩니다. 각 PU는 나름대로의 제품을 또 만듭니다. 최신 기술들인 비스타에 있는 .NET Framework 3.0도 저희 제품이고, WPF/E도 저희 제품이고, ASP.NET AJAX도 저희 제품입니다. 각 제품들은 또다시 서비스팩, 패치등을 비정기적으로 냅니다. OS가 업그레이드하면, 거기서 문제가 없는지도 테스트해야합니다.
되도록이면 어려운 용어는 빼고 이야기했지만, 위의 한문장처럼 간단하지는 않죠? 이외에도 하고 싶은 이야기는 산적해있습니다. 하지만, 기사가 아니고 그냥 머리에서 떠오르는 생각으로 적은 글이니, 이정도면 감은 올 듯 합니다. 다음주에 새로 SDET(스뎃;;;)이 늘어나는데, 이렇게 재미난 일인지 알고 입사를 하는 것인지 모르겠네요.^^