SOAP, 웹 서비스 등 XML 기반 기술과 BPM을 통한 프로세스 시스템 신봉자로 소프트웨어 품질에 대한 정통부 GS인증 업무를 수행하는 등 개발자 출신 QA라는 흔치 않은 경력을 가지고 있다. 현재 와이즈스톤(www.wisestone.kr) 대표이며, 소프트웨어 품질관리 교육 및 컨설팅 등을 하고 있다.
2009년 1월 20일
현재 필자의 주업은 테스팅(품질 컨설팅)이다. 필자가 외부 강연이나 발표시 소개될 때 꼭 빠지지 않는 수식어는 ‘개발자 출신 테스터’라는 것이다. 그렇다면 현재 필자는 개발자가 아닌가? 이렇게 생각해 보자. 개발 프로젝트의 PM을 맡아 전체 시스템 설계와 일정 관리를 하는 매니저는 개발자인가, 아닌가? 테스팅은 개발 프로젝트와 함께 (또는 내부에서) 일어나는 활동이다. 필자는 개발자 출신 테스터가 아니라 넓은 관점(?)의 개발자라고 생각한다.
왜 이런 얘기를 신년 벽두부터 꺼내 놓는가? 필자가 던지는 화두가 모든 개발자의 공감을 얻기 바라는 마음에서다.
필자는 테스팅과 품질에 대한 이야기를 개발자들을 향해 꺼내 놓는 것을 좋아한다. 정작 필자의 이야기에 관심을 가지고 귀 기울여줄 소프트웨어 테스팅 엔지니어나 품질 관리 담당자를 차치하고, 늘 아무리 목에 핏대를 세우고 떠들어도 관심이 없는 개발자를 상대로 품질에 대해 이야기한다. 테스팅 엔지니어나 품질 관리 담당자는 품질의 중요성을 이미 잘 아는 사람들이니 더 이상 이야기할 필요도 없으며 재미도 없다.
이 연재를 처음 시작할 때 개발자를 향해 출사표를 던진 것처럼 필자의 이야기 대상은 개발자다. 개발자들이야말로 소프트웨어 품질의 가장 근본적 영향을 주는 주체이기 때문이다. 이러한 고민 끝에 필자가 개발자를 향해 던지는 새해 첫 필살의 화두는 바로 ‘빠르게 개발하기’다.
어떻게 빠르게 개발할 것인가?
이것이야말로 많은 개발자의 공감을 형성할 수 있는 관심 주제다. 자, 생각해 보자. 개발 일정에 맞추느라 정신 없이 기능 구현을 위해 앞만 바라보며 달려왔다. 일정을 약간 초과했지만 약속한 기능의 90% 이상을 구현한 상황이다. 이제 고지가 보인다.
과연 그러한가? 출시를 위해 다른 개발자가 개발한 모듈과 합쳐 기본 운영을 해보니 여기저기 문제가 발생한다. 약속한 기능이 동작하지 않는 것은 아니다. 기능은 정상으로 동작하나 생각하지 못한 입력값에 내가 개발한 모듈에서 프로그램이 자꾸 다운된다. 10% 나머지 기능을 구현할 시간이 없다. 여기저기서 발견되는 버그에 대한 수정 요구로 정신이 없다.
일반적으로 제품에 결함이 일정 수준 이상으로 많으면 개발자는 기능 구현보다는 결함 수정에 많은 시간을 보낸다. 처음부터 소프트웨어 품질을 관리해야 했다는 것을 프로젝트 말미에 느낀다. 하지만 뒤늦은 후회일 뿐. 결국 빠르게 개발하고 싶다면 처음부터 품질 관리 기본에 충실해야 한다는 것이다.
일정이 넉넉하지 않아 개발 기간에 쫓기는 대부분의 프로젝트에서 개발 기간을 줄이려고 선택하는 방법은 비슷하다. 서로 하나씩 모듈을 전담해 개발하며 설계나 코드 검토 등을 등한시한다. 게다가 일정이 계획보다 늦어지면 선택하는 방법은 테스트 시간을 줄이는 것이다. 테스트라는 단계가 개발 일정 마지막에 위치하기 때문에 최악의 경우에는 테스트를 거치지 못하고 프로젝트 종료일을 맞을 수도 있다. 하지만 이러한 선택은 결국 개발 일정 지연으로 이어진다.
출처: Applied Software Engineering
IBM의 Jones에 조사된 상기 표는 결함 제거율이 95% 선에 있는 프로젝트가 가장 빨리 수행되었음을 보여준다. 즉 프로젝트 진행 중에 품질에 신경을 쓴 경우가 그렇지 않은 경우보다 개발 기간이 단축되었음을 알 수 있다. 또한 대부분의 회사가 위치하는 결함 제거율 50% 미만의 경우 개발 기간이 늘어났음을 알 수 있다. 아주 특별한 미션 크리티컬한 프로젝트(가령 로켓, 우주선, 비행기 등)의 경우 결함 제거율을 높이려는 노력 때문에 개발 기간이 늘어나는 경우도 있을 수 있다. 다음은 Rapid Development에서 인용한 사례다.
일정이 촉박한 프로젝트는 개발자 단계에서 수행해야 할 품질 보증을 건성으로 하기 쉽다. 출시에 30일밖에 없어서라는 이유로 귀퉁이를 잘라 버린다. 깨끗하고 독립적인 인쇄 모듈을 작성하기보다 화면 출력 모듈에 인쇄 기능을 끼워 넣는다. 확장하기 어렵고 유지보수가 힘든 나쁜 설계라는 사실은 알지만 제대로 할 시간이 없다. 제품을 빨리 완성하도록 압력을 받고 있으므로 지름길을 택하도록 내몰린다.
석 달 후, 제품은 아직 출시하지 못했고 잘라버렸던 귀퉁이가 결국 골치거리가 되어 돌아온다. 사용자자 인쇄 기능을 못마땅하게 여기므로 사용자를 만족시키려면 인쇄 기능을 크게 확장해야만 한다. 불행하게도, 인쇄 모듈을 화면 출력 모듈에 끼워 넣은 후 석 달 동안 두 기능은 완전히 뒤섞여버렸다. 인쇄 모듈을 다시 설계하고 화면 출력 모듈에서 분리하는 작업이 이제는 시간이 많이 들고 오류가 쉽게 발생하는 힘든 일이 되어버렸다.
어떤가? 자신의 이야기나 내 주위 이야기처럼 느껴지는가? 우리 모두가 공감하듯이 처음부터 소프트웨어 품질을 제대로 관리하지 않으면 종국에는 걷잡을 수 없는 문제가 되어 개발 일정이 엉망이 되어 버릴 수도 있다.
이제 바쁜 개발 일정을 쪼개 개발하는 소프트웨어의 품질 관리를 위해 테스팅을 해야겠다는 생각을 갖게 되었을 것이다. 그렇다고 하더라도 내가 지금 테스팅을 위해 소비하는 지금 한 시간이 얼마만큼의 효과로 개발 일정을 단축할 수 있을 것인지 궁금할 수 있겠다.
테스팅 레벨은 일반적으로 단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅 등으로 구분된다.
단위 테스팅은 ‘개개의 소프트웨어 컴포넌트가 기능을 정상으로 수행하는지를 테스트하는 하위 레벨 테스팅’이며, 통합 테스팅은 ‘통합된 컴포넌트나 시스템 간의 인터페이스와 상호작용에서의 결함을 중점적으로 찾는 테스팅’이다. 시스템 테스팅은 ‘명시된 요구사항을 만족하는지 확인하기 위해 통합된 시스템을 테스트하는 절차[Hetzel] 또는 컴포넌트나 부분 시스템이 하나의 시스템으로 동작하면서 시스템 기능 및 성능과 관련된 고객의 요구사항이 완벽하게 수행되는지를 모든 시스템 구성요소를 통합한 후 평가하는 테스팅’이며, 인수 테스팅은 ‘시스템이 인수 조건을 만족하는지, 사용자, 고객 또는 다른 인가된 개체가 시스템을 인수할지 결정할 수 있도록 사용자의 필요, 요구, 비즈니스 프로세스를 고려하여 수행하는 공식적인 테스팅[IEEE 610 준수]’이다. (출처 : STA 소프트웨어 테스팅 용어 사전)
일반적으로 단위 테스팅은 개발자가 자신이 개발한 코드를 검수하는 것으로 수행된다. 시스템 테스팅의 경우 개발자가 아닌 제3의 테스터에 의해 블랙박스 테스팅으로 실제 기능을 동작시켜 테스트하는 방법으로 수행된다.
Jones에 의하면 단위 테스팅을 통해 개발하는 소프트웨어의 10%에서 50% 정도의 결함을 발견할 수 있다고 한다. 시스템 테스팅을 통해서는 20%에서 60% 정도의 결함을 발견할 수 있다. 한 가지 재미있는 점은 개발자들이 일반적으로 생각하는 것과는 달리 소스 기반 단위 테스팅보다 소스를 고려하지 않는 블랙박스 개념의 시스템 테스팅의 결함 검출률이 높다는 것이다. 하지만 다음 표를 통해 코드를 개발하는 중에 발견하는 결함이 테스트 단계에서 발견하는 결함에 비해 개발 기간을 단축하는 데는 더 효과적임을 알 수 있다.
출처 : Software Verification & Validation, Steven Rakitin
상기 표는 요구사항 분석시 발견되는 결함 수정에 비해 테스트 단계에서 결함 수정이 50배 많은 비용(시간)이 든다는 것을 보여준다. 또한 출시 이후 발견된 결함 수정에는 무려 100배 이상의 비용이 든다는 것을 알 수 있다. 코드를 개발하던 중에 한 시간을 소비하여 결함을 하나 찾아 수정했다면, 그것은 향후 유지보수를 위해 소비해야 했던 다섯 시간(다섯 배의 비용)을 절약했다고 할 수 있겠다.
상기 표를 통해 알 수 있듯이 개발 기간을 단축하려면 최대한 빠른 프로젝트 진행 시점에 결함을 찾아야 한다. 코드를 작성하기 이전 단계인 요구사항 분석과 설계시에 결함을 발견한다면 개발 기간을 크게 줄일 수 있을 것이다.
그렇다면 어떤 방법으로 요구사항 분석과 설계 시점에 결함을 찾을 수 있을 것인가? 요구분석서와 설계 문서 리뷰를 통해 결함을 찾을 수 있다. Boehm에 의하면 리뷰를 통해 무려 30%에서 70%까지 오류를 발견할 수 있다고 한다. 이것은 단위 테스트와 시스템 테스트를 통해 발견할 수 있는 결함 검출률보다 높다. 또한 프로젝트 초기에 결함을 발견함으로써 개발 기간을 크게 단축할 수 있는 기회를 제공한다.
더욱 놀라운 테스팅은 코드 인스펙션이다. Gilb와 Graham에 의하면 코드 인스펙션으로 무려 60%에서 90%까지 결함을 발견할 수 있으며, 이것은 전체 개발 일정의 10%에서 30%까지 단축을 가능하게 한다고 한다.
후기
필자에게 낚였다는 생각이 드는가? 아니면 개발 일정 단축과 소프트웨어 품질 관리가 연관이 있다는 이야기에 고개가 끄덕여지는가? 이번에는 테스팅이 중요하다는 막연한 이야기가 아니라 실제 테스팅을 통해 얻을 수 있는 효과에 대해 구체적인 통계 자료를 기반으로 살펴보았다. 소프트웨어 품질에 대해 관심을 가지고 진행되는 프로젝트가 아니라면 시한폭탄을 안고 있는 것과 마찬가지라는 것을 알았다면, 필자는 새해 첫 화두를 통해 얻고자 했던 목표를 달성했다. 앞으로 필자가 계속해서 펼칠 소프트웨어 테스팅과 품질 관리 이야기에 귀 기울여줄 독자를 하나 더 얻었으니 말이다.
이올린에 북마크하기
이올린에 추천하기
이영석 
