Quality Assurance

개발자는 프로그램의 기능이 동작하게 하고 테스터는 프로그램의 기능이 오동작하거나 동작하지 않는 경우를 없앤다. - 겐도 -

테스팅에서 가장 먼저 수행하는 것은 Smoking Test일 것이다. 전기제품을 만들었을때 전류를 가해서 어디 타는 곳이 없나 확인하는 작업에서 유래된 이 말은 어플리케이션을 만들고 릴리징 준비 단계로 들어갈 때 실제로 설치하거나 배포(Deploy)를 수행한 후 가동을 시작해 보는 작업이다. 수없는 단위 테스트로 인해 이미 더러워질 데로 더러워진, 즉 시스템의 상당 부분이 해당 프로그램이 동작하도록 설정된 환경을 벗어나서 깨끗한 곳에서 동작성을 테스트 하는 이 과정조차 한번에 되기란 그리 쉬운 것은 아니다. DLL이 누락되었거나 버전이 안맞을 수도 있고 임시 파일이나 레지스트리등의 설정값이 아예 존재하지 않아 오동작 하는 경우가 많다.

다음에 해야할 테스팅은 성공 테스트, Acceptance Test일 것이다. 권장사양에서 어플리케이션 외적인 문제가 가장 적을 것 같은 환경을 마련하고 기능 명세표에 나와 있는 기능들을 하나씩 수행한다. 기능의 동작성 자체를 검사하므로 외적인 변수를 통제하는 것이다. 메모리도 충분히 넣어주고 인터넷도 안정된 회선을 제공하며 어플리케이션을 제외한 다른 프로그램들은 거의 설치하지 않는다. 그리고 명세표를 보며 하나하나 동작시키고 체크표시를 하는 것이다.

다른 테스팅도 있을 수 있겠지만 보통 이정도 하고 나면 제품은 나간다. 그리고 다음날부터 고객센터의 전화기에는 불이 난다. 우리의 가난한 고객들은 램도 적고 인터넷은 매일 끊기며 그들의 컴퓨터에는 수백개의 프로그램이 깔려 있기 때문이다. 배포를 위한 프로그램이라면 반드시 예외 상황 테스트, Exceptional Test를 수행해야 한다.

QA에 있어 노련한 테스터가 필요한 이유는 이세상의 모든 고객의 컴퓨터에서 프로그램을 테스트 할 수 없기 때문이다. 어플리케이션의 특성에 따라 모델링을 해야 하고 특히 어플리케이션에 영향을 줄 수 있는 변수들을 정확히 예측해야 하기 때문이다. 돈이나 재화에 관련된 프로그램이라면 보안 전문가도 필요하다(물론 말뿐인 컨설턴트나 스크립트나 돌리는 점검팀을 말하는 것은 아니다). 속도차이가 현저하게 나는 두 컴퓨터간에서 프로그램을 돌리고 랜선을 뽑았다 꼽았다 하며 백신도 몇개 넣어서 중간에 보안 경고창을 띄워 보기도 한다. 열심히 연산을 하고 있는 컴퓨터의 전원을 확 뽑기도 하고 서스펜드는 물론이요 오락을 즐기기도 한다. 로긴창에 노래 가사를 적기도 하고 버튼 백연타를 한다. 숫자를 적으라는 입력창엔 왠지 특수문자를 입력하고픈 충동을 느끼기도 한다.

QA는 제품 출시 지연의 범인으로 기획자의 적이고 자신의 잘못을 콕 찍어내는 고자질 쟁이로서 개발자의 적이 되기도 한다. 평소에 으르렁 거리는 기획자와 개발자가 이때는 한마음이 되어 QA를 간략화 시키고 몇가지 보고를 너무 예외적인 상황이므로 무시하자라는 의견을 관철한다. 하지만 에드워드 공군기지에서 인간을 마하의 속도에 진입시키기 위한 실험에서 나온 "머피의 법칙"에서처럼 일어날 수 있는 사고는 일어나게 되는 것이다.

제품 출시일이 다가오게 되면 모든 사람들의 신경이 곤두서게 되고 무리수를 두기도 한다. 크리스마스 시즌에 맞추어 인형을 내어 놓으려다 <토이스토리>의 3편을 찍게 될지도 모른다.

현재 기능을 모두 갖추고 싶다면 일정을 연기하라. 일정을 지키고 싶다면 과감히 기능의 일부를 포기해라. 그러기도 싫다면 어서 절이나 교회에 가서 열심히 빌어라. 아마 평생의 운을 일순간에 써야 할지도 모른다. (사실 많은 케이스에서는 오히려 기능은 더 늘어난다.)