[ALM-Test] 3. 테스터에 대한 오해와 진실

테스터 역할 배경에 대한 오해

이전 단원에서 "왜 단위 테스트를 해야 하는가" 에 대해 이야기를 해 보았습니다.

[ALM-Test] 왜 단위 테스트를 해야 하는가? [1]
[ALM-Test] 왜 단위 테스트를 해야 하는가? [2]

그리고 테스터의 역할 정의를 아래와 같이 하였습니다.

• 업무 도메인의 이해
• 테스트 도구 사용
• 전반적인 테스트 시스템 인프라 와 운영체제(OS) 의 이해

하지만 필자도 테스트에 대한 공부를 시작하면서 몇 가지 오해를 하였던 것이 사실이었습니다. 필자는 대부분 SI, 컨설팅, 솔루션 개발을 하였고, 개발자 대신에 테스트를 해 주는 역할이 테스트라는 엄청난 함정에 빠졌던 것입니다. 자칫 함정에 빠진 이유는 SI 개발과 SM 이라는 유지 보수 업무의 장기 선상으로만 빗댄 것이었죠. 더불어 테스터의 역할은 업무에 따라서 충분히 달라질 수 있다는 것을 알게 되었습니다.

아마 대부분의 IT 개발직에 몸 담으신 분들이라면 저와의 생각과 크게 다르지 않을 것이라고 생각합니다. 일반적으로 작은 조직에서는 테스터(Tester) 직무만 보유하지만, 특히 대기업, 솔루션 업체나 게임 업계에서는 QA(Quality Assurance-품질 보증) 팀을 자체적으로 보유하는 것으로 알고 있습니다.

QA(Quality Assurance) 팀은 주로 소프트웨어의 버그/결함을 발견하고 개선하기 위한 업무가 수행됩니다. 그렇다면 이 QA 팀의 테스터는 기술자인가? 아니면 그냥 그저 그런 테스터인가? 기술자라면 어느 정도의 기술 요구사항이 필요한지, 그냥 테스터라면 어떤 단순 업무가 수행되는지, 궁금하지 않으십니까?

   

소프트웨어 1위 업계는 어떻게 구성이 되었는가?

단연, 소프트웨어 1위 업계는 Microsoft 입니다. Microsoft 는 초기 솔루션(제품) 이 개발되기 시작하면서(당시 1979년 인턴부터 시작하여) 테스터를 모집하여 참여했다고 합니다. 초기에는 STE(Software Test Engineer) 와 SDE/T(Software Development Engineer in Test) 라는 두 개의 직함이 있었는데, STE와 SDE/T 의 직무는 사실상 약간의 차이를 보였습니다.

STE 의 직무는 테스트 플래닝(Test Planning), 핵심 테스트, 테스트 자동화와 같은 테스트를 리드하는 직무였고, SDE/T 는 테스트 코드 작성, 코드 리뷰, 테스팅 툴 개발 등 실제로 일선에서 테스팅을 수행하는 직무였습니다. 2002년도 부터 SDE/T 직함을 없애려고 하였고, 2005년도에 SDE/T 가 SDET 로 명명되었습니다. 실제로 당시 시대적 배경으로 암시해보면 STE 의 비중보다 SDET 의 비중과 직원 증가율이 높았습니다. 왜냐하면 STE 는 주로 자동화 테스팅과 관련된 직무를 수행했는데, 사실상 시대적인 기술 한계 등으로 많은 활성화가 되지 않았던 것 같습니다.

결국 SDET 로 테스트 관련 직군이 모두 통합이 되었지만, SDET 도 각 직급이 존재하였습니다.

• SDET1 : 테스트 케이스를 구현
• SDET2 : SDET1 과 큰 변화는 없지만, 영향력이 고객과 직접적으로 의견을 교환할 수 있습니다.
• Senior Software Development in Test : 테스트와 관련된 아키텍처가 가능하고, 문제를 해결할 수 있는 능력
• Principal Senior Software Development Engineer in Test : 조직을 관리하고 테스트 방법론, 테스트 기술 혁신을 제시
• Partner Software Development Engineer in Test : 조직 및 제품 전반을 이해하고 기술 혁신을 선도

특히, 현재 Microsoft 의 SDET 의 인원은 9,000명 넘는 인원이 직무를 수행 중이며, Microsoft Office 2007 제품에는 3,000 여명의 SDET 가 투입되었다고 합니다. 아래는 2008년도 대비 전세계 80,000여명이 넘는 직원 중의 각 분야별로 인원입니다. 특히 '제품 개발 및 지원' 은 SDE/SDET/Op(Operations)/IPE(International Project Engineering-현지화) 등등 을 모두 합한 것으로 9,000명의 SDET 라는 것은 거의 SDE 보다 SDET 가 더 많다고 합니다.

Op(Operations) IT 분야를 관리하고, 네트워크, 서버를 관리 및 유지보수 하는 분야입니다. 즉 Microsoft 의 인프라를 주로 담당하며, 효과적으로 비용을 절감하거나 품질 좋은 서비스를 제공하기 위한 분야입니다. IPE(International Project Engineer) Microsoft 제품은 대부분 다국어 제품으로 출시하는데 각 나라의 특성에 맞게 변형하는 역할 (참고 : 국제화(i18n, internationalization): (1) 그거 번역하는거 아냐?)

   

SDET 의 자격 요건!!

SDET 는 적어도 소프트웨어 업계 1인자인 Microsoft 에서는 매우 중요한 직무임이 틀림이 없습니다. 그것이 우리나라에서는 SDET 의 역할이 그리 중요하지 않거나, 빅3 SI 업계에서는 공학적인 측면만을 강조하고 있다는 느낌이 드는 것도 사실입니다. (적어도 .NET 분야에서는 말이죠^^;)  

SDET 는 소프트웨어나 제품이 출시하기 위해 매우 막중한 임무를 수행하는 직무입니다. 한 명의 SDET 가 최선을 다하지 못한다면 버그/결함이 고스란히 고객에게 영향을 미치게 될 것이 분명합니다. SDET 는 소위 우리나라의 '베타 테스터'와 같이 먼저 사용해보고 평가나 버그를 제작사에게 알려주는 것이 아닌, 버그/결함을 제거하는 사명을 띠는 매우 크리티컬한 분야입니다.

버그와 결함에 대해서는 다음 회차에 명확히 할 예정입니다.

그렇다면, SDET 는 어떤 자격 요건을 갖추어야 할까요?

1. C# 과 같은 객체지향적 언어 또는 필요한 언어적인 기술을 완벽히 갖추어야 한다.
2. 특정 버그/결함을 디버깅하거나 리팩토링/개선이 가능해야 한다.
3. 제품에 대한 기술적인 배경 지식을 갖추어야 한다.
4. 제품이나 도메인에 대한 전체적인 프로세스/아키텍처를 이해할 수 있어야 한다.
5. 테스트 케이스를 계획하고 테스트 공학적인 지식을 갖추어야 한다.
6. 다양한 방법/기법으로 테스트 케이스를 작성할 수 있어야 한다.
7. 테스트 케이스를 작성하거나 테스트 자동화에 대한 지식이 있어야 한다.
8. 개발, 기획, 운영 팀 등과 커뮤니케이션을 원활하게 할 수 있어야 한다.

만약, 이 중에서 5개 이상 스스로 가능하다고 판단되지 않는다면, 필자와 함께 "[ALM-Test]" 연재를 꾸준히 구독하길 바랍니다. 그리고 5개 이상 수행이 불가능하다면 이미 SDET 가 아닌, "베타 테스터"라고 자칭하셔야 합니다.

필자 또한 테스팅 분야에 관심이 많았지만, 본격적으로 막 뛰어는 풋내기나 다름이 없기 때문에, 꾸준히 저와 함께 정보를 공유하거나 경험이 많은 분들의 가르침이 필요하다고 생각을 합니다.^^

   

왜 테스팅 분야에 뛰어 들었나요?

저는 약 1.5년 전부터 애자일(Agile) 방법론과 프로세스에 매우 관심을 갖게 되었습니다. 그리고 결국 깨닫게 된 것은 애자일을 경험하면서 우리나리 현실과 부합되지 않는다는 것을 몸소 느꼈습니다. 물론 제가 잘못된 애자일을 수행했을 가능성도 없지 않겠지요. 애자일은 점진적이고 반복적인 프로세스로 단지 프로세스 뿐만 아니라 사람 그리고 인격을 강조한 기만한 방법론이지만, 사실상 우리나라에서는 조직의 작은 팀 내부에서만 불화음 없이 수행 가능하던 그저 그런 것이었습니다. (참고:애자일에 대한 고찰)

어떠한 고객도 관심 없는 XP(eXtreme Programming), Scrum 를 수행하면서 자기 만족 수준에 불과했으니까요. 하지만, 일부 애자일 프로세스가 권장하는 방법을 버리고, 개선/조합하니 왠걸??? ^^

어떤 미친 기업에서 SDE:SDET=1:1 비율로 배치가 가능하며, 아무리 좋은 사례를 가져와도 실패하고 맙니다. 뿌와쨔쨔님의 영어이야기 중 "한국 미국, 자기소개의 차이점?" 을 보면서 또 한번 느낀 것이, 조직 단위 뿐만 아니라, 개인 단위로 이미 상하관계가 형성된다는 것입니다. (물론 단지 이런 이유 뿐만은 아닙니다)

Visual Studio 와 .NET 은 이미 테스팅 분야에 혁신을 진행하고 있고, 우리나라에서 소외되는 테스팅 분야에서 많은 할 일이 남아 있을 것 같아요. 작은 경험이나마 공유하고 도움이 되는 실전 테스팅 기법에 대해서 차근 차근 공부하면서 여러분들에게 알려드릴 계획입니다. 그리고 함께 생각을 정리하는 시간이 되길 바랍니다.