[컴퓨터월드]

지금까지 우리는 제품의 품질을 향상시키기 위한 테스트 절차와 방법에 대해 알아봤다. 테스트 계획을 시작으로 테스트 설계와 환경 구축, 정적 테스트(Static Test)인 리뷰와 코드 인스펙션(Code Inspection) 및 테스트 관리도구 등등. 우리는 제품의 품질을 향상시키기 위해 다양한 테스트 활동이 필요하다는 것을 알고 있다. 그러나 보다 효율적인 테스트 수행을 위해서는 테스트 조직에서 수행하고 있는 테스트 프로세스 개선이 필요하다. 여기에서는 E-Commerce에서 도입되었던 테스트 개선 사례와 방법 및 효과에 대해서 이야기한다.

테스트 프로세스 개선 모델이란?

다양한 테스트 절차가 필요하다는 사실은 모두가 동의하고 있다. 하지만 각 절차 별로 어떠한 행동과 어떠한 산출물이 생성되고 관리돼야 하는지에 대해서는 정의된 프로세스가 존재하지 않는 경우가 많다. 또한 잘 정의된 프로세스가 있다고 하더라도 실제로 어떠한 활동을 수행하고 있으며, 부족한 내용은 무엇인지에 대한 지속적인 관리 및 점검이 필요하다.

테스트 활동에 대한 지속적인 관리, 점검 및 개선을 위해 사용되는 모델을 프로세스 개선 모델이라고 한다. 현재 국내에서 가장 많이 언급되고 있는 테스트 프로세스 개선 모델로는 TMMi(Test Maturity Model Integration)가 있다. TMMi는 CMMi(Capability Maturity Model Integration)의 구조를 바탕으로 개발됐는데 대표적으로 소제티(Sogeti, 네덜란드)에서 개발한 TPI Next 모델을 들 수 있다.

TPI Next는 각 테스트 프로세스 별로 성숙도를 진단하고, 각 진단 테스트 프로세스 결과에 따라 개선방안을 제시한다. TPI Next는 특정 테스트 프로세스 개선을 준비하는 기업에 적용할 수 있다. 일반적으로 전사적인 대규모 테스트 조직에 대한 테스트 프로세스 개선에 TMMi를 선택할 수 있지만, 단순한 테스트 팀이나 소규모 조직에서는 TPI Next를 적용하는 것이 좋다.

그렇다면, 이러한 테스트 프로세스 개선 모델을 테스트 조직에 도입할 경우 조직의 테스트 성숙도가 높아지고 제품의 품질이 향상될 수 있을까?

우리가 항상 범하는 오류 중 하나는 어떠한 시스템이나 프로세스가 조직에 도입되거나 구축될 경우 즉시 효과가 나타날 것이라고 생각하는 것이다. 이전 기고에서도 언급했지만, 테스트 도구를 도입한다고 해서 바로 테스트 수행 시간이 감소하거나 품질이 향상되는 것은 아니다. 테스트 프로세스 개선 모델 역시 마찬가지다.

테스트 프로세스 개선 모델의 활용 방법은?

테스트 조직들은 테스트 프로세스를 개선하기 위해 위에서 언급한 TMMi나 TPI Next(또는 TPI, Test Process Improvement)와 같은 테스트 프로세스 개선 모델을 도입한다. 테스트 프로세스 개선 모델을 도입하기 전에 우선적으로 해야 할 일은 현재 테스트 조직의 상태를 정확히 파악하는 것이다. 그래야만 테스트 도구를 도입할 때와 마찬가지로 쉽게 도입 가능하며, 가장 큰 효과를 볼 수 있는 테스트 프로세스 개선 모델을 선택할 수 있다.

만일 테스트 조직의 상태를 파악하지 않고 무작정 테스트 프로세스 개선 모델을 도입한다면, 테스트 조직의 업무를 향상시키고 개선하는 것이 아니라, 오히려 테스트 조직의 업무만 늘어나고 필요 없는 문서나 활동이 늘어나는 결과를 가져올 뿐이다.

테스트 조직의 프로세스를 개선하기 위해서 가장 먼저 해야 할 일은, 현 조직의 현황을 파악하고 분석하는 일이다. 규모가 작은 조직의 경우에는 TPI Next 모델의 체크리스트를 활용해 각 프로세스 별 강점과 약점을 파악해야 한다. 기타 산출물 및 프로젝트 관련자들과 인터뷰를 통해 조직의 현황을 파악해야 하는 것은 필수적이다.

조직의 현황 파악이 끝나면 실제로 수행 가능한 개선활동에 들어가야 한다. TMMi나 TPI Next에서 제시하는 모든 절차 등을 적용하면 좋겠지만, 회사나 조직의 여러 상황을 고려해 가장 도입이 쉽고 효과가 높은 영역을 찾아 개선활동을 수행하는 것이 가장 좋다.

E-Commerce의 테스트 프로세스 개선사례

E-Commerce는 대부분 웹 기반으로 개발 후 서비스를 제공한다. 웹 기반 서비스는 문제가 발생한 경우 빠르게 해결할 수 있다는 것이 장점이다. 그러나 이러한 점은 서비스 제공자와 개발자 입장에서는 장점이 될 수 있지만, 테스트 조직의 입장에서는 단점으로 작용할 수 있다. 왜냐하면, 테스트 조직의 입장에서 보면 정해진 시간이 아니라 수시로 테스트를 수행해야 한다는 것을 의미하기 때문이다.

A사의 테스트 조직은 테스트 프로세스 개선을 위해 다음과 같은 개선활동을 진행했다.

● 테스트 수행 절차 개선
● 변경된 요구사항 관리
● 결함관리도구 도입
● 테스트 환경 구축
● 지속적인 개선활동

첫 번째로 진행한 테스트를 수행하면서 가장 먼저 주의해야 할 점은 테스트 수행 시간, 테스트 배포 시간, 테스트 모니터링 시간을 정해진 일정에 맞춰야 한다는 것이다. ‘이러한 활동이 뭐 그리 중요하고 어려울까’라고 생각하겠지만, 실제로 E-Commerce 서비스 제공업체로서는 결코 쉽지 않은 절차 중 하나이다. 지속적으로 결함이 발생되고 개선되는 기능을 빠른 시간 내에 수정해 서비스에 반영해야 하는 E-Commerce의 특성 때문이다.

테스트 엔지니어들이 가장 많이 하는 질문중 하나는 “과연 언제 테스트를 시작해야 하는가?” 이다. 일반적으로 테스트는 프로젝트 시작과 함께 수행해야 한다. 프로젝트 초기부터 요구사항 명세서를 바탕으로 분석 및 테스트 케이스 설계를 진행해야 하는 것이다. 그러나 너무도 당연한 이러한 절차를 잘 준수하고 있는 조직은 많지 않다. 특히 조기 테스트 수행을 위해서는 요구사항 관리가 필수다. 요구사항 변경에 대한 관리가 이루어지지 않는다면 조기 테스트의 의미는 퇴색된다.

A사는 요구사항을 관리 도구가 아닌 워드나 파워포인트로 관리했다. 현실에 맞게 변경된 요구사항이나 변경된 내용에 대한 히스토리를 워드나 파워포인트로 관리한 것이다.

도구를 사용하지 않는 방법이 구식이라고 생각할 수도 있지만 이 또한 효과적이라 할 수 있다. 현실적으로 변경되는 모든 요구사항 명세서를 하나의 도구로 관리하는 것이 어렵기 때문에, 변경되는 요구사항에 대해서 이전과 어떤 내용이 변경되었는지 최소한의 표시만으로도 테스트를 진행하는데 많은 도움이 된다.

다음으로 진행한 개선 활동은 결함관리도구를 도입하는 것이다. 결함관리의 가장 큰 목적은 결함의 상태를 파악하고 현재 제품이나 서비스의 품질을 측정하는 것이다. A사는 테스트 수행을 테스트 전문 조직이 아니라 개발자나 기획자가 진행했기 때문에 테스트 수행 시 발견된 결함에 대해 체계적인 관리가 이뤄지지 않고 있었다.

이런 경우 보통 오픈소스 기반의 결함관리도구나 상용 결함관리도구를 도입하는 경우가 많다. 하지만, A사는 이미 자체적으로 운영되고 있는 포털 시스템이 있어, 이 포털 시스템의 게시판을 결함관리도구로 활용했다.

물론, 오픈소스나 상용 결함관리도구를 활용하는 경우에는 다양한 결함정보를 수집하고 대시보드 등을 통해 다양한 결함분석이 가능하다는 장점이 있다. 하지만, 새로운 시스템을 도입하는 경우에는 추가적인 유지보수 비용과 관리를 위한 인원이 더 필요하다. 이런 이유로 A사는 기본 시스템을 응용해 사용한 것이다.

이를 통해 A사는 결함관리도구 도입 비용과 관리 비용을 절약할 수 있었고, 또한 도구를 사용하는 사용자에 대한 추가적인 교육없이 빠른 도입이 가능했으며 다른 사용자들의 불만없이 업무를 진행할 수 있었다.

마지막으로 진행된 개선활동은 테스트조직을 위한 테스트 환경구축이다. E-Commerce에서 테스트를 수행하는 경우 가장 중요한 건 테스트환경이다. 지금은 보편화 되어 있지만, 아직까지도 테스트 조직을 위한 테스트 환경 구축이 미흡한 조직이 많다. 일반적으로 개발자가 개발한 기능에 대해서는 개발자 PC에서 단위 테스트를 수행하고, 전체 기능은 통합해 테스트를 수행한다. 통합 테스트 환경에서 테스트를 수행하고, 특별한 이상이 없는 경우에는 배포 후 모니터링을 진행한다.

하지만, 테스트 조직이 있는 경우에는 테스트 조직을 위한 테스트 수행 환경이 필요하다. 일반적으로 통합 테스트 환경에서는 많은 개발자들이 테스트를 수행하기 때문에, 수시로 데이터가 변경되거나 소스가 변경되는 경우가 많다. 이러한 현상은 테스트 수행 결과에 많은 영향을 미치며 테스트 수행결과에 대한 신뢰성에 문제를 야기하기도 한다. 테스트 조직을 위한 테스트 환경이 반드시 구축되어야 하는 이유이다.

즉 V-Model의 테스트 레벨로 본다면 시스템 테스트가 가능한 테스트 환경이 구축되어야 하는 것이다. 물론 시스템 테스트라고 이야기는 했지만, 꼭 비기능 테스트가 가능한 테스트 환경을 의미하는 것은 아니다. 테스트 조직은 개발이 완료된 요구사항에 대해서 최종적으로 외부의 영향을 받지 않은 상태에서 테스트를 수행할 수 있어야 한다.

품질향상을 위한 지속적인 개선활동

이렇게 테스트 수행 절차 개선, 변경된 요구사항 관리, 결함관리도구 및 테스트 환경 등이 구축되면 이를 바탕으로 테스트를 수행하고, 수행결과를 지속적으로 확인하고 분석해야 한다. 또한, 테스트를 수행하면서 부족한 부분이나 개선이 필요한 내용에 대해서는 기획자, 개발자, 배포관리자 등의 피드백을 받아서 부족한 부분을 보완하고 지속적으로 개선해야 한다. 가능하다면 품질지표를 설정해 지난 달과 이번 달의 목표를 비교하고 어느 정도 개선이 되었는지 확인하는 것도 좋은 방법이다.

위에서 언급한 방법은 PDCA 사이클과 같이 목표설정 후 실천 계획을 세우고(Plan), 실천계획을 수행하며 그 결과를 측정(Do)한 후, 측정결과를 평가(Check)하며, 이를 바탕으로 실제로 개선활동을 진행(Act)하는 방법과 유사하다.

A사는 위에서 언급한 PDCA 사이클과 유사한 방법을 활용했다. Act에 해당하는 개선활동을 위해 정적분석도구 PMD를 도입했으며 현재는 개발코드에 대한 품질까지 측정하고 있다. 개발자는 본인이 개발한 소스코드에 대해 반드시 PMD Rules을 통과해야만 테스트를 수행할 수 있고, 배포가 가능하도록 절차를 개선했다.

개선모델 도입보다 중요한 건 수행하는 사람의 의지

지금까지 E-Commerce 분야의 테스트 프로세스 개선 사례를 알아봤다. 물론 TMMi와 같은 테스트 프로세스 개선 모델을 이용해 테스트 프로세스를 구축하지도 않았고 다양한 테스트 관련 도구를 도입하지도 않았다.

중요한 것은 우리가 왜 테스트 프로세스 개선을 해야 하는지 고민해야 한다는 것이다. 테스트 프로세스 개선 모델은 테스트 활동을 보다 더 효율적으로 수행할 수 있도록 도와주는 하나의 도구일 뿐이다. 즉 이러한 개선 모델 도입이 중요한 것이 아니라, 과연 우리 조직에 진짜로 도움이 될 수 있는 테스트 활동이 무엇인지 고민하는 것이 더 필요하다. 물론, 기업의 홍보를 위해 공신력 있는 업체에서 인증을 받는다는 목적을 가지고 있다면, 반드시 테스트 프로세스 개선모델을 적용해야 할 것이다.

많은 사람들은 TMMi, TPI Next와 같은 테스트 프로세스 개선모델을 도입하면 모든 것이 개선될 것이라는 착각을 한다. 하지만, 이러한 활동을 하는 것은 실제 프로젝트를 수행하는 기획자, 개발자, 테스트 엔지니어들이다. 프로젝트를 수행하는 사람들에게 아무런 도움이 되지 않고 업무만 가중되는 것이라면 업무를 수행하는 사람들에게 테스트 프로세스 개선이라는 도구는 도입 후 불필요한 도구가 되어 버릴 뿐이다.