훌륭한 테스트 팀을 만들고 유지하기(Hire and KEEP A Great Test Team)

By Jeff Feldstein[1]

 

지금까지는 애플리케이션과 개발자가 모든 관심을 받아왔다. 그러나 오늘날 방대하고 미션 크리티컬한 소프트웨어 애플리케이션을 테스팅 하는 것은, 애플리케이션을 개발하는 것만큼이나 복잡하다. 사용자들은 언제나 더 많은 것들을 원하고, 여기에 더해 새로운 기능, 좀 더 고상하고 신속한 성능, 증가된 사용자 편의성과 스케일을 요구하고 있다. 상급 관리부서는 이러한 모든 요구사항들이 비용은 절감하면서 충족되도록 요구하고 있고, 개발 리더들은 새로운 방법을 제안하는 반면 우리는 언제나 그렇듯 무척이나 바쁘다.

 

The Test Team

테스트 엔지니어, 테스트 매니저 그리고 품질 보증 파트로서 우리는 우리가 맡은 역할대로 다양한 요구의 균형을 잡기 위한 시도를 한다. 그러나 우리 회사는 한 걸음 더 나아가, 우리가 모든 분야를 동시에 개선해야 한다고 요구한다. 우리는 끊임없이 테스팅에 관한 우리의 접근법을 살펴보고 개선할 영역을 찾아야 한다: 어떤 경우에는 지나치게 개선되기도 한다. 강력하고, 다재 다능한 테스트 팀 없이는 이러한 것을 완수하리라고는 거의 기대할 수 없다. 여기서 의문이 발생한다: 어떻게 최고의 인재를 모으고, 채용하고, 고용을 유지해서 강력하고 다재 다능한 테스트 팀으로 성장시킬 것인가?

나는 소프트웨어 테스팅에 대해 우선 소프트웨어 개발의 문제로 접근해야 한다고 믿고 있다. 소프트웨어 엔지니어링의 원리와 테스트 엔지니어링의 원리가 같다는 것을 명심하라. 테스트 용이성(Testability)이나 품질을 향상시키는 제품의 기술이나 구조는 항상 소프트웨어 엔지니어링 원리에 의해 추적이 가능하다. 또한 제품에 적용된 모든 소프트웨어 엔지니어링의 원리들이 제품을 테스트 하는데 사용되는 자동화만큼이나 중요하다는 것을 기억하라. 소프트웨어 엔지니어링 기술은 테스팅의 효율을 정확하게 측정하는 것만큼이나 중요하다. 예를 들어, 경험 있는 소프트웨어 엔지니어만이 테스트 중인 제품의 코드 커버리지를 디자인하고, 개발하고 해석할 수 있다.

이것이 팀의 모든 구성원이 깊이 있는 소프트웨어 엔지니어링 지식을 가지고 있어야 한다는 것을 뜻하는 것은 아니지만, 만약 팀에서 적정한 비율의 구성원이 그러한 기술을 보유하고 있다면 당신의 위치는 더욱 공고해 질 것이다. 정확한 구성비는 당신의 프로젝트 요구(needs)와 현재 조직의 실체에 기반해 조정될 수 있다.

 

The Test Cycle

전형적인 소프트웨어 품질의 문제는 너무 늦게 찾아지는 버그, 작동하기 위해 사용되었던 기능이 동작하지 않는 것(리그레션 테스트에서), 너무 느린 퍼포먼스, 충분하지 못한 정량화(Scaling), 주위 환경으로부터 오는 압박에 대한 적절치 못한 반응, 그리고 장기간의 불안정한 상태 등을 포함한다.

어떻게 소프트웨어 엔지니어들이 테스터처럼 행동함으로써 이런 품질 이슈를 완화시킬 수 있는가?

 

버그는 너무 늦게 발견된다(Bugs found too late). 당신이 여기까지 읽었다면, 버그가 늦게 발견될수록, 수정에 더 많은 비용이 든다는 것을 알 것이다. 테스트의 전형적인 스타일(테스트 팀에게 기능이 전달될 때가지 기다리는 것)에서는, 버그의 대부분 혹은 전부가 개발 사이클의 마지막 부분에서 발견된다.

만약, 우리가 테스트 자동화 코드를 제품의 코드가 작성되는 동안 동시에 작성하면(혹은 그전에, 테스트 우선 개발(Test-first development) 접근법을 사용하면), 우리는 거의 대부분의 버그들이 코드 안에 내재되어 있다는 것을 발견할 수 있다. (그러므로 제품이) 테스트 하도록 건네질 필요가 없으며, 종종 복잡한 문제해결과 디버깅 세션을 피할 수도 있다. 이러한 종류의 자동화를 코딩 하는 것은 일반적으로 아주 높은 수준의 프로그래밍 기술을 요구하지만, 이는 버그가 더 빨리 찾아질 수 있도록 한다(혹은 완벽하게 피할 수 있도록 한다). 일반적으로 이는 서로 맞바꿀만할 가치가 있는 일이다.

리그레션(Regression). 테스트 케이스가 작성되고 디버깅된 후, 이는 필요할 때마다(더 나중의 빌드에서, 새로운 코드가 릴리즈 되거나 환경적인 호환성 검증을 위해) 언제라도 상대적으로 저렴한 비용으로 재사용되어야 한다. 테스트 케이스가 더 빨리 작성될수록 유용하다는 것이 더 많이 입증될 것이며, 더 쉽게 리그레션 테스트를 수정할 수 있도록 할 것이다. 리그레션 테스트는 수동으로 실행되고, 테스트 케이스가 수행될 때마다 매번 거의 동일한 비용이 소모되며, GUI를 통한 자동화는 종종 새로 작성하는 것보다 유지하는 것에 더 많은 비용이 들기도 한다(Regression tests run manually and cost almost as much to run each time they’re executed, and automation through the GUI often costs more to maintain than to rewrite).  

성능(Performance). 충분한 역량의 프로그래밍 언어를 구사해 제대로 만들어진 자동화는 타이밍 측정과 다른 리소스 사용 체크가 쉽게 수행될 수 있다. 이러한 체크는 실제 테스트 결과와 함께 기록될 수 있고, 시간이 지나도 추적이 가능하다. 스크립트를 사용해 수행되는 자동화는 테스트 중인 애플리케이션의 속도를 저하시키는 사이드 이펙트를 가지고 있으므로 타이밍 측정 결과가 부정확할 수도 있다. 측정되어야 하는 모든 것들이 측정으로 인해 변하게 된다는 것을 완벽하게 피할 수는 없지만, 원치 않는 사이드 이펙트는 측정을 수행하는 사람이 적절한 수준의 소프트웨어 스킬을 가진 경우 쉽게 발견되고 수정될 수 있다.  

범위(Scale)[2]. 수많은 훌륭한 상업적 그리고 오픈 소스 툴들이 스케일 테스팅을 도와주는 반면, 우리는 정확하게 우리의 특정한 환경을 복제하기 위해 종종 지금 사용하는 툴보다 더 많은 것이 요구된다는 것을 발견하게 된다. 어떤 경우에는 사용 가능한 툴들이 전혀 도움이 되지 않기도 하고, 우리 스스로가 스케일 환경을 개발할 필요도 있다. 어느 경우에나, 툴을 개발하고 다듬고 유지보수 하는 데에는 숙련된 소프트웨어 개발 엔지니어가 요구된다. 심지어 툴이 우리의 특정한 요구에 부합하는 경우라고 해도, 툴이 어떤 일을 수행하고 정상적으로 작동하고 있는지를 확인하기 위해 어떻게 수행되고 있는지, 그리고 어떤 것들이 테스트 되지 않는지에 대해 이해하고 있는 것이 중요하다.

스트레스 테스팅(Stress testing). 저자는 스트레스 테스팅을 입력 단계에서 시스템 작동을 검증하는 것으로 정의하고 있다:

a.     과도한 기대값, 혹은

b.     비정상적으로 높은 수준, 혹은

c.     시스템에 부적당한(hostile)인 값(예기치 않은 환경조건이나 유효하지 않은 파라미터).

이러한 스트레스에는 너무 많은 사용자의 로그인, 전력 손실 및 동시에 요청되는 과도한 주문 등이 포함될 수 있다. 이러한 테스트 케이스의 다수가 해당 분야의 전문가와 소프트웨어를 무력화하는데 자질이 있는 사람에 의해서 설계될 수 있지만, 툴을 디자인하고 이 테스트에 대한 효과를 측정하는 데에는 깊이 있는 소프트웨어 엔지니어링 지식이 요구될 수도 있다.

안정성 테스팅(Stability Testing). 이것은 출시된 제품이 수명 기간, 즉 보통 여러 달에서 2년에 걸치는 기간 동안 정확한 행동을 수행하리라는 것을 보장하는 것을 의미한다. 안정성 테스팅은 출시 이후에도 어느 정도 제어가 가능하고 상대적으로 쉽게 업그레이드가 가능한 웹 서버 혹은 웹 애플리케이션 보다는 독립적으로 출시되는 제품에 우선적으로 사용된다.

이 종류의 테스팅은 종종 며칠에서 몇 주일에 걸치는 제품 수명 기간을 시뮬레이션 하는 것이 요구된다; 즉, 라이프 사이클을 빨리 돌려 어떻게 시스템이 반복적으로 작동하는지 살피는 것이다. 현실에서 접할 수 있는 것보다 훨씬 빠른 속도를 재현하는 시간의 압축은 복잡한 문제이다. 더 강력한 프로그래밍 툴과 더 숙련된 엔지니어들이 있을수록, 당신은 이런 복잡한 문제에서 벗어날 더 나은 기회를 가지게 될 것이다.

 

Categories of Testers

이제 당신은 소프트웨어 엔지니어가 테스트 조직에 속해 있을 경우의 장점에 대해서 명확하게 확신을 가졌을 것이므로, 테스트 엔지니어에 대해서 조금 더 시간을 할애해 보자. 이 논의를 위해, 테스트 엔지니어는 크게 세 종류로 정의될 수 있다: 고전적인 테스터(Classic Testers), 스크립터(Scripters) 그리고 소프트웨어 엔지니어(Software Engineers)가 그것이다.

고전적인 테스터에는 내가 개발 파트를 떠나 처음 만났던 대부분의 테스트 그룹에 속해있던 애플리케이션 테스터들이 속한다. 이들 테스터들은 종종 애플리케이션 영역 출신이며, 해당 애플리케이션이 속한 도메인에 대해 강력한 백그라운드를 가지고 있었을 것이다. 그들은 테스트하는 분야의 파워 유저 혹은 전문가였을 수도 있고(기술적인 전문가, 소프트웨어 엔지니어 혹은 컴퓨터 과학자라기보다는), 또한 테스트하는 애플리케이션에 대해 깊이 있는 이해를 하고 있는 사람일 수도 있다. 이들 테스터들은 긍정적 테스트 케이스(Positive Test Case)나 부정적인 테스트 케이스(Negative Test Case)를 디자인하는데 매우 유용하며, 제품을 무력화시키는 방식을 설계하는데 있어 매우 창조적일 수도 있다.

스크립터는 종종 고전적인 테스터로 시작하지만 직업으로 인해 스크립트에 관한 지식을 습득하게 되는 경우다. 그들은 펄이나 쉘(Shell) 스크립트 일부를 익혔을 수도 있고, 상용 테스트 툴을 사용하면서 스크립트를 배웠을 수도 있다. 아마도 그들은 GUI 레코드 앤 플레이백(Record-and-playback) 기술에도 다소간의 시간을 소모했을 것이다. 저자는 여기서 스크립트 언어와 프로그래밍 언어를 구별하고자 한다. 프로그래밍 언어(자바 혹은 C와 같은)는 순차적인 실행 단계를 가지고 있을 뿐만 아니라, 복잡한 로직과 순환 구조(Looping Structure), 진보한 데이터 구조를 생성하고 다루는 능력도 가지고 있다(“프로그래밍에서의 스크립트(The Script on Programming)” 사이드바 참조).      

소프트웨어 엔지니어는 테스터의 역할 중에서 소프트웨어 개발자 역할을 수행한다. 이들은 소프트웨어 개발자들과 동일한 교육을 받고, 동일한 백그라운드 및 기술들을 보유하고 있다; 단지 다른 것은 그러한 기술들을 사용하는 애플리케이션일 뿐이다.

즉, 개발자로서의 소프트웨어 엔지니어는 테스트 중인 애플리케이션을 만든다. 테스터로서의 소프트웨어 엔지니어는 애플리케이션의 기능성을 검증하기 위한 시스템을 개발하고 이를 무력화하려고 시도해 본다.[3]

이러한 기술들은 테스트 엔지니어에게 제품이 테스트 용이성에 적합하게 디자인되었는지, 그리고 적합하게 유닛 테스트를 수행했는지 확인하기 위해 개발 담당 팀과 같이 일할 수 있도록 해준다. 테스트 엔지니어가 비록 개발자와 유사한 일련의 스킬과 단어를 사용한다고 하더라도, 테스트 엔지니어는 (개발 담당 엔지니어에 비해) 제품을 더 잘 평가하고 제품의 테스트 용이성이 개선될 수 있는 부분을 더 잘 지적할 수 있다. 이러한 테스터는 단지 사용자가 키보드 앞에 앉아있는 것을 흉내 내는 것[4]과는 다른 수준의 테스트 자동화를 디자인하고 만들어 낼 수 있다. 그 대신 그는 훌륭하게 설계되고 테스트 중인 시스템만큼이나 정교한 자동화 프로그램을 만들어 낼 수 있을 것이다. 덧붙여, 소프트웨어 엔지니어는 고객이나 실제 환경을 더 밀접하게 시뮬레이션 하거나 모델링 하기 위해 적절한 소양을 갖추어야 하며, 이러한 소프트웨어 엔지니어가 작성하는 자동화 프로그램은 스스로 에러를 복구할 수 있어야 한다.

 

Recruiting Software Engineers

어떻게 팀을 꾸릴 것인가? 대부분의 개발자들은 단지 개발만을 하고 어떤 대가를 치르더라도 테스트를 피하고 싶어하는 것이 현실이다. 아마도 테스트 조직에서 소프트웨어 엔지니어를 채용하는 데 있어 가장 큰 장애물은 테스트 엔지니어링에 대한 인식일 것이다. 테스트 컨퍼런스에 참가하는 도중, 나는 많은 테스트 엔지니어와 그들의 매니저로부터 개발자들이 그들에 대해 어떻게 말하는지를 들려달라는 요청을 받았다. 그 말들 중 가장 날카로운 것들 몇 가지는 다음과 같다: “테스터들은 멍청이들이야”, “테스팅은 지루하고, 수동적이고 반복적이야”, “테스팅은 창조적이지 못하고 혁신할 기회가 부족해”, “테스팅은 전문직이 아니야”, “테스트 엔지니어들은 프로세스가 품질에 공헌하던, 그렇지 않던지 간에 맹목적으로 프로세스를 따라가려고 해” 등등이다. 그리고 물론, 내가 개발을 할 때 가졌던 태도도 “테스트는 나의 훌륭한 창작 행위와 사용자 사이에 서있는 필요악이다” 였다.

이런 말들을 얼마나 많이 들었는가? 당신은 더 나쁜 경험도 가지고 있지 않은가? 우리가 뛰어난 성과를 발휘하는 테스트 팀을 만들기 위해 직면한 하나의 장애물이 바로 이러한 개념을 극복하는 것이다.

자, 이쯤에서, 아마 당신은 개발분야의 직업을 구하고 있는 후보자에게 소프트웨어 엔지니어가 테스팅 부서에서 어떤 일을 해야 하는지를 어떻게 설명해야 할지 궁금해 할 것이다. 이 한 마디로 당신은 설명을 시작할 수 있을 것이다:

“우리 테스트 팀의 소프트웨어 엔지니어는 시스템의 기능성을 검증하고, 성능을 보장하고 요구사항의 범위를 설정하며 신뢰성과 에러로부터 복구되는 것을 증명하기 위한 정교한 소프트웨어를 디자인한다.”

만약 그 후보자가 당신이 위의 문장을 다 말하기 전에 전화를 끊지 않았다면, 더 자세한 논의를 해보면 된다. 사실, 내가 모집하는 이 포지션은 개발직과 동일할 뿐만 아니라, 오히려 더 많은 것을 요구하는 것이다. 여기에 그 이유가 있다:

정교한 소프트웨어(Sophisticated software). 당신은 아주 기술적이고, 정교하고, 에러에서 복구가 가능한 소프트웨어를 디자인하고 개발할 것이다. 단지 소프트웨어의 목적이 다를 뿐이다. 작은 규모의 애플리케이션을 만드는 대신, 당신은 기능성, 확장성(Scalability), 신뢰성을 검증할 수 있는 완벽한 시스템을 개발해야 하는 것이다. 여기에 더해, 당신의 소프트웨어는 사실상 수동으로 구동되지 않으면서도 각 제품 빌드를 다시 만드는데 많은 시간을 소모하지 않는 방법과 기술을 사용하며, 아울러 이러한 테스트 환경에서 시험중인 시스템을 파괴하는 창조적인 방식도 포함하고 있어야 한다.

당신은 무엇을 만들지를 결정해야 한다(You decide what to build). 대부분의 “소프트웨어 개발자”들이 마케팅 부서나 혹은 제품관리 부서에서 만든 요구사항에 충족하는 시스템을 만들려고 한다. 새로운 기능과 특성은 제품에서 구현되기 이전에 제품 관리자의 마음을 제일 먼저 사로잡아야 한다(New features and capabilities must first be sold to the product managers before they can be put into a product). 마케팅 팀은 그들이 이미 마음 속에 가지고 있던 기능에 대해 개발자가 제안한 기능의 비용을 측정해 어떤 것을 탈락시킬지 결정할 필요가 있다. 테스팅에 있어서, 당신은 당신의 보스에게 어떻게 소프트웨어가 생산성을 향상시키고, 품질 확인을 도와주고, 더 많은 버그를 찾게 해주는지를 보여줌으로써, 보스가 당신에게 그 기능이나 시스템을 만들기 시작하라고 지시하도록 할 것이다. 마케팅 회의, 조사 그룹(Survey groups) 혹은 비용 분석은 없다.

소규모 팀(Small Teams). 테스트 팀은 그들의 파트너인 개발 파트보다 규모가 작기 때문에, 당신은 프로젝트에서 일부분이 아니라 무척이나 많은 부분(혹은 어쩌면 프로젝트 전체일수도)을 담당하고 있을 것이다. 여기에 더해, 당신은 당신의 측정 부분이 어떻게 구현되는지에 대한 깊이 있는 이해보다는 제품 전체의 더 많은 기능을 이해함으로써 “큰 그림(big picture)”에 대한 더 나은 인식을 가져야 한다.

창조성(Creativity). 개발자들은 전형적으로 관리자가 기술한 제품을 만들기 때문에, 그들의 창조성은 일반적으로 기능 구현에만 제한되기 마련이다. 즉, 어떻게 이러한 기능들을 최대한의 성능과 품질을 발휘하도록 구현하는 가만을 고민하게 된다. 이와는 반대로, 테스트 엔지니어는 어떤 기능의 구현 방법에서뿐만 아니라 그들이 만들어 내는 기능 자체에 대해서도 창조적이라고 할 수 있다.

창조성의 일반적인 두 가지 영역은 테스팅을 위해 어떤 툴을 사용할 것인가와, 얼마나 새롭고 창조적인 방식으로 테스팅을 수행할 것인가 이다. 여기에는 아마도 시스템에 스트레스를 주거나, 모델-베이스 테스팅을 수행하는 것과 같은 새로운 방식과, 애플리케이션의 품질을 자동적으로 측정하는 다양한 방법과 자동화 자체도 포함된다.

당신은 당신 동료의 코드를 파괴할 필요도 있다(You get to break your buddy’s code). 더 이상의 설명이 필요 없다(No explanation required).

혁신(Innovation). 테스트 자동화 – 특히 기술적으로 고도화된 자동화의 경우 – 는 순수한 소프트웨어 개발에 비해 더 새롭고, 덜 탐구된 영역인 경향이 있다. 이는 혁신할 여지를 더 많이 남겨두는 것이다. 이는 창조성과 겹치는 부분도 있지만, 여기에서 강조하고자 하는 것은 (테스트 자동화가) 여전히 개발되고 있는 단계이며 새로운 단계라는 것이다. 높은 품질의 소프트웨어를 개발하는 방법에 중점을 두는 산업에서는 새로운 테스팅 기법과 방법론이 끊임없이 개발되고, 전파되고 정제된다. 팀에 이러한 혁신을 도입하고 이를 특정한 제품에 적용하는 것은 제품의 품질과 팀의 생산성을 증대시키면서도 한편으로는 (이를 도입한) 엔지니어에 대한 보상이 될 수도 있다.

고객 상호작용/비즈니스 지식(Customer interaction / Business Knowledge). 가장 효과적인 테스트 엔지니어 – 그들이 고전적이거나 스크립터이거나, 혹은 소프트웨어 엔지니어라고 할지라도 – 는 제품에 대한 총체적인 이해를 하는 것이 필요하다. 이러한 총체적인 이해는 (개발자보다는) 테스터에게 있어 좀 더 보편적인데, 그 이유는 테스터들이 특정한 기능의 구현에 덜 관련되어 있고 소프트웨어 검사에 좀 더 연관이 되어 있기 때문이다. 우리는 종종 우리의 테스트 팀을 제품의 한 영역에서부터 새로운 기능이 구현되었거나, 혹은 현존하는 기능이 강화되거나, 버그가 수정된 또 다른 영역으로 전환하기도 한다. 여기에 더해, 고객이 찾아내는 버그들은 우리에게 어디에 문제가 있는지에 대한 단서를 제공해 주는 것이므로, 우리는 고객들이 어떻게 제품을 사용하는지를 스스로 분석해야 하고 그러한 정보들이 다음 릴리즈를 위해 어떻게 사용되는지를 분석해야 한다. 테스트 엔지니어들은 종종 외부 테스트가 시행되는 동안 고객과의 상호작용을 하는 데에도 무척 적합한데, 이는 고객들이 아마도 제품에 대해 전반적인 이해를 가진 사람의 도움이 필요하기 때문일 것이다. 많은 엔지니어들이 고객과의 상호작용과 종종 이를 동반한 사업적인 여행을 즐긴다. 만약 이 경우가 당신에게도 해당이 된다면, 이것은 매우 적합한 구인(Recruiting) 포인트가 된다.

모든 엔지니어가 영원히 엔지니어로 남는 것을 바라지 않는다는 것을 명심하는 것도 도움이 된다. 나는 많은 개발자 및 테스터들이 마침내는 더 중요한 사업적인 역할을 수행하는 자리로 이동하는 것을 수없이 보아왔다. 대다수의 경우, 테스터 직으로부터 이러한 변환이 더 쉽다: 제품에 대한 훌륭한 이해, 비즈니스 이슈를 해결하는 능력 및 고객과의 상호작용과 같은 경험 등이 이러한 변환을 도와줄 것이다.

 

실망한 사람들을 채용하기(Recruiting Disappointments)

만약 당신이 여기에서 주어진 모든 가이드 라인을 따르고 당신 스스로 겪었던 다른(혹은 더 나은)문제를 제시한다고 하더라도, 당신이 대화를 나누는 모든 후보자들을 이길 수는 없다. 어쩌면 대부분을 이기지 못할지도 모른다. 그렇다고 실망하지는 마라. 우리가 개발자에게 테스팅을 고려하게 하는 것은 언덕 아래에서 위로 올라가는 힘겨운 싸움을 하고 있는 것과 마찬가지이다. 훌륭한 엔지니어가 한 번 테스팅에 관한 가능성을 생각하기 시작하면, 그것이 점점 커져간다는 것을 기억하라. 나는 여러 가지 이유에서 테스팅을 시작하고 결국엔 그것을 즐기게 되는 많은 엔지니어들과 이야기를 나누어봤다. 그리고 또한 개발부서만이 모든 훌륭한 엔지니어들을 끌어들이는 것은 아니라는 것도 명심하라. 개발 엔지니어 후보들은 그들이 인터뷰하는 팀이 너무 크거나, 너무 작거나, 너무 젊거나(junior) 너무 나이 들었다고(senior) 생각할 수도 있다: 혹은 프로젝트나, 개발 부서나 회사가 자신들의 목적에 맞지 않는다고 생각할 수도 있다. 테스팅에 종사하는 우리들처럼, 개발부서의 관리자들도 인원 채용에 있어 어느 정도의 영업 정신이 필요한 것이다.

 

대안적인 접근방법(Alternative Approaches)

후보자를 끌어들이는 상호 보완적인 접근법이 있다: 인턴, 내부적인 후보자와 “먼저 테스트를 하게 하고 나중에 개발하도록 하는” 전략이 있다.

인턴(Interns). 내 경험상 고용된 인턴(졸업이 가까워진 소프트웨어 엔지니어링을 공부하는 학생들)들은 지극히 효과적인 고용 기술이다. 인턴들은 학기 중의(전문대학이나 대학교가 당신의 직장 가까이에 있다고 가정할 경우) 여름이나 일부 기간 동안 풀 타임으로 근무하며, 확장된 두 가지 방식[5]의 인터뷰를 통해 프로젝트에 종사하는 두 가지 역할을 모두 고려해 볼 수 있다.

대부분의 경우, 인턴들은 종종 그들이 첫 “실질적인” 직업을 가졌다는 기쁨 때문에 열심히 일하곤 한다. 그들은 경험 있는 프로그래머나 이제 갓 학교를 졸업해 소프트웨어 개발자로서의 역할 모델을 가지지 못한 신입 사원들보다 덜 걱정하는 편이다. 내가 기억하는 가장 행복했던 날은, 가스 주유소를 그만두고 그 다음날부터 진짜 사무실에서 이전보다 두 배의 임금을 받으며 프로그래머 인턴으로서 일을 시작한 날이다. 비록 아직 대학에 몸을 담은 상태고, 실질적으로 새로운 위치에서 행한 일들이 그렇게 중요하지는 않았지만, 결국엔 내가 고되게 행한 일들이 회사에 이익을 가져다 줄 것이라고 믿었었다. 나는 요즘의 인턴들이 나와 그렇게 틀리리라고는 생각하지 않는다.

이렇듯 인턴을 통해 양성되고 있는 엔지니어들은 조직에 신선하고, 새롭고, 틀에 박히지 않은 아이디어를 가져다 줄 수 있다. 그들이 한 번 당신의 테스트 그룹에서 몇 달 혹은 일 년씩 근무하고 나면 그들은 테스트의 장점을 절대적으로 이해하게 되고 졸업 이후에는 풀 타임 근무자로 전환이 가능할 것이다.

내부적인 지원자(Internal Candidates). 때때로 당신은 변화를 준비하거나, 혹은 그들의 리더십 역할을 수행할 곳을 찾거나 혹은 발전을 위해 다른 기회를 찾고 있는 개발 조직의 엔지니어들을 만날지도 모른다. 상대적으로 더 많은 경험을 가진 상급 소프트웨어 개발자일수록 테스트 부서의 훌륭한 리더가 될 수 있다. 이것은 엔지니어들의 성장과 함께 잠재적인 리더십의 성장을 이끌어 낸다는 두 가지 장점을 제공한다.

테스트가 먼저, 개발은 나중에(Test first, then develop). 테스트 업무에 종사하는 많은 회사들(그리고 내 동료들 일부도)은 “18 ~ 24개월 동안 테스터로 우리 회사에 입사하세요. 그러면 이후에 개발 부서로 옮겨 드립니다”라는 구인 기법을 찾아냈다. 나도 그런 경우였다. 나는 종종 기대했던 것보다 소수의 엔지니어들만이 개발 부서로의 이동을 희망하고, 그들이 확고한 상급 테스트 엔지니어나 리더로 성장하는 것을 보아왔다.

 

다른 자원들(Other Resources)

인재 채용에 있어 다른 자원으로는 당신이 채용한 갓 학교를 졸업한 학생(아마도 이전에는 인턴이었을)을 활용하는 것이다. 당신의 팀에서 몇 개월 혹은 1~2년 동안 일한 경험이 있으며 조리 있고, 그의 일을 정말 즐기고, 그가 일하는 방면에 열정적인, 최근의 졸업생을 찾아보라. 이러한 엔지니어들을 채용 절차에 투입시켜보라 – 그들을 만나보고 그들의 연령대와 비슷한 후보자들과 면담하게 하라 – 이는 아마 당신의 채용에 상당한 도움을 줄 것이다. 후보자들은 “테스팅이 더 낫다”라는 메시지를 이러한 방법을 통해 채용된 누군가로부터 들을 때 더 명확하게 이해할 수 있을 것이며 테스트 분야에서 일하는 이득을 누릴 수 있을 것이다.

경우에 따라, 테스트 부서에서 개발 부서와의 마찰을 경험할 수도 있을 것이다. 내 경험상 이런 일은 드물었지만, 그렇다고 해서 겪을 필요가 없는 나쁜 일만은 아니다. 당신의 테스트 엔지니어 중 약 10 ~ 20% 가량이 몇 년이 지나 개발 부서로 가게 될 경우, 이들이 테스트 가능한 아키텍쳐나 품질에 가장 깊게 관련하는 엔지니어가 될 수 있기 때문에, 이런 경우에는 개발 부서와의 마찰이 당신에게 이로울 수도 있다. 그들은 양쪽의 시각에서 프로세스를 관찰한 경험이 있기 때문에 테스트 부서에 우호적인 상태로 남아있으며 이로 인해 그들은 개발과 테스트 부서 사이의 효과적인 중재자 역할을 수행할 수 있다. 여기에 더해, 그들은 개발 부서 내에서도 새로운 테스트 툴이나 기술을 받아들이는 얼리 어댑터로 기대되기도 한다.

 

Keep ‘Em on the Farm

이제 당신이 당신의 팀을 구성하고 그들이 열심히 일하고 있다면, 당신은 당신의 팀에서 최고의 재능을 유지하는데 초점을 맞출 필요가 있다. 당신의 테스트 조직이 완성되면, 테스팅 업무를 즐기고 그 일에 만족하는 리더를 선정하는 것이 무척이나 중요하다. 그들이 후배 엔지니어들에게   보여주는 선례들은 주목할 만한 것들일 것이다. 당신의 엔지니어들이 계속 테스트 업무에 흥미를 느끼고 도전하게 만드는 것도 중요하다. 당신의 사업이나 문제가 발생한 영역, 소프트웨어 엔지니어링 스킬, 일반적인 비즈니스 스킬 그리고 매니지먼트나 리더십에 관해 훈련 받을 시간을 보장하라.

다른 중요한 유지 기술 역시 품질 관점에서는 도움이 된다: 제품의 라이프 사이클 초기에 테스트 엔지니어들을 포함시켜 일하도록 하는 것이다. 초기 의사결정 단계에 테스트 엔지니어들을 포함시키는 것이 결코 빠른 것이 아니다. 그들은 마케팅 부서나 아키텍쳐 팀에 중요한 통찰력을 제공할 뿐만 아니라, 그들 스스로 그런 경험을 즐길 것이다.

테스트 리더나 관리자로서의 당신 직무의 일부는 개발 부서의 당신 동료들에 대해서도 정통해야 한다는 것이다. 만약 그들이 새로운 기술이나 아키텍쳐에 관해 연구하거나 교육을 할 때, 테스트 부서에서 당신이 꼭 참석해야 한다. 이는 개발 부서와 테스트 부서와의 밀접한 관계 형성을 도와줄 뿐만 아니라, 당신의 테스트 엔지니어들에게 흥미로운 식견을 제공해 줄 것이다.

 

조직 지원(Organization Support)

일반적으로 테스트 매니저는 더 큰 조직의 일부이므로 조직으로부터의 지원 없이는 그만의 드림 팀을 꾸릴 수 없다. 테스팅이 개발만큼이나 중요하다는 것과 개발자와 동일한 종류의 스킬을 가진 엔지니어가 필요하다는 것을 이해한다면, 조직에서 (테스트) 엔지니어들을 동료로 다루는 것이 무척이나 중요하다.

이것은 동등한 급여 수준과 유사한 진급의 기회를 제공하는 병렬적인 캐리어 트랙을 포함한다. 문화적으로 테스트 엔지니어링 조직이 문서를 리뷰 하거나, 프로젝트를 결정하거나 다른 팀과의 논의에서 다른 조직과 동등하게 대화할 수 있는 것이 중요하다. 추가적으로, 테스트가 개발을 위한 서비스 조직으로 다루어져서는 안되며, 다양한 관점의 데이터를 기반으로 의사 결정을 내리는 상급 관리자에게 독립적인 목소리를 낼 수 있어야 한다.

이미 많은 소프트웨어 회사들이 이러한 종류의 구조를 가지고 있음에도 불구하고, 또 그만큼 많은 회사들이 그러지 못하고 있는 것도 사실이다. 만약 당신의 조직이 후자에 속한다면, 밤을 새서 변화시키려고는 하지 마라. 대신 끈기를 가지고, 확고한 결과의 데모와 측정 가능한 개선, 이와 같은 것들을 시간이 지날수록 달성해야 한다.

비록 많은 환경 하에서, 테스팅은 개발 팀의 다른 멤버들을 보조하는 역할로 보이기는 하지만, 테스트 엔지니어링은 소프트웨어 개발 과정에 있어서 중요한 컴포넌트이다. 강력한 테스트 부서는 충분한 소프트웨어 엔지니어를 포함한다. 적당한 리더십이 있다면, 개발부서의 동료들과 고객, 그리고 상급 관리자들로부터 존경 받고 가치를 인정받으며 제품 개발과 품질에 지대한 공헌을 하는 테스터 역할에 소프트웨어 엔지니어를 채용하고, 유지하고 성장시키는 것이 가능할 것이다.

---

[1] 저자인 Jeff Feldstein 은 Cisco Systems에서 40명의 테스터로 이루어진 팀을 이끌고 있다.

[2] 역자 주: 주로 Tom Gilb의 Article에서 ‘Scale’은 ‘측정’ 혹은 ‘정량화’의 의미로 사용되고 있다. 여기서는 ‘Scale’을 범위 기반 테스팅, 혹은 범위 테스팅에 사용되는 ‘Scale’로 보는 것이 타당할 듯 하다.  

[3] 역자 주: “~tries to break it”은 극단적인 Negative Test를 수행해 높은 Severity의 Failure를 유도해 본다는 뜻으로 사료됨

[4] 역자 주: Capture and Play Tool을 지칭하는 듯 함

[5] 역자 주: 개발자로서의 역할과 테스터로서의 역할을 의미하는 듯함