좋은 테스터가 되기 위한 요건

이영석 stone@sqe.co.kr SOAP, 웹 서비스 등 XML 기반 기술과 BPM을 통한 프로세스 시스템 신봉자로 소프트웨어 품질에 대한 정통부 GS인증 업무를 수행하는 등 개발자 출신 QA라는 흔치 않은 경력을 가지고 있다. 현재 (주)와이즈스톤 대표이며, 소프트웨어 품질관리 교육 및 컨설팅 등을 하고 있다. 2008년 01월 15일

필자는 군 생활을 상무대 기계화학교에서 했다. 입대 후 군인이 되기 위한 4주 기본 군사 훈련을 마치고 나서 각자 군 복무중에 수행할 역할을 부여 받는다. 일부는 부여 받은 역할을 수행하기 위한 추가 군사 교육을 받게 된다. 일부는 통신병 역할을 수행하기 위해 통신학교로, 일부는 포병 역할을 수행하기 위해 포병학교로, 또 일부는 군대 내 사무 업무 지원을 위해 행정학교로 가는 등 각자 부여 받은 역할을 잘 수행하기 위한 교육을 추가로 받는다.

필자가 복무한 기계화학교는 탱크와 장갑차를 조종하는 조종사를 교육하는 곳이었고, 함께 군 복무를 한 사람들 대부분은 이러한 교육 수료 이후 각 부대로 배치되지 않고 후배를 교육하는 교관 역할을 부여 받고 학교에 남게 된 사람들이었다.

좋은 군인의 요건

군 생활 중 재미있는 점을 하나 발견했다. 국군의 날 행진에 참여할 기수를 차출해야 한다는 상부 지시가 있었고, 부대 내에서 누구를 뽑아야 하는지 논의 후에 기수 역할을 할 사병 두 명이 선정되었다. 선정된 기수 두 명은 부대에서 인물이 가장 좋고 각(?)이 잘 나오는, 체격 요건이 좋은 사람들이었다. 그럼에도 불구하고 객관적으로 볼 때 이 사병 두 명은 170cm가 조금 넘는, 기수를 하기에 키가 조금 작은 사람들이었다. 부대에서 체격 조건이 가장 좋은 사람으로 그 사람들이 선정될 만큼 사병들이 대부분 키가 큰 편이 아니었다.

사병들이 대부분 키가 작은 이유는 탱크와 장갑차의 실내 공간이 좁기 때문이다. 우리가 일반적으로 생각하는 군인의 대표적인 이미지는 '람보'나 '코만도'의 주인공들처럼 큰 덩치에 우락부락한 '근육맨'일 것이다. 작고 호리호리한 사람을 보고 멋진 군인의 이미지를 떠올리기란 쉽지 않다. 하지만 탱크와 장갑차를 조종할 조종병들에게 좋은 체격 요건은 일반적인 조건과는 다를 수밖에 없다. 좁은 실내 공간에서 효과적으로 움직이려면 덩치가 큰 사람보다는 작은 사람이 유리하기 때문이다. 과거 러시아에선 탱크 조종 공간이 아주 비좁아 난쟁이를 뽑아 탱크 조종을 시켰다고 한다.

이렇듯 역할을 수행할 적임자란 일반적인 기준이 아닌, 그 역할에 따라 요구되는 특별한 조건과 기준을 만족하는 사람이라 하겠다. 테스터도 그 역할에 따라 요구되는 나름의 조건이 있다. 그러한 요건을 갖춘 사람이 좋은 테스터라 할 수 있다.

위로

좋은 테스터의 요건

이제 소개할 조건은 어디에서 인정을 받아 권위가 있거나 절대적인 것은 아니다. 하지만 테스팅을 업으로 하는 필자로서는 상당히 납득이 가는 재미있는 조건이라 생각한다. ^[1]

탐구적인가
테스트는 의구심을 가지고 문제를 가정하여 그 문제를 찾아 가는 사람이다. 이런 업무에 반드시 필요한 것이 탐구심 ^[2]이다. 깊이 문제를 파고자 하는 성향이 없다면 테스터로 부적합하다.

능동적인가
악의적인 마음만 먹는다면 아무리 양질의 소프트웨어라도 수많은 버그를 찾아낼(?) 수 있으며, 문제가 많은 소프트웨어라도 버그를 찾지 못할 수 있을 것이다. 버그를 많이 찾았다고 테스트 업무를 열심히 한 것은 아니다. 또한 버그를 많이 찾지 못했다고 테스트를 소홀히 한 것 역시 아니다. 발견한 버그 개수는 소프트웨어 자체의 품질에 근간을 두고 있으며, 이러한 까닭에 테스터의 업무 성과를 단순히 버그 개수로 판단하기 어렵다. 이러한 테스트 업무의 특성을 고려할 때 능동적인 ^[3] 태도야말로 테스터에게 필요한 조건이다.

머리 회전이 빠른가
탐구적이고 능동적인 것만큼 필요한 것이 명석한 두뇌라 하겠다. 어리석고 능동적인 사람과 일해본 사람이라면 모두 이 요건에 공감할 것이다.

기능 또는 비즈니스 지식이 있는가
지금 여러분이 테스트하는 소프트웨어가 누구에게 무엇을 위해 쓰이는 소프트웨어인지 인지하고 있는가? 얼리어답터를 대상으로 그들의 입소문을 이용해 시장에 진입하려는 솔루션이라면, 지금 그 아키텍처의 옳고 그름을 논할 것이 아니라 그들이 관심을 가지고 있는 바로 그 새로운 기능에 대해 테스트해야 한다. 그러려면 해당 소프트웨어의 비즈니스 목표를 꼭 알 필요가 있다.

섬세한가
테스트 업무는 잘 짜여진 틀 안에서 허점을 찾는 일이다. 감각이 둔한 사람은 스쳐 지나가는 허점을 잡아내기 어렵다. 정말 둔한 사람이라면 눈 앞에 보이는 버그도 찾지 못할 것이다(필자는 가끔 편집증이 좋은 테스터의 필요 조건이 아닌가 하는 생각을 한다!?).

사고가 논리적인가
소프트웨어의 버그는 그냥 발생하지 않는다. 반드시 그 발생 원인이 있으며, 많은 클래스와 복잡하게 얽힌 함수의 연관관계를 통해 문제가 생기는 것이다. 이러한 문제의 원인을 찾으려면 훌륭한 논리적 ^[4] 사고가 필요하다.

마인드가 열려 있는가
테스터의 쓴 비판의 수용을 위해 개발자도 마인드가 열려야 한다. 개발자의 논리적이고 타당한 변명(?)을 수용하기 위해 테스터도 마인드가 열려 있어야 한다.

스트레스를 잘 다스리는가
개발팀과 잦은 마찰, 반복적인 회귀 테스트, 출시를 앞둔 상황에서 빠듯한 일정, 이 모든 것이 테스터에게 스트레스다. 테스터는 스트레스를 잘 다스려야 한다!

프로그래머가 되기를 원하지 않지만 기술적인 지식을 가졌는가
모든 전산을 공부한 엔지니어가 프로그래머가 되길 원하는 것은 아니다. 일부는 시스템 운영, 일부는 기획 일을 한다. 테스팅도 그들이 선택할 수 있는 좋은 역할이다. 테스터에게 있어 뛰어난 기술력은 두말할 필요 없이 중요한 조건이다.

테스트 대상 소프트웨어를 아는가
테스트해야 할 대상 소프트웨어를 안다면 더할 나위 없이 좋은 테스터가 될 수 있다. 평소에 그 소프트웨어를 사용했다면 더욱 좋다. 소프트웨어의 문제점을 이미 알고 있을 수도 있으며, 테스트를 위해 소프트웨어를 공부하고 분석하는 비용도 줄일 수 있다. 그래서 좋은 테스터의 후보로 사용자를 꼽기도 한다.

테스트 경험이 있는가
어쩌면 개발 경력이 오래된 개발자보다 이제 막 엔지니어로 첫발을 내딛은 초보 엔지니어가 좋은 테스터가 될 가능성이 높다. 그들은 학교에서 오래된 개발자들이 듣지 못한 '테스트'에 대한 이론을 들었을 가능성이 높기 때문이다. 실제로 강원대학 등 몇몇 대학에서 전산학과 정규 교육과정으로 소프트웨어 테스트를 가르치기 시작했다. 하지만 명심할 것은 가능성이라는 것이다. 가장 좋은 요건은 실제 그런 테스트를 해본 적이 있는가 하는 것이다. 테스트 경험이 있는 사람이야말로 가장 좋은 테스터다.

상식적인가
비상식적인 테스터의 비상식적인 논리로 인한 비상식적인 오류. 이 소프트웨어를 사용할 사람들이 상식적이라고 가정하자! 또한 비상식적인 논리로는 누구와도 의사 소통할 수 없다.

팀 플레이에 익숙한가
테스트는 혼자서 하는 일이 아니다. 여럿이 함께 모여 팀을 이뤄 일을 한다. 설령 혼자 테스트를 수행하더라도, 소프트웨어를 개발한 개발자와 한 팀이나 다름없다. 팀 플레이에 익숙하다는 것은 의사 소통 실력이 좋고 배려심이 깊다는 것이다. 테스트는 어떤 상황에서도 혼자 할 수 있는 일이 아니므로 팀 플레이에 익숙한 사람이어야 한다.

인간성이 좋은가
좋은 인간성이야 무슨 일을 하든 필요하겠지만 테스터 역시 좋은 인간성이 필요 조건이다. 앞서 언급한 팀 플레이의 기술적 요건만큼 좋은 인간성도 사람과 사람의 소통을 위한 중요한 조건이라 하겠다.

정략적으로 기민한가
부정적인(negative) 일을 하는 테스트 업무의 특성상 필연적으로 의견 충돌을 겪을 수밖에 없다. 또한 신제품의 경우 출시 시점에 제품 품질에 대해 갑론을박이 있을 수 있다. 테스터는 현 시점의 품질로 출시가 가능한지 여부 또한 논의해야 한다. 이러한 논의에 정략적 ^[5]인 기민함 ^[6]이 필요하다. 우직한 성품으로 회사의 사활이 걸린 제품 출시를 품질이 완벽하지 않다는 이유로 무조건 막을 수는 없는 것이 아닌가.

위로

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

사고가 유연한가
테스트란 업무는 틀에 박힌 정형적인 업무가 아니다. 사용자가 소프트웨어에서 제공하는 많은 기능을 어떤 조합과 절차로 사용할지 예상하기란 어렵다. 또한 일반적으로 논리의 흐름을 가진 프로그램 코드는 만들어진 논리의 흐름에 따라 동작하는 경우에 문제를 일으킬 확률이 적다. 버그는 그러한 흐름이 깨질 때 발생하는 경우가 많다. 이러한 소프트웨어의 특성상 유연한 사고는 필수다. 테스트의 한 기법으로 Ad-Hoc 방식이 있을 정도로 말이다.

소프트웨어 개발 라이프사이클을 아는가
필자가 언제나 강력하게 주장하는 바가 있다. 개발자와 테스터는 좋은 제품을 만들기 위해 노력하는, 한배를 탄 운명 공동체라는 것이다. 테스터도 좋은 소프트웨어를 개발하고자 하는 절차에 참여하는 사람이다. 당연히 개발의 라이프사이클을 알고 있어야 한다.

아직도 숨쉬고 있는가
지금까지 좋은 테스터의 요건에 대해 살펴 보았다. 일면 공감을 하는 독자도, 일반론이라 평하는 독자도 있겠다. 하지만 테스터라는 역할에 적임자를 뽑을 때 엔지니어라는 관점에서 지나치게 기능적인 부분만을 강조해서야 되겠는가? 엔지니어 역시 사람인데 말이다. 어쩌면 이런 같은 조건이야말로 테스터가 갖추어야 할 필수 조건이라 할 수 있지 않을까? 가령 야근을 즐기는지? 또는 아직도 숨을 쉬고 있는지?

위로

주

^[1] Craig&Jaskiel, Systematic Software Testing, Artech House Publishers.

^[2] 탐구심(探究心) : [명사]진리, 학문 따위를 깊이 파고들어 연구하려는 마음.

^[3] 능동적(能動的) : [관형사][명사]다른 것에 이끌리지 아니하고 스스로 일으키거나 움직이는. 또는 그런 것.

^[4] 논리적[論理的) : [관형사][명사]사고나 추리에 능란한. 또는 그런 것.

^[5] 정략적[政略的) : [관형사][명사]정치상의 책략을 목적으로 하는. 또는 그런 것.

^[6] 기민[機敏]하다 : [형용사]눈치가 빠르고 동작이 날쌔다.

위로

[지난 developerWorks Column 보기]