[번역] The Test Center of Excellence

 

이번 호 『Testing Experience』의 주제는 “Test Center of Excellence(TCoE)” 였습니다.

 

제 개인적으로는 생소한 개념인지라 구글링을 해보았더니 이미 해외에서는 이 단어가 몇 년 전부터 일반적으로 사용되었던 것 같습니다. 인포시스에서 2006년에 만든 백서를 참고하면 TCoE의 기본적인 정의는 다음과 같습니다.

 

 

 

즉, 개별 조직이나 프로젝트 단위로 수행되는 테스트 업무를 한 곳에 집중해 프로세스와 툴 등의 리소스를 효율적으로 사용하고 이를 통해 최고의 테스팅 성과를 거두기 위한 테스트 프레임워크를 TCoE라고 정의하고 있습니다. 인포시스의 이 문서에서는 TCoE 프레임워크의 전략적 요소로 Process, People, Technology 를 꼽고 있습니다.

 

이번에 소개하는 Mariya Vankovych의 “The Test Center of Excellence”는 이런 프레임워크의 구조적인 측면보다는 ‘Excellence’ 에 더욱 초점을 맞추고 있습니다. 이 글에서는 TCoE에서 어떻게 탁월한 테스팅 성과를 거둘 수 있는지를 프레임워크의 주요 요소 별로 자세히 설명하고 있습니다. 굳이 TCoE를 활용하는 경우로 한정 짓지 않더라도 일반적으로도 통용 가능한 내용이니 부담 없이 일독해 보시기를 권장합니다.

 

번역 및 포스팅에 대해서는 원 저자의 승인을 받았습니다.

 

Mariya Vankovych 의 블로그 quality-and-life.com

Testing Experience Homepage

 

 

The Test Center of Excellence

 

 By Mariya Vankovych

 

우리는 ‘우수함(Quality[1])’, ‘양호함(Goodness)’, ‘탁월함(Excellence)’ 등의 단어를 일상에서 자주 사용한다. 하지만 이 단어들이 뜻하는 바를 제대로 알고 사용하는 것일까? 메리엄 웹스터(Merriam-webster) 사전에서 이 단어들의 뜻을 찾아보면 다음과 같다.

 

ü  우수함(Quality) – 어떤 종류의 우월함(superiority of kind)

탁월함의 정도나 수준(degree or grade of excellence)

ü  양호함(Goodness) – 적합함(adequate), 만족할 만한 수준(satisfactory)

ü  탁월함(Excellence) – 탁월한 것의 수준(is the quality of being excellent);

탁월하거나 가치 있는 품질(an excellent or valuable quality)

 

일반적으로 ‘탁월함’이라는 말은 보통 수준을 뛰어넘는 품질이나 두드러지게 좋은 것을 의미한다. 그렇다면 과연 누구를 위한 우수함과 양호함이란 말인가? 나? 당신? 아니면 제 3의 누구인가? 사전에는 ‘적합함’이나 ‘가치 있는 품질’이라는 말을 사용하고 있다. 이는 곧 ‘우수하다’ 혹은 ‘양호하다’ 라고 평가하려는 대상에 대해 ‘적합한가?’ 혹은 ‘가치가 있는가?’ 라는 의문을 품을 수 있다는 것을 의미한다. 우리의 경우에는 그 질문의 대상이 소프트웨어라고 할 수 있다.

 

이 문제에 대한 답은 결국 엔드 유저, 즉 제품을 사용하는 사용자가 누구냐에 따라 달라지게 된다. 나에게 필요한 기능을 제공해 주는 프로그램이 나에게는 유용한 프로그램이지만, 다른 사람들은 또 다른 요구사항을 가지고 있을 수도 있다. 다른 사람의 시각에서는 내게 유용한 프로그램이 아무런 소용이 없을 수도 있다는 말이다. 모든 사람들이 서로 다른 요구사항을 가지기 마련이다. 따라서 모든 제품은 제품을 사용하는 엔드 유저가 가지고 있는 요구사항에 따라 얼마나 좋은 품질을 가지고 있는지, 얼마나 유용한 제품인지가 결정된다.   

 

 

 

그림.1 – 제품이 우리에게 원하는 품질을 제공하는지 알기 위해 필요한 몇 가지 질문들

 

품질을 분류하는 다양한 방법이 존재한다. 예를 들어, 이자벨 에반스(Isabel Evans)는 그녀의 저서 “팀웍을 통한 소프트웨어 품질 달성(Achieving Software Quality through Teamwork)”에서 품질을 다음과 같이 분류했다.

 

ü  사용자 기반(user-based) 품질

ü  가치 기반(value-based) 품질

ü  제조(manufacturing) 품질

ü  제품 기반(product-based) 품질

ü  초월적(transcendent) 품질

 

이 항목들을 기반으로 제품 개발 과정을 분석한다면 어떤 면을 더 보강해야 탁월한 결과를 달성할 수 있는지 알 수 있게 된다.  

 

많은 사람들이 세상이 너무 빠르게 변하고 있고 이렇게 변해가는 것들을 하나하나 테스트하고 검증할 시간이 없다고 말한다. 우리는 끊임없이 변하는 고객의 요구에 대응하기 위해 아주 유연해질 필요가 있다. 어떻게 소프트웨어 개발 프로세스가 수행되어야 하는지를 결정하는 가장 중요한 요소는 바로 빠르게 변하는 요구사항과 그에 대응하기 위한 유연함이다. 회사가 시장에서 현재의 위치를 고수하기를 원한다면 이런 게임의 법칙을 반드시 지켜야만 한다. 소프트웨어 개발 프로세스가 변한다면 소프트웨어 업계 역시 변화할 필요가 있다. 소프트웨어에 결함이 발생해 사람의 생명이나 건강에 해를 끼치거나 개인의 데이터를 훼손하는 경우도 있다. 또한 개개인의 재산과 신용에 좋지 않은 영향을 끼치는 경우도 발생한다. 이런 경우 완벽한 검증 없이 제품을 출시하는 것은 결코 바람직한 프로세스라고 할 수 없다.

 

모든 제품들이 월등히 뛰어난 품질을 가지고 출시 이후에도 아무 문제도 발생하지 않는 것은 유토피아에서나 가능한 일이다. 불행하게도 현실 세계에서는 완벽한 품질을 달성하기 위해 극복해야 할 수많은 장애물이 존재한다. 이중 몇 가지를 설명해보면 다음과 같다.

 

1.     대규모 프로젝트를 분석하고 설계할 때, 모든 의존성(dependency)을 파악했다고 확신할 수 있는가? 요구사항 중 일부가 누락되었을 수도 있고, 몇 가지 복합적인 의존관계가 고려되지 않았을 수도 있다. 분석과 설계를 완벽하게 수행하기 위해서는 문서화에 세심한 주의를 기울일 필요가 있다. 이를 통해 요구사항의 변경이나 기술적 변경 사항을 추적할 수 있게 된다. 또한 해당 분야의 전문가를 활용할 수 없다고 하더라도, 지식을 원활하게 전달할 수 있는 훌륭한 도구를 마련하게 되는 것이다. 하지만 이렇게 문서화가 잘 되었다고 하더라도, 모든 항목들이 빠짐없이 분석되었다고 보장할 수는 없다. 문서를 항상 최신의 것으로 유지하는 것은 오랜 시간이 걸리는 아주 힘든 일이다. 엄격한 문서 정책을 적용하고 담당자에게 왜 이런 프로세스가 수행되어야 하는지를 교육함으로써 원하는 효과를 얻을 수 있을 것이다. 이러한 방법론은 특히 의료 관련 산업에서 유용하다. 정확하고 최신화된 문서를 만드는 것은 사전에 합의된 수준의 품질을 어느 정도까지 보장할 수 있다. 이는 곧 소프트웨어의 탁월한 품질을 어느 정도까지는 보장할 수 있다는 말이다. 반면, 게임 웹 포털이나 소셜-인터랙션 웹페이지 분야에서는 거의 이런 방법을 택하지 않을 것이다. 시스템의 장애로 인해 발생하는 리스크에 비해, 이러한 문서화 작업에 드는 비용이 더 많기 때문이다.  

 

2.     프로젝트 관리라는 측면에서 우리가 지금 어디쯤에 와있는지를 아는 것도 중요하다. 여러 가지 방법을 통해 이를 측정하고 보고하는 것이 가능하다. 팀을 관리하는 능력과 기술적인 역량을 겸비한 관리자가 작고 투명한 조직에서 일한다면 굳이 무언가를 따로 측정할 필요는 없을 것이다. 이런 경우라면 팀의 작업이 어떻게 진행되고 있으며, 어떤 일을 하고 있는지를 매일 동료들과 커뮤니케이션 하면서 알 수 있을 것이다. 현재 우리가 어디쯤에 위치하고 있는지 측정하는 방법은 우리가 어떤 분야에 종사하고 있는지, 그리고 우리가 속한 팀의 규모가 어느 정도인지에 따라 달라진다. 단순히 육안 만으로는 모든 사람의 업무 진행상황을 파악하기 힘든 경우도 있다. 우리가 어디쯤에 와있는지를 확인한다는 것은 곧 어떤 요구사항이 충족되었는지를 파악하고, 개별적으로 할당된 업무를 수행할 때 추가로 도움이 필요한 사람은 누구인지를 파악해 프로젝트가 전반적으로 어떤 상태인지를 파악한다는 것을 의미한다. 제대로 제어할 수 없는 프로세스가 존재한다는 첫 번째 경고(갑자기 결함의 수가 증가하거나, 결함이 전혀 발생하지 않거나, 업무를 완료하는 데 일정이 지연되거나)가 발생하면, 관리자는 바로 앞서 말한 측정 프로세스를 수행해야 한다. 프로젝트는 현재의 리스크뿐만 아니라 개발 단계 이전에 수행된 사전 평가와 대비해서도 분석이 수행되어야 한다. 실질적인 개발 업무가 시작되기 전에 리스크 분석과 평가를 완료함으로써, 예상하지 못했던 상황이 발생한다고 하더라도 데드라인 안에 프로젝트를 완수할 수 있는 것이다. 이렇듯 적절한 측정과 보고가 동반되지 않는다면, 제품이 릴리즈된 이후 어떤 이슈가 발생했을 때 “뜨거운 감자”와 같은 문제가 발생할 가능성이 있다. 팀 전체가 탁월한 품질 달성을 위해 함께 일하는 상황에서 문제가 발생했을 때 누구의 잘못인가를 밝히는 것은 결코 중요한 일이 아니다. 하지만 실제로는 모든 사람들이 항상 희생양을 찾기 마련이다. 책임질 사람이 누구인지를 밝혀내기 위해 보고가 필요한 게 아니라, 팀의 약점이 어느 부분이며 이를 어떻게 개선할지를 알기 위한 보고가 필요하다. 프로젝트의 성공 여부는 결국 팀과 그 팀의 성숙도, 요구사항에 따라 달라지는 것이며, 최종적으로 탁월한 성과를 거두기 위해서는 적합한 측정과 평가 방법이 사용되어야만 하는 것이다.

 

3.     요구사항이 끊임없이 변경됨에도 불구하고 최종 산출물이 우리가 원하는 품질수준(관리, 설계, 개발, 검증이라는 측면에서)을 달성할 거라고 어떻게 확신할 것인가? 오늘 내린 결정이 내일도 유효하리라 보장할 수 없는 것이 오늘날의 현실이다. 이미 코딩 작업이 시작된 프로젝트 중간에도 끊임없이 새로운 아이디어와 요구사항이 반영된다. 고객이 새로운 요구사항을 추가할 때 “안됩니다”라고 말하며 제일 처음 요구했던 요구사항에만 맞춰서 제품을 출시할 수는 없는 노릇이다. 만약 이런 일이 가능하다고 해도 결국은 사용자에게 아무 쓸모 없는 제품을 출시하게 되는 것이며 결과적으로는 고객과 비용 모두를 잃게 되는 것이다. 그렇다면 우리는 모든 요구사항의 변경을 받아들여야만 하는 걸까? 이 경우에는 제품의 안정성을 보장할 수 없게 되고 SDLC(Software Development Life Cycle)를 연장하게 됨으로써 마찬가지로 고객의 신뢰를 잃게 될 것이다. 고객에게 “아니오”라고 말하는 것은 경영진에서도 받아들이기 힘든 옵션이다. 고객들은 그들의 요구를 충족시키기 위해 비용을 지불한다. 소프트웨어를 사용하는 다양한 산업 환경을 감안해 새로운 요구사항을 받아들이되, 이후의 릴리즈에 이를 반영할지, 아니면 새로운 요구사항을 그때 그때 반영할지 최적의 결정을 내리는 것이 중요하다. 시스템에 심각한 결함이 존재할수록, 새로운 요구사항을 더 엄격하게 수용해야 한다.

 

일반적으로 소프트웨어 개발 라이프사이클에는 크게 3가지 인적 요소가 존재한다. 고객, 회사(경영진), 그리고 기술 인력(아키텍트, 코딩 및 테스팅 담당 인력)들이다. 여기에 프로바이더나 물류 담당과 같은 써드파티는 일반적으로 포함되지 않는다. 이 3가지 다른 부류의 사람들은 각기 다른 니즈와 목표를 가진다.

 

 

위의 표에서도 볼 수 있듯이, 이 세 부류의 사람들은 하나의 공통된 목표를 가지고 있다. 제품이 최종 릴리즈 될 때 안정적이며 장애가 발생하지 않아야 한다는 것이 바로 그것이다. 어떤 방식으로든 이들 모두는 훌륭한 제품이 나오기를 바라고 있는 것이다. 하지만 이는 여러 항목 중 단지 하나에 불과하다. 일부 다른 항목들은 상호 모순되는 관계를 보이고 있다. 고객들은 제품에 최소한의 비용만 지불하고 싶어한다. 회사는 고객들로부터 더 많은 비용을 받기를 원하고 직원들에게는 비용을 덜 쓰기를 원한다. 회사에 고용된 사람들은 더 높은 연봉을 받기를 원한다. 이는 상호모순 적인 관계의 일부를 보여줄 뿐이다. 

 

이렇듯 소프트웨어 개발 라이프사이클 내에 존재하는 니즈와 목표들이 서로 다르기 때문에 모든 사람들이 원하는 결과를 얻을 수 있는 단 하나의 방법은 당사자들이 합의(consensus)를 도출하는 것이다. 모든 합의는 논의를 통해 도출되어야 하며, 그 결과는 다음의 항목에 따라 달라진다.

 

ü 고객이 원하는 것은 무엇인가?

ü 고객이 원하는 것을 얻기 위해 감내할 수 있는 것은 무엇인가?

  (일정 지연, 릴리즈 이후 발견 가능한 마이너한 이슈들, 예상보다 많은 추가 비용 지출 등)

ü 해당 산업 환경과 시스템에 결함이 발생할 경우 최악의 시나리오

ü 회사의 전략과 목표 달성 가능성

ü 직원들의 니즈와 가능성

ü 사용하는 방법론

ü 사용하는 플랫폼

ü 그 밖의 요소들

  (그림. 2 참조)

 

그림.2 - IT 프로젝트의 주요 구성요소

 

자, 그럼 이제 TCoE(Test Center of Excellence)의 주요 항목들을 좀 더 자세하게 살펴보자. 가장 중요한 항목은 바로 사람이다. 구성원들이 탁월한 성과를 내기 위해 필요한 몇 가지 항목들이 있다. 무엇보다도 먼저 훌륭한 성과를 내고자 하는 모티베이션이 이루어져야 한다. 이러한 모티베이션은 내부적인 모티베이션(성공을 위한 욕구, 대규모 팀 안에서 스스로가 중요한 일을 수행하는 일원이라는 자부심)과 외부적인 모티베이션(평가, 보너스) 등이 동시에 이루어져야 가능하다. 프로젝트의 구성원들은 스스로 새로운 기술을 학습하려는 욕구를 가지고 있어야 하며, 또한 그런 기회가 주어져야 한다. 여기에 더해 구성원들은 효율적인 커뮤니케이션 능력을 보유하고 있어야 한다. 다른 사람의 비판을 수용할 줄 알아야 하며, 듣는 사람이 기분 나쁘지 않게 이슈에 대해 이야기할 수 있어야 하고, 외교적인 수완을 겸비해야 한다.

또 다른 중요한 요소는 프로젝트에서 사용되는 방법론이다. 워터폴 방식을 사용할지 혹은 애자일 방식을 사용할지에 대한 결정이 이루어져야 한다. 이 문제는 주로 어떤 분야에서 일을 하느냐에 따라 달라진다. 만약 프로그램에서 발생한 결함으로 인해 사람이 죽을 수 있거나 혹은 심각한 상해를 입을 수 있다면, 이를 커버할 수 있는 완벽한 매트릭을 작성할 수 있고 라이프사이클의 전 단계를 제어할 수 있는 방법론을 선택해야 할 것이다. 이런 특별한 경우에는 고객들이 CMMI 레벨과 같은 항목을 요구할 수도 있다. (그림.3 참조)

 

 

 

그림.3 – 제품의 기능성 vs. 고객 니즈와의 상호관계

 

탁월한 성과 달성 여부는 또한 우리의 고객이 누구인가에 따라 달라진다. 우리가 만드는 제품이 보편적인 고객들을 대상으로 하는 제품인지, 혹은 좀 더 특별한 과정을 거쳐 특정한 고객을 대상으로 하는 제품인지, 아니면 소수의 고객을 위해 처음부터 새로 만드는 제품인지에 따라 달라지는 것이다. 첫 번째의 경우에는 모든 사람들의 니즈가 다르므로 보편적인 탁월한 품질을 달성하기 힘들다. 이런 경우 제품이 제공하는 기능과 니즈가 일부 중복되는 부분이 발생하지만, 이와 반대로 특별한 애드온이 개발되어 추가되지 않는 이상 커버되기 힘든 요구사항도 발생하기 마련이다. 고객을 고려할 때 산업 분야의 특성도 함께 고려해야 한다.  앞에서 설명한 바와 같이, 의료나 공공기관, 운송과 같은 분야에서는 하나의 결함으로 인해 발생하는 손해비용이 아주 높을 수 있기 때문에 무결점(Zero-defect) 상태를 목표로 하는 것이 중요하다.

 

최근에는 하루가 멀다 하고 혁신적인 툴들이 출시되고 있다. 또한 다양한 방법과 기술을 사용해 검증해야 하는 플랫폼도 끊임없이 출시되고 있다. 심지어는 이를 위해 기존에 사용하던 검증 프로세스를 변경해야 하는 경우도 있다. 요즘은 대중들이 쉽게 접할 수 있는 거의 모든 소프트웨어 제품의 모바일 버전이 출시되고 있다. 얼마나 많은 모바일 디바이스들이 유효한 단말인지를 고려해야 한다. 그렇다고 모든 디바이스에서 모든 소프트웨어 제품을 검증하는 것 역시 불가능한 일이다. 소프트웨어 개발 라이프사이클에서 주요한 모든 요소들이 탁월한 성과를 거두기 위해서는 일단 무엇이 테스트되어야 하고, 어떤 플랫폼이 테스트되어야 하며, 언제 검증 프로세스를 중단해야 하는가를 알아낼 필요가 있다. 이를 위해서는 우선 시장에 대한 완벽한 분석이 선행되어야만 한다.

 

마지막으로 소프트웨어 개발사의 성숙도 역시 무척이나 중요한 요소 중의 하나이다. 구성원들이 사용하고 있는 프로세스나 해당 프로젝트를 위해 수립된 정책과 프로세스 등의 성숙도가 높을수록, 더 탁월한 품질의 최종 제품이 출시되기 때문이다.

 

예술적인 수준으로 다양한 요소들의 균형을 맞추고 이를 유지해 나간다면 이를 ‘탁월하다’라고 평가할 수 있을 것이다. 이는 곧 무엇이 필요한지, 어떻게 이를 달성할지, 그리고 이런 필요한 것들을 얻기 위해 어떤 일들이 수행되어야 하는지에 대한 적절한 조합을 찾아내는 과정인 것이다. 가장 위험한 것은 소프트웨어 개발 라이프사이클의 여러 요소들 중에서 한 가지에만 집중하는 것이다. 프로세스의 한 면만 본다던가, SDLC의 한 가지 요소만을 고려하는 것은 제품 생산을 지연시키고, 소프트웨어의 가격을 필요 이상 비싸게 만들며, 개발팀을 지치게 만들고, 결국은 요구사항 조차 충족하지 못하게 만든다.  

 

대화하고, 커뮤니케이션하고, 토론하고, 계획을 세우고 분석하고, 합의점을 찾는 것이 필요하다.

탁월한 성과는 이를 통해 달성되는 것이다.

  

---

[1] 역자 주: ‘Quality’는 일반적으로 ‘품질’이라는 의미의 명사로 사용되지만, ‘quality furniture’, ‘quality service’와 같이 ‘우수한’, ‘양질의’라는 의미의 형용사로 사용되는 경우도 있다. 같은 문장에서 사용되고 있는 “goodness”, “excellence” 등이 형용사의 명사형으로 사용되었으므로 여기에서는 ‘quality’를 ‘우수함’이라는 형용사적 의미의 명사형으로 해석했다.