2012. 10. 19. 16:02

비슷한 글들로 유입되는 방문자가 많아서, 관련 글들 묶어둡니다.

QM, QE, QA, QC, 그리고 Test - http://xelion.tistory.com/1202
QA는 개발자인가요? - http://xelion.tistory.com/1243
테스트 용어 재정립에 대한 이야기 - http://xelion.tistory.com/1280

알려드립니다. 오래된 글들은 
 1) 현재 제 생각과 다를 수도 있고, 
 2) 그 당시 제가 잘 못 알고 있었을 수 있으나 수정할 생각은 없으며, 
 3) 예전 글들은 당시의 언어로 쓰여져
지금 읽기에는 편하지 않으실 수 있습니다.

몇 일 전, 오랜만에 감사 댓글 남겨주신 분도 있고 해서, 기념으로(?) 예전부터 마음에 걸리던 용어 사용 중 하나에 대한 이야기를 객관적 사실들로 엮어서 글을 써 보았습니다. 이런 객관적인 견지를 이용한 종류의 글을 자주 쓰지 않는 이유 중, 가장 큰 이유는 "귀찮아서" 입니다. 그리고 두 번 째 이유는, '사실을 빌미로' 개인적인 생각을 섞어서 마치 종교의 교리를 전파하는 종교적인 방식으로 전파되는 소프트웨어 개발방법론 전파 방식에 염증을 느끼기 때문입니다. 이에 대한 긴 이야기는 언제 내킬 때 해 보도록 하지요.


어쨌든, 오늘은 2012년 관점에서 "소프트웨어 테스트"라는 정의가 이제는 각 역할에 맞게 분화되어야 하지 않는 가에 대한 이야기를 해 보려 합니다. 업무로서의 테스트는 무엇일까요? 검증은요? 감리는 뭐고 감사는 뭘까요? QA니 QC니 하는 것들 대체 다 뭘까요? 이런 것들을 정리하려고 애쓰는 글을 남들에 비해서는 자주 올리는 편인데, 또 그런 글 중 하나입니다. 오늘은 아주 조금 더 객관적이지요.


소프트웨어 테스트는 제품이나 서비스의 품질에 대한 정보를 이해관계자에게 제공하기 위해 실시되는 시험 조사활동으로, [Wikipedia, Software Testing] 전 세계적으로 매우 빠른 성장을 나타내고 있는 분야입니다. 소프트웨어 테스트는 누구나 할 수 있는 일이라는 세간의 믿음과 다르게, 소프트웨어 테스트 활동은 소프트웨어 개발 생명주기에서 넓은 범위에서 지속적으로 이루어지는 활동이라는 점 때문에 매우 복잡하고 어렵다는 특징을 가지고 있는 분야입니다. [W. Hetzel, The complete guide to software testing, 1998] 또한, 소프트웨어 테스트 활동의 어려움은 현재 프로그래밍의 근간을 이루고 있는 객체지향(Object Oriented) 모델링 방법의 복잡성 때문에 발생합니다. 객체지향 모델링 개발 방법론은 프로그래밍에 획기적인 전환점을 마련해 준 동시에, 매우 까다로운 테스트의 복잡도를 야기시켰습니다. [R. V. Binder, Testing Object-Oriented System Model, patterns and tools, 2000]


어떠신가요, 테스트라는 활동이 뭔가 좀 어렵고 고귀해 보이지요. 하지만 이런 외국의 이야기들은 소프트웨어 테스트 활동을 debugging 활동으로 보는 것이 아니라 evaluation이나 prevention 활동으로 보기 때문에 나오는 이야기들입니다. 그리고 바로 위의 이야기를 기반으로 하여, 한국 소프트웨어 품질의 현재 문제점과 소프트웨어 테스팅 분야가 나아가야 할 방향에 대해 이야기해야 합니다. 하지만 그런 고차원적인 컨셉을 제안하기 전에, 기본적으로 우리는 "테스트(Test)"라는 용어를 잘 못 사용하고 있으므로 이 부분에 대해 먼저 짚어보아야 합니다.


지식경제부 산하, 정보통신산업진흥원 소속 소프트웨어공학센터가 2012년에 발표한 『SW테스팅 동향브리핑에 대한 보고서』에 따르면, 기업 컨설팅 전문업체인 Pierre Audoin Consultants(PAC)는 전세계적으로 많은 기업들이 애플리케이션 테스트 및 품질 보증에 연간 500억 달러 이상을 투자한다고 발표하였고, IDC, Forrester와 같은 시장조사기관도 테스트 서비스 시장이 향후 5년간 연평균 15.4% 성장세를 나타내면서 2015년에는 193억 달러 규모에 이를 것이라고 전망하였으며, 인도소프트웨어개발자협회인 NASSCOM은 테스트 서비스 시장 규모가 2010년 35억 달러에 달했으며, 2020년까지 연평균 17%의 성장률을 나타낼 것이라 전망하였습니다. [소프트웨어공학센터, SW테스팅 동향브리핑에 대한 보고서, 2012]


이러한 소프트웨어 테스트 역량은 국내가 해외의 경우보다 낮은 편으로써, 소프트웨어공학센터에서 2012년 발표한 소프트웨어 공학백서에 따르면, 한국은 개발단계의 테스트 활동으로 식별하는 결함이 14% 정도로 외국의 24%에 비해 10%가량 낮은 것으로 나타났습니다. [소프트웨어산업진흥원, SW공학백서, 2012] 외국과 국내의 테스트 활동 결과가 차이 나는 이유는 한국에서는 소프트웨어 테스트 활동을 시스템 통합 이후에 실행하는 프로세스라는 인식이 굳어져 있기 때문이며, 이런 인식을 해결하기 위한 여러 가지 접근이 소프트웨어공학센터 내에서 수행되고 있습니다. 소프트웨어 테스트 활동은 사실 품질 비용으로 이야기되어야 하며, 내부실패 비용, 외부실패 비용 등을 역추적하여 문서 리뷰, 프로세스 개선 등의 활동을 진행해야 합니다. 이를 통해 소프트웨어 개발 생명 주기 내에서 조직이 전반적으로 발전해 나아갈 수 있도록 하는 프로세스를 '소프트웨어 테스팅'이라고 합니다. [소프트웨어 테스팅 제2판] 


자, 이제 우리들의 이야기를 해 볼까요? 소프트웨어 검증이니 소프트웨어 테스트니 하는 용어들은 대체 무엇일까에 대해 가만히 살펴보면, 사실 우리는 몇 가지 활동들을 'QA'라는 이름으로 포괄적으로 묶어서 이야기 하고 있음을 알 수 있습니다. 일반적으로 한국에서 QA라는 역할은 'PM따까리' 아니면 '단순 테스터' 인 경우가 대부분입니다. 이런 현상은 PMBOK에서 QA에 대한 개념을 제대로 가르치지 않아서 대충 배운 PM들이 그렇게 만들어 놓아서 그렇기도 하고, 그런 상태에서 너무 오랜 시간이 흘러 모두가 「QA = 테스트」라고 인식하고 있어서 그런 것인데요, 이 부분을 해결하려 제가 PMBOK을 들이 파고 PM담당자들에게 PMBOK 8장을 제대로 알리기 위한 활동을 개인적으로 진행하고 있습니다.

(PMBOK의 관점에서) PMBOK 등의 정의에는 QA와 QC를 명확히 구분하고 있지만, 정작 QA와 QC를 이루기 위한 Tool(도구, 방법)에 대한 설명은 명확하게 해두지 않았습니다. [http://www.pmi.org] 또한 테스트에 대한 이야기를 시스템 통합 이후의 테스트를 이야기만 살짝 해 두었기 때문에, 정황에 따라 달라지는(Context Driven) 테스트의 기본 성질을 제대로 알리지 못하고 있습니다. [http://context-driven-testing.com]

또한 한국에서 가장 공신력 있게 사용되는 소프트웨어 테스트 관련 자격증인 ISTQB(International Software Testing Qualifications Board)에서도 요구사항 품질, 설계 품질에 대한 이야기는 자세히 다루지 않습니다. 오로지 블랙박스 단에서의 테스트 설계 기법들에 대한 이야기들이 위주가 됩니다. [http://www.istqb.org]

그런데 저런 PMBOK이나 ISTQB를 딴 사람들을 우리는 흔히 '경력자' 혹은 '자격이 되는 사람'으로 생각하고 현업에서 그들을 위주로 업무를 진행할 수 밖에 없습니다. 그러다 보니 테스트라는 용어가 단지 완성된 제품을 사용자 입장에서 사용해 보는 것으로 곡해되고 있습니다. 또한, 나름대로 전문가라고 강의에서 발표하시는 분들 대부분이  "QA=Test"로 인식하고 말씀하시더군요.

또 다른 측면에서 이 문제를 바라보자면, SW공학 자체가 이론이 체계화된 지 얼마 되지 않았고, 근래까지도 '어떻게 개발할 것인가'에 맞추어서 발전해 왔다는 점을 들 수 있습니다. 그리고 또한 SW공학 자체가 "대규모의", "위험이 큰(Mission Critical)" 제품들을 위주로 발전해 왔기 때문에, '테스트 활동' 보다는 '검증' 활동에 초점이 맞추어진 채로 발전한 것도 사실이고요.

그렇기 때문에 여기에서 우리가 외국의 경우가 어떻다 저떻다 하며 구질구질하게 사대주의를 내보이는 것 보다는 지금 우리가 처한 입장을 직시하고, 이 문제를 해결할 방안을 제안하는 것이 더 생산적이지 않을까 합니다.

일단, 우리가 Software QA라는 업무에서, 그 중 'QA'라는 단어로 사용하는 한국어 단어들을 살펴보았습니다. 예문이 다소 극단적으로 보일 수도 있습니다만, 아이러니하게도 실제 생활에서 저런 식으로 쓰인다는 게 재미있는 점입니다. 아마 이 글을 읽으시는 분들도 이렇게 사용하고 계실겁니다. 오랫동안 고민하면서 QA업무 하셨던 분들은 정말 싫으실 지도 모르겠어요. (혹시 이 외에도 Software QA로 사용되는 한국말이 있다면 알려주세요.)

대한민국에서의 QA = 테스트, 확인, 검토, 검사, 검증, 감사, 감리

1. 우리 QA 했어? -> QA = 테스트
2. 우리 그거 QA 해봐야 하지 않나? -> QA = 확인
3. 우리 빌드 아직 QA 안 거쳤어. -> QA = 검토, 검사
4. 우리 제품 최종 QA 해야 돼 -> QA = 검증
5. 품질관리 할려고 QA 뽑아서 프로세스 개선해요. -> QA = 감사, 감리

흔히 QA를 업으로 가진 사람들끼리도 위와 같은 이런 복잡한, 그러나 미묘하게 다른 단어들을 뭉뚱그려 단지 「QA」라는 하나의 표현으로 사용하곤합니다. 그래서 제 주위에 좀 깨이신 분들은 말하다가 중간에 "지금 말하는 QA가 테스트니? 검증이니? 감사니?" 하고 묻는 분들이 있습니다. 아주 옳은 습관이십니다. 개인적으로 그런 분들 좋아합니다. "대충 남이 쓰는 대로 따라 하자" 라고 하는 사람들은 안 좋아합니다. 소프트웨어 공학은 제 직업이니만큼, 이 분야에서만큼은 호불호가 명확합니다. 그리고 이런 부분에 대해 포기할 생각이 전혀~ 없습니다.

위에 나열된 한국어 단어들의 기본적인 사전적 의미를 좀 볼까 합니다.

※ 참고문헌 - 네이버, 다음, 네이트 사전

테스트
- 제품의 성능이나 상태 따위를 일정한 기준에 따라 검사함, 일정한 기준에 따라 검사하다
- 사람의 학력, 지능, 능력이나 제품의 성능 따위를 알아보기 위하여 검사하거나 시험함. 또는 그런 검사나 시험.

확인
- 확실히 인정하거나 알아봄.
- 틀림없이 그러한가를 알아보거나 인정함. 또는 그런 인정.

검토
- 어떤 의견이나 그 내용을 찬찬히 살피거나 잘 따져 봄.
- 어떤 사실이나 내용을 분석하여 따짐.

검사
- 어떤 일이나 사실의 옳고 그름이나 사물의 좋고 나쁨 따위를 살피거나 조사함.
- 사실이나 일의 상태 또는 물질의 구성 성분 따위를 조사하여 옳고 그름과 낫고 못함을 판단하는 일.

검증
- 가설이나 사실, 이론 등을 검사하여 참인지 거짓인지 증명함.
- 검사하여 증명함. 
- 어떤 명제의 참, 거짓을 사실에 비추어 검사하는 일. ≒ 실증(實證).

감사
- 법적 권한이 있는 기관이 단체나 조직의 업무 상황을 감독하고 조사함.
- 감독하고 검사함. 

감리
- 주로 공사나 설계 따위에서, 일이 잘 진행되고 있는지 감독하고 관리함.
- 감독하고 관리함.

자, 보시다시피 우리가 혼재해서 사용하고 있는 "Software QA"라는 업무에 이렇게 많은 다양한 의미가 내포되어 있습니다. 그러니 대부분 QA로 입사한 신입들이 자기 정체성 찾는 데만 1~2년을 쓰게 됩니다. 너무 비효율적이죠. 이런 과정이 없었다면 한국의 QA업계는 더 많이 발전했을 겁니다.

어쨌든, Software QA라는 것은 본래 (Test가 아니라) Validation하고 Verification하는 게 주 업무의 목적이다 보니, 위에 나열된 여러 가지 활동들을 각기 다른 접근 방법, 즉 도구(Tool)로 사용합니다. 그러다 보니 QA가 직업이 아닌 사람들이 보기에는 마치 QA 역할을 맡은 사람들이 '지네끼리 다 하는' 것 같은 느낌을 받으실 때도 있을 겁니다.

아참, 말 나온 김에 Validation과 Verification을 짚고 넘어가시죠.

※ 참고문헌 - ISTQB syllabus

Validation
Confirmation by examination and thorough provision of object evidence that the requirements for a specific intended use or application have been fulfilled. [ISO9000]

Verification
Confirmation by examination and through the provision of objective evidence that specified requirements have been fulfilled. [ISO9000]

일반적으로 Validation&Verification을 '확인과 검증' 이라고 번역하는데, 위에서 보여드린 국어 사전적인 의미로 보면 '검사와 검증'이 되어야 하는군요. Validation은 요구사항이 의도된 대로 사용되는가를 보는 것이니 사전적 의미로는 '검사'에 가깝고, Verification은 요구사항을 충족하는지를 객관적 증거를 통해 보는 것이니 '검증'에 가깝지요.

예, 맞습니다. 

바로 (위에서 V&V를 한글로 재 정의한) 이런 식으로 Software QA 직업 군을 세분화할 수 없다면, Software QA가 해야 하는 업무라도 세분화해야 하지 않는가 생각합니다. 

술자리에서 지인들과 술김에 논의하고 정작 이 부분은 검토하지 않았지만, 제가 제안하는 재정립 방안은 다음과 같습니다.



너무 당연한 거라 실제 말하기는 민망한데, 오늘은 이런 포스팅을 쓰니까 말씀 드릴 수 있겠네요. 


이 세상의 모든 테스트는 「기대 결과」를 예측하여 진행해야 합니다.


그러합니다. 모든 테스트는 '어떻게 되어야 하는가' 에 대한 기준이 있는 상태에서 진행되어야 합니다. 프로젝트에 이렇다 할 문서나 결과에 대한 기준이 존재하지 않는다면, 그런데도 상식적인 수준에서 기대결과가 예측되는 기능이 아니라면, 반드시 PM담당자나, Dev담당자들과 이야기해서 협의해야 합니다. QA담당자들이 스스로 기준을 정해선 안됩니다.

위의 표는 저의 제안입니다. 혹시 더 나은 방법을 연구하신 분이 있으면 Trackback 하나 보내주세요. 

조금은 구태의연할 지도 모르겠습니다만, 이런 용어의 혼돈이 빨리 정리가 되어야 한다고 믿습니다. 이런 부분이 정확히 정립이 안되어 있으니까, 프로그래밍하는 Dev담당자들이 "내가 다 알아서 할 테니 QA뽑아서 사용자 관점에서 제품 사용해 줄 사람만 찾아라" 라는 말도 안 되는 이야기를 하는 것이고, 회사는 그것이 옳다고 착각하고 Test 인력을 뽑다 보면, 회사의 재정 상태가 안 좋아졌다는 걸 알고 원인 분석을 할 때쯤, 전문 테스터(Tester)라는 게 허울뿐인 가식이라는 걸 깨닫게 되시죠. 정확히 말하자면, 기본적인 「소프트웨어 공학 역할을 담당해야 하는 QA 역할」을 제외하고 단순히 Test 업무 하는 사람만 뽑는다면, (적어도 제가 관찰해온 바로는) 그 조직은 발전할 수 없습니다. 단 한 번도 그런 조직을 본 적이 없습니다. 그래서 삼성이나 LG같은 대기업이 아닌 이상 그런 형태는 추천하지 않습니다. 그 분들이야 테스터 몇 백 명 뽑아 쓸 수 있으니까 가능하시죠. 실제로 중국에 테스트 센터에 몇 백 명이 테스트하고 있구요. 이 부분은 또 애기하면 길어지니까 그만 하겠습니다.

최근 국가적으로 국가 사업을 통해 한국 SW의 R&D 역량을 향상시키려 노력하고 있습니다. R&D 역량은 과정을 통해 배우는 재 학습 효과를 통해서만 발전합니다. 결과론적으로, 사용자 관점의 제품 품질에 대한 테스트가 아닌, 설계 품질이나 코딩 품질을 향상시켜야 하는데, 그러기 위해서는 아이러니하게도 QA라는 용어를 재정립해야 한다는 결론에 봉착해서 (제 기준으로는 어처구니 없는) 포스팅을 올려보았습니다.

위에 설명한 바를 실행하기 위한 실제 활동 예제는 다음 번에, 내킬 때 올려보겠습니다. 
(하겠다 이래 놓고 안하는거 많은거 아시죠? 기대는 하지 마십셔~)




Posted by 『 Lv8+の 꽃怪獸 』 천년나무