서핑중 좋은글이 있어서..
------------------------------------------------------------------------------------------------
소프트웨어 엔지니어는 테스터의 역할 중에서 소프트웨어 개발자 역할을 수행한다. 이들은 소프트웨어 개발자들과 동일한 교육을 받고, 동일한 백그라운드 및 기술들을 보유하고 있다; 단 지 다른 것은 그러한 기술들을 사용하는 애플리케이션일 뿐이다.
즉, 개발자로서의 소프트웨어 엔지니어는 테스트 중인 애플리케이션을 만든다. 테스터로서의 소프트웨어 엔지니어는 애플리케이션의 기능성을 검증하기 위한 시스템을 개발하고 이를 무력화하려고 시도해 본다.[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). 때때로 당신은 변화를 준비하거나, 혹은 그들의 리더십 역할을 수행할 곳을 찾거나 혹은 발전을 위해 다른 기회를 찾고 있는 개발 조직의 엔지니어들을 만날지도 모른다. 상 대적으로 더 많은 경험을 가진 상급 소프트웨어 개발자일수록 테스트 부서의 훌륭한 리더가 될 수 있다. 이것은 엔지니어들의 성장과 함께 잠재적인 리더십의 성장을 이끌어 낸다는 두 가지 장점을 제공한다.
-----------------------------------------------------------------------------------------
전문은 원본출처에서 : http://angel927.tistory.com/75
댓글 없음:
댓글 쓰기