테스팅, 그 창조적 파괴의 중요성

이미 마이크로소프트웨어를 통해 잘 읽었던 내용이고, 이 내용에 거의 모든 부분을 공감한다. 그러나, 아무리 좋은 내용이고, 당연히 그렇게 해야 함에도 불구하고, 현실은 이를 충분히 반영할 수 없는 체제다. 정말 대형의 조직이 아닌 이상, 해당 기일안에 개발을 마치는 것조차 무리일때가 많다. 아주 단순한 테스팅이 전부인, 그래서 오히려 추후에 유지보수 이슈가 더 큼에도 불구하고, 현실은 그렇게 호전될 생각을 못하고 있다. 이렇게 푸념을 늘어놓는 것이 무의함을 알고는 있지만, 나는 내 일을 사랑하고, 분명 발전되리라 믿기에 내가 있는 공간부터 작은 노력을 기울이려 한다.

===============================================================


권원일(KTB 대표, STEN 운영자)   유명 휴대폰이나 자동차의 리콜이 내부 소프트웨어의 문제에서 비롯된 것이라는 사실은 이제 공공연한 비밀이다. 하드웨어 개발을 끝내놓고도 이를 제어하는 소프트웨어의 문제로 출시가 늦어지는 일도 다반사다. 이처럼 전 산업의 화두가 된 테스팅은 점점 개발의 일부가 아니라 개발활동과 밀접한 관계를 갖는 독립적인 프로젝트라는 시각이 설득력을 얻고 있다. 테스팅을 체계적으로 관리하지 않으면 성공적으로 수행할 수 없고 결국 개발 프로젝트 전체가 실패할 수 있는 가능성은 그만큼 높아진다.

테스팅의 중요성은 누구나 알고 있으나 일반적으로 개발자들은 고정 업무만으로도 버거워 테스팅에는 시간과 관심을 크게 두지 못하는 것이 현실이다. 이렇다 보니 테스팅에 본격적으로 관심을 갖는 개발자를 찾아보기 쉽지 않고 프로젝트 관리자나 고객지원 부서 등은 가능하면 짧은 시간 안에 이를 해결하려고 온갖 방법을 동원(?)하는 실정이다.

그러나 이런 와중에도 테스팅에 대한 관심은 지속적으로 커지고 있다. 전체 개발비의 40%, 많게는 60% 이상이 테스팅 비용에 소요된다는 통계도 나오고 있으며 최근에는 기존 소프트웨어 분야는 물론 전자회사, 자동차 관련 회사 등 대부분의 제조회사가 테스팅에 큰 관심을 보이고 있다.

예를 들어 굴지의 모 전자회사는 테스팅이 요 근래 가장 큰 이슈로 부각되고 있다. 개발자, 프로젝트 관리자, 혹은 고객지원 부서 담당자 등에 의해 이슈가 되기보다는 소프트웨어(를 포함한) 제품이 출시되었는데 소프트웨어 결함으로 유지보수와 리콜 등의 비용이 발생하거나 내부 감사(Internal Audit) 등에서 ‘부적절하고 부족한 테스팅’ 이 심각한 지적사항으로 돌출되면서 이슈가 되는 것이다. 예전에도 이런 사례가 없었던 것은 아니나 최근에는 하드웨어 성능의 대부분이 소프트웨어에 의해 제어되는 경우가 많아 소프트웨어 개발에 있어서 테스팅의 중요성은 과거와 질적으로 다르다고 할 수 있다.

BMW도 소프트웨어 결함으로 리콜
최근 유명 휴대폰의 리콜. 자동차의 리콜, 교통카드 단말기의 작동 불능 사고 등은 대부분이 (내장된) 소프트웨어의 결함 때문이라는 것은 아는 사람은 다 아는 사실이다. 휴대폰은 사실상 소프트웨어 덩어리로 성능 좋은 프로세서와 저장장치를 사용해 다양한 기능을 수행한다. 자동차의 경우 신형 모델에는 80개 이상의 CPU가 탑재되고 수없이 많은 소프트웨어가 내장돼 자동차를 제어하고 고급 기능을 수행한다. BMW의 경우 소프트웨어 결함으로 리콜하는 경우가 많아 최근 소프트웨어의 품질 향상에 심혈을 기울이고 있고 그 핵심에 소프트웨어 테스팅이 자리하고 있다.

이처럼 소프트웨어가 전통적인 컴퓨팅 영역을 탈피해 가전, 무선단말기, 산업기기 등 전방위로 확산되면서 소프트웨어 개발 공정은 물론 개발이 끝난 제품의 소프트웨어 오류를 사전에 진단하고 정상 작동여부를 시험하는 테스팅의 중요성이 점점 부각되고 있다. 반면 국내에는 전문가가 적어 유수의 전자회사들은 물론 많은 관련 기업들이 테스팅 인력 확보에 어려움을 겪고 있다. 이들의 경우 그 대안으로 계열 SI(System Integration) 회사에 파견을 요청하고 책정된 인건비를 계열사에 지불하는 방식으로 인력 부족을 해결하고 있다.

그렇다면 테스팅의 정확한 범위와 테스터의 역할을 무엇일까. 한가지 흥미로운 것은 독자 여러분들이 개발자로서 이미 직간접적으로 테스팅 활동에 참여하고 있다는 사실이다. 개발하는 과정에서 자신이 개발한 부분의 기능이 잘 동작하는지 확인하는 것이 바로 코드 레벨에서의 테스팅이다. 시스템 유지보수를 위해 업데이트된 부분을 확인하기도 하고 사용자들의 불만 사항과 사용자가 발견한 결함에 대해 커뮤니케이션을 하는 것도 모두 테스팅의 영역에 포함된다.

이처럼 현재의 테스팅 개념은 과거와는 조금 다르다. 테스팅이란 응용 프로그램 또는 시스템(구성요소를 포함해서)의 동작과 성능, 안정성이 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘으로 응용 프로그램 또는 시스템이 잘 작동하는지를 확인하는 것이 전통적인 테스팅 개념이었다면 현재의 테스팅은 사용자의 기대 수준과 요구 사항에 맞게 구현되고 동작하는지를 확인하는 것도 포함하며, 특히 이런 작업을 통해서 결함을 발견하고 최종적으로는 결함 데이터를 근간으로 개발 프로젝트의 리스크(Risk)에 대한 수치적인 판단 근거를 의사결정권자에게 전달하는 작업도 포함한다. (그러므로 기대 동작, 성능과 안정성은 명확하게 작성되고 측정 가능해야 한다). 흔히 테스팅을 디버깅(Debugging)과 혼동하곤 하는데 디버깅은 문자 그대로 결함 즉 ‘버그’를 제거하는 것이므로 디버깅과 테스팅은 본질적으로 다르다. 한편으로는 디버깅을 테스팅 프로세스의 한 부분으로 보기도 한다. 테스팅이 품질을 탐지하는 수단이라면 디버깅은 품질을 개선하는 수단인 셈이다.

테스팅의 가장 큰 매력은 결함 데이터를 이용해 수치적으로 현재 개발 프로젝트의 상태를 파악할 수 있다는 점이다. 개발자가 지난 여름밤에 급해서 대충 개발하거나 과도한 업무로 졸면서 개발한 것을 구체적인 수치를 제시하며 밝혀내어 섬뜩하게 만들 수도 있다.

실제로 국내 모 기업의 홈네트워킹 시스템 개발 사례의 경우, 결함이 발견(open)되는 수가 수정(close)되는 수보다 많거나 전체적으로 수정해야 할 중요도 높은 결함이 많아 출시 예정일을 몇 개월씩 늦출 수밖에 없었고 이 때문에 인건비 등으로 5억 원 가량을 추가로 지불해야 했다. 제품 출시가 늦어져서 발생하는 기회비용까지 포함하면 그 피해 규모는 수십 억 원에 달했다.

전문 테스팅 조직의 필요성
휴대폰 관련 사례도 있다. 모 전자회사는 10억 정도의 개발 비용을 들여 신제품 단말기를 개발했다. 그런데 출시 예정시기를 맞추느라 테스팅을 충분히 하지 못했다. 예전에 잘 돌아가는 것이 입증된 기반에서 일정 부분만 변경하였으니 문제없을 것으로 판단하고 예정된 출시일에 시장에 출하를 했다. 그러나 소프트웨어 결함으로 인한 업그레이드 등 유지보수를 위해 100억 이상의 추가 비용이 소요됐고 엄청난 기업 이미지 손상을 입고 말았다.

이처럼 최근의 테스팅은 개발팀이 모두 맡아 하기에는 일이 너무 많고 복잡한 프로세스를 갖고 있다. 테스트를 계획하고 설계하고 수행한 후 결과 리포팅을 하는 것은 물론 테스트 프로세스를 개선하기 위한 테스팅 전담 조직이 필요하고 그 중요성이 계속 커질 수밖에 없다. 전문적인 테스팅 조직이 필요한 또 다른 중요한 이유는 ‘중이 제 머리를 깎지 못하기’ 때문이다. 개발자는 자신이 개발한 소프트웨어가 잘 돌아가는 것을 확인하고자 테스팅을 하지 ‘자기의 자식’을 파괴하고자 테스팅을 하지는 않는다. 또한 개발조직이 발견하는 결함과 테스팅 조직이 발견하는 결함은 본질적으로 다르다. 1970년대 말 Glendford J. Myer는 다음과 같은 예를 들면서 그 차이점을 설명하였다.

길거리에서 애인이 없는 총각과 임신을 한 주부가 같이 있는 경우 총각은 길거리에 다니는 사람 중 자신의 관심 대상인 젊은 여성이 눈에 많이 띄지만 아기를 임신한 주부들은 아기에 관심이 많기 때문에 거리의 아기들이 눈에 많이 띄게 된다.-Glendford J. Myer

테스트를 수행하면서 잘 작동되는 것을 보여주려는 의도를 갖고 있으면 결국 결함은 보이지 않게 되지만 잘 작동이 되지 않는다는 것을 보여주려는 의도를 가지고 있으면 결함이 더 잘 보이게 된다는 것이다. 이렇게 다른 시각(사용자의 시각 & 전문화된 테스터의 시각)에서 더 다양한 결함을 발견하고 이를 체계적으로 테스팅하고 결함을 관리하며 동시에 테스팅 방법과 프로세스 개선을 지속하는 테스팅 조직이 최종 산출물의 품질을 높이고 추후에 발생할 비용을 줄여주는 것이다.

개발 조직은 결함을 발견하는 것을 자체적으로 하지 않음으로서 많은 시간을 절약하게 되고 더욱더 개발에 집중할 수 있다. 물론 예상치 못한 결함이 너무 많이 발견되어 결함 수정에 소요되는 시간이 늘어날 수는 있지만 이것은 향후 리콜 비용을 고려하면 전체 비즈니스 측면에서 당연히 좋은 일이다.

국내 테스팅의 한계
현재 국내에서는 테스팅에 대한 인식이 많이 부족한 실정이다. 실제로 현장에서 다양한 개발자들과 경영자들을 만나다보면 ‘중요한 것 같기는 한데, 뭐 그거 대충해서 프로그램만 잘 돌아가면 되고 사이트에 설치되어 사용자들이 큰 문제없이 쓰면서 수정 요구사항과 결함이 나오면 그 때 처리해 주면 되지’하고 답변하곤 한다.

실제로 별 문제없이 넘어가는 경우도 많다. 그러나 가장 심각한 경우는 개발비용보다 유지보수 비용이 더 많이 들어가는 경우다. 또한 최근에는 품질에 대한 인식이 높아져서 사용자들이 기대하는 수준이 높고 이에 부응해 주지 못할 경우 개발 프로젝트가 실패하거나 제품이 시장에서 실패해 비즈니스에 큰 손실을 주는 경우가 종종 발생한다. 국내 개발 문화상 프로젝트에 실패한 경우 그 내용이 외부로 드러나지 않고 있지만 상당수의 개발 프로젝트가 성공적이지 못하거나 크게 손실을 보고 있는 것으로 알려져 있다. 이 중 대부분은 적절하지 못한 리스크 관리 때문이며 만일 적절하고 체계적인 테스팅이 개발 프로젝트와 함께 했었다면 결과는 크게 달라졌을지도 모른다.

테스팅 관련 문제점들은 개발의 문제와 밀접하게 관련되어 있다. 개발 자체가 실제 소요될 시간보다 짧은 시간에 부족한 인력과 리소스로 진행되고 있기 때문에 테스팅에 대한 투자를 고려하기 힘들고 그저 밤샘해 가며 시간 내에 적절하게 끝내기 바쁘다. 이런 개발 환경에서 테스팅을 체계적으로 해야 한다고 하면 대부분의 개발 현장에서는 “중요하기는 한데 도저히 그 정도까지 테스팅할 여력이 안 됩니다. 누가 몰라서 안하나요?”하고 일축한다.

필자가 업계에서 테스팅에 관심 있는 개발자와 테스트 엔지니어 등을 대상으로 테스팅 교육을 진행해보면 놀라운 점들을 여러 가지 발견하게 된다. 관심을 가지고 있거나 테스팅 업무를 하고 있는 사람들이 테스팅에 대해 너무 단편적으로 알고 있다는 것이다.
테스팅의 가장 중요한 개념인 ‘테스트 커버리지(Test Coverage)'에 대한 개념을 제대로 이해하고 사용하는 수강자는 거의 없고 그나마 알고 있는 테스팅 개념과 기법들을 적용하고 있는 경우는 더 찾아보기 힘들다.

바쁘기 때문에 닥친 것과 시키는 것 하기에도 바쁜 것은 알지만 모든 분야가 다 그렇듯이 테스팅 분야도 이론적인 부분을 현업에 나름대로 적용하는 노력을 하지 않으면 현재의 테스팅 수준을 답보할 뿐 경력이 있는 테스트 엔지니어의 역량도 한계가 명확하다.
이러한 문제점은 그 동안 국내의 테스팅 인력의 성장을 돕는 테스팅 교육과정이 거의 없었던 것도 그 하나의 원인이라고 할 수 있다. 최근 테스팅 인력 수요에 대처하기 위해 몇몇 교육과정이 개설되고는 있지만 아직도 턱없이 부족한 실정이다.

현재 국내에서 진행되고 있는 테스팅 교육과정은 STEN에서 비정기적으로 진행해오고 있는 ‘테스팅 실무 기초 과정’과 한국썬마이크로시스템즈가 STEN과 함께 정기적으로 진행하는 ‘SW 테스팅 실무 & 자격증 대비반’이 있으며, 한국정보통신기술협회(TTA)에서도 정기적으로 테스트 전문가 양성과정을 개설하고 있다. 그 밖에도 버그 테스트 등 테스팅 전문회사에서 자사 테스트 엔지니어와 고객사 테스트 엔지니어를 위해 자체적인 테스팅 교육과정을 운영하고 있다.

테스팅에 대한 기본 시각이 문제
참고로 테스팅 전문 자격증은 전 세계적으로 ISTQB, CSTE 등 크게 2가지가 존재한다. ISTQB(International Software Testing Board)는 비영리적인 국제 조직에서 운영하는 자격증 프로그램으로 미국, 유럽은 물론 아시아 지역까지 퍼져 있는 3가지 레벨로 이루어진 국제 자격증이다. 국내에는 올해 2월에 도입되어 Foundation 레벨의 경우 현재 100여 명 정도가 자격증을 취득했고(Advanced/ Expert 레벨 취득자는 아직 없음), 2달에 한 번 있는 시험을 통해 지속적으로 자격증 소지자가 배출되고 있다(현재 삼성전자에서 가장 많은 자격증 취득자를 보유하고 있다). CSTE는 미국 QAI라는 사설조직이 주관하는 소프트웨어 테스팅 전문 자격증으로 STEN을 통해 1년에 1회 시험이 국내에서 호스팅되고 있으며 현재 10명 이하의 취득자가 존재한다. 해당 자격증은 서술식의 주관식 문제를 포함하고 있어 비영어권에서 취득하기 어려운 자격증으로 알려져 있다.

국내 테스팅의 또 다른 문제는 의사결정권자 또는 매너저들의 테스팅에 대한 인식 부족을 들 수 있다. 필자 역시 경험했던 것이지만 의식있고 적극적인 테스트 엔지니어들이 사명감을 가지고 아무리 테스팅을 제대로 해보려고 해도 임원들이 그 중요성을 이해하지 못하고 자꾸 제동을 걸기 때문이다. 그래서 매니저급과 의사결정권자 수준의 관리자들을 설득해 테스팅에 대한 우호적인 분위기를 만들어 주는 것이 가장 도움이 될 것이라는 의견도 있다.

이러한 현상의 근본적인 이유는 테스팅을 투자가 아닌 불필요한 비용으로 보기 때문이다. 그러나 잠시만 생각해 보면 테스팅은 어떤 개발활동보다 더 확실히 수치적으로 ROI(Return On Investment)를 제공하는 활동이라는 것을 알 수 있다. 이런한 개발 프로젝트의 중요 활동을 불필요한 비용으로 보고 가능한 줄여 보려는 노력이 향후 더 큰 비용을 유발하고 극단적인 경우에는 비즈니스 자체가 위험에 처하게 되는 경우도 발생한다.

테스팅을 줄이거나 없애려는 노력은 이미 더 큰 비용을 유발하거나 개발 프로젝트 또는 비즈니스의 리스크를 높이는 것으로 기정사실화되어 있으므로 다른 시각과 방법으로 접근하는 노력이 요구된다. 테스팅을 더 적극적으로 활용하여 개발 결과물의 완성도(Stability)와 품질을 높이고 실제적으로 개발 기간을 단축하는 시도(리소스를 효과적으로 투입하는 방법)가 바로 그것이다. 이는 이미 해외선진국에 여러 프로젝트에서 유사한 결과를 통해 확인된 사실이다.

테스팅 선진국의 ‘테스팅 인식’
필자가 속한 STEN은 지난 8월말에서 9월초에 걸쳐 진행한 테스팅 세미나에서 테스팅 명저 의 저자인 Bart Broekman을 초청했었다. 당시 그를 만나서 느낀 것은 교육을 통해 배운 지식보다 사적으로 일주일간 식사하고 서울을 돌아보며 나눈 이야기들이 더 머릿 속에 남는다는 것이었다.

Bart Broekman은 15-18년에 필립스에서 개발하다가 선구자적인 매너저 한 명의 설득으로 테스팅을 시작했다고 한다. 3년 정도 테스팅을 하다가 그 테스팅 매너저를 따라 현재 재직 중인 Sogeti로 옮겨갔는데 첫 테스트 프로젝트는 5명이 고객사의 테스팅에 컨설턴트로 참여하는 것이었다고 한다.

당시 그는 컨설턴트로 참석하게 되어 개발자보다 훨씬 높은 수익을 회사에 가져다주었고 테스팅 전문가가 귀한 시절이라 좋은 대접을 받으며 일을 했다고 한다. 그것이 이어져서 지금까지 그 회사에서는 테스팅이 개발보다 더 높은 수익성을 보이고 있다. Bart Broekman이 소속돼 있는 네덜란드 지사에 직원이 2500명인데 그 중 500명이 테스트 전문가라고 한다. 그 중 또 다른 유명한 사람이 TPI(Test Process Improvement)의 창시자 Tim Koomen이고 세계적으로 유명한 테스트의 선구자인 Martin Poll도 그 회사 사람이다. 그 밖에도 Erik van Veenendaal 등 최근 많은 활동을 하고 있는 테스팅 업계의 거물급들이 즐비하다.

이 회사가 이렇게 유명한 테스트 전문가를 보유하고 있는 이유는 무엇일까. 그 회사에서는 테스팅이 개발보다 더 수익성이 좋기 때문에 테스트 전문가들에게 자유시간을 더 많이 허용하며, 프로젝트가 끝나면 경우에 따라 책을 집필해서 지식 베이스를 만드는 것을 지원해 준다고 한다. 라 는 책도 이런 지원을 통해 빛을 보게 됐고 10여 년 전부터 지속적으로 출판한 다른 서적들을 기반으로 쓰였다. 이렇게 지식 베이스가 쌓여 테스팅 프로젝트를 더 높은 수준으로 수행하고 그것이 또 다른 서적 발간으로 연결된다. 책 내용의 2/3 정도는 이미 회사에 지식 베이스로 있으니 책 저술에 크게 시간을 들이지 않아도 양질의 서적이 발간될 수 있는 것이다. 이렇게 출판된 책은 세계의 유수 기업으로부터 테스팅 프로젝트 의뢰라는 부산물을 지속적으로 이끌어 냈고 이들로부터 높은 가격을 받고 테스팅 프로젝트 수행이나 컨설팅을 할 수 있게 됐다.

그가 들려준 필립스 메디컬 센터의 테스팅 사례도 매우 인상 깊었다. 필립스 메디컬 센터는 2000년까지 열심히 의료 장비에 들어가는 소프트웨어를 개발하고 테스팅해 왔다. 생명과 관련된 소프트웨어를 다루고 있어 테스팅에 많은 투자를 해왔으나 테스팅이 전체 개발의 병목으로 작용하는 어려움을 겪게 되었고 2000년에 문제의 심각성이 전반적으로 제기됐다. 이를 극복하기 위해 2001년부터 여러 가지 노력을 기울여 2005년 4월에 80%의 테스팅 비용을 절감하고 50%의 소프트웨어 문제 해결 비용을 절감했다. 어려움을 극복하기 위한 활동의 핵심은 <그림 1>과 같이 테스트 프로세스 평가(심사) 및 개선 활동이었고 전 테스트 인력과 개발인력들에게 ISTQB 자격증 취득을 의무화하는 등의 교육도 밑바탕이 됐다.


<그림 1>을 보면 개발 측면에서는 객체지향(OO) 방법론과 컴포넌트 기반 개발(CBD) 방법론, RUP(Rational Unified Process), XP(eXtreme Programing) 개발 방법론, SPI(Software Process Improvement), PSP, TSP(Team Software Process) 등의 발전과 개선 노력으로 개발에 소요되는 노력을 많이 줄여가고 있는 반면 테스팅은 소프트웨어 품질의 중요성과 소프트웨어/시스템의 복잡도가 증가함에 따라 더 많은 노력을 요구하고 있어 지속적인 도전을 받고 있으며 필립스의 경우 이를 효율적으로 통제하고 있음을 알 수 있다.

개발자 커리어로도 매력적
최근 테스팅의 필요성이 급속히 부각되고 있다. 소프트웨어 회사는 물론 국내의 거의 모든 (전자)회사들의 제품에 소프트웨어의 비중이 증대되면서 테스팅이 개발만큼이나 관심의 대상이다. 오히려 개발보다 잘 못하는 부분이어서 그런지 테스팅 역량을 강화하기 위해 혈안이다. 대부분의 유명 전자회사 사업부서는 물론 개발 지원 부서에서도 테스팅 인력을 확보하기 위해 구인 활동을 다방면으로 하고 있고 필자에게 개인적으로 부탁을 하는 경우도 많다. 반면 요구하는 능력을 갖춘 인력이 거의 없어 요구 인력의 1/20도 채 뽑지 못하고 있다.

특히 개발 분야는 개발 커리어가 연령적 한계가 있는 반면 테스팅 커리어는 상대적으로 연령 때문에 커리어가 제한되는 경우가 적다는 매력도 있다. 또한 개발 경력이 많으면서 테스트 전문지식을 습득하고 테스트 실무 프로젝트 경험을 갖추면 가치는 더욱 높아진다. 다시 말해 개발 경험이 풍부하면서 테스팅을 전문적으로 배우고 경험한 인력이 최고의 대우를 받는다. 그런 인력은 결국 개발 인력이 테스팅 쪽으로 이동함으로써 가능한데 현재는 그런 경우가 많지 않다. 이 부분에 있어서도 개발자와 매니저의 인식 전환이 필요하다(반면 테스팅 경험을 쌓은 사람이 개발 분야의 일을 시작하면서 두각을 나타내는 사례가 해외 선진국에는 다수 있다).

소프트웨어 테스팅은 지식 영역이 넓고 잘 정립된 전문분야이다. 소프트웨어 역사와 함께 발전해 왔고 현재는 체계적인 지식체계(Body of Knowledge)를 갖는 ‘Profession'이다. 소프트웨어 테스트를 수행하기 위해 필요한 기본적인 개념과 테스트 전략, 계획, 설계 기법, 테스트 케이스 작성, 결함 관리, 지원 도구, 정적 테스팅(Static Testing) 기법, 비기능성 테스팅 기법, 테스트 프로세스 관리 등의 분야를 포함한다. 여기에서 테스팅 지원 도구 중 자동화 도구 관련 주제만도 광범위하며 자동화 도구를 사용하는 것만으로도 전문적인 커리어를 가질 수 있다. 또한 비기능성 테스팅 기법의 한 가지(예를 들어 보안성 테스팅(Security Testing), 신뢰성 테스팅 등) 분야만 전문지식과 경험이 있어도 전문적인 커리어를 가져갈 수 있을 정도로 테스팅 분야는 넓고 매력적인 분야이다. 그 밖에도 이러한 테스팅 컨셉, 기법 및 관리 방법을 소프트웨어 종류별로 최적화하여 적용하는 것이 테스팅에서 중요한 부분이며 일반적인 커리어 형태의 하나이다.

현대의 소프트웨어 테스팅은 개발의 일부가 아니라 개발 활동과 밀접한 관계를 갖는 독립적인 프로젝트로 보는 것도 이 때문이다. 테스팅은 제한된 시간, 인력, 장비 등의 리소스로 비즈니스 리스크를 최소화하기 위한 일련의 활동이다. 이는 체계적으로 관리되지 않으면 성공적으로 수행하기 어렵고 결국 개발 프로젝트 전체가 실패할 수 있는 가능성을 높이게 된다.

이 글을 통해 테스팅에 대한 막연한 이해가 더 넓어지는 기회가 됐으면 한다. 이 밖에도 소프트웨어 테스팅 분야에서 다뤄야 할 주제가 많고 이번 글에서 언급된 내용도 표면적으로 다루기는 했지만 많은 부분 여러분의 공감을 얻었으리라 생각한다. 업계에서 지금부터라도 테스팅에 대해 더 관심을 갖는다면 국내 소프트웨어 산업이 선진국 대열에 올라가는데 소요되는 시간도 단축될 것으로 믿는다.

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.