TPI (Test Process Improvement)는 테스팅 프로세스의 개선 로드맵을 제시해 주는 모델이라 할 수 있다. 즉, chaos 상태를 거쳐 어떤 식으로던 안정기를 거친 이후에 고민하는 이슈인 것이다. 이에 대한 글을 번역해 보았다.
-----------------------------------------------------------------------------------------------------
테스팅은 종종 비용이 많이 들고, 제어되지 않는 프로세스인 것처럼 인식된다. 테스팅은 시간이 매우 많이 걸리고, 계획된 것보다 비용이 더 들며, 종종 테스트 프로세스의 품질에 대해서 불충분한 개념을 제공한다. 그러므로, 정보 시스템의 품질과 비즈니스의 리스크를 결정하기 어려워질 수 있다.
많은 조직들은 테스트 프로세스의 개선이 그러한 문제들을 해결할 수 있다고 인식한다. 하지만, 실제 상황에서 프로세스의 제어와 개선을 위해 어떤 단계를 정의해야 하는지, 어떤 순서로 정의해야 하는지 결정하기 어렵다고 판명되고 있다.
TPI (Test Process Improvement) 모델은 테스트 프로세스 개발의 실용적인 지식과 경험을 바탕으로 개발되어져 왔다. TPI는 조직 내부의 테스트 프로세스의 성숙도를 재는 어떤 관점을 제공한다. 이러한 이해를 바탕으로 이 모델은 점진적으로 제어가능한 테스트 프로세스 개선 단계들을 정의하는데 도움을 준다.
이 문서에서 TPI 모델의 구조와 내용이 소개된다. 또한 테스트 프로세스 개선과 그 도전과제들의 일반적인 측면들이 논의된다.
ACM Computing Classification System (CCS): D.2.4, D.2.5, K.6.3
Keywords: test process improvement, test process maturity, test maturity matrix
CONTENTS
1 INTRODUCTION
2 PURPOSE OF TESTING
3 TEST LEVELS
3.1 LOW LEVEL TESTS
3.2 HIGH LEVEL TESTS
4 PROBLEMS CONCERNING TESTING
4.1 PRIMITIVE TESTING
4.2 CURRENT STATE OF AFFAIRS
4.3 NEW DEVELOPMENTS
5 IMPROVING THE TEST PROCESS
5.1 THE NEED FOR TEST PROCESS IMPROVEMENT
5.2 TEST PROCESS IMPROVEMENT STEPS
6 THE TPI MODEL
6.1 GENERAL DESCRIPTION OF THE TPI MODEL
6.2 THE TMAP MODEL
6.3. KEY AREAS AND LEVELS
6.4 CHECKPOINTS
6.5 TEST MATURITY MATRIX
6.6 IMPROVEMENT SUGGESTIONS
7 CONCLUSIONS
REFERENCES
1 소개
테스팅은 종종 비용이 많이 들고, 제어되지 않는 프로세스인것처럼 인식된다. 테스팅은 시간이 매우 많이 걸리고, 계획된 것보다 비용이 더 들며, 종종 테스트 프로세스의 품질에 대해서 불충분한 개념을 제공한다. 그러므로, 정보 시스템의 품질과 비즈니스의 리스크를 결정하기 어려워질 수 있다.
많은 조직들은 테스트 프로세스의 개선이 그러한 문제들을 해결할 수 있다고 인식한다. 하지만, 실제로는 프로세스의 제어와 개선을 위해 어떤 단계들을 정의해야 하는지, 어떤 순서로 정의해야 하는지 결정하기 어렵다고 판명되고 있다.
TPI (Test Process Improvement) 모델은 테스트 프로세스 개발의 실용적인 지식과 경험을 바탕으로 개발되어져 왔다. TPI는 조직 내부의 테스트 프로세스의 성숙도를 재는 어떤 관점을 제공한다. 이러한 이해를 바탕으로 이 모델은 세분화되고 제어가능한 테스트 프로세스 개선 단계들을 정의하는데 도움을 준다 [Sog04].
이 세미나 자료의 목적은 TPI 모델의 구조와 내용을 기술하고 보이는 것이다. 이 세미나 자료는 다음의 순서로 구성되었다. 2장과 3장은 테스트 레벨의 서로 다른 측면과 테스팅에 대한 개관을 보이고, 4장은 테스팅과 테스팅 프로세스에 관한 일반적인 문제들을 논의한다. 5장은 테스트 프로세스 개선의 서로 다른 단계들을 서술한다. 6장은 TPI 모델을 설명한다. 마지막으로, 7장에서는 이 문서를 요약한다.
2 테스팅의 목적
정보 시스템의 개발에서 테스팅 활동은 다음과 같이 정의된다 [TMa04]:
테스팅은 정보 시스템의 특징들을 목표로 하여 계획, 준비, 실행, 분석하고, 정보 시스템의 특성을 확립하는 것을 목표로 하며, 요구되는 상태와 실제 상태 간의 차이를 증명하는 프로세스이다.
테스트 계획과 준비 활동들은 테스팅이 그 테스트되는 대상이 전달될 때 시작되는 프로세스로 간주되어서는 안 된다는 사실을 강조한다. 하나의 테스트 프로세스는 어떤 측정활동이 수행되기 전에 정확하게 계획하고 준비하는 단계들을 필요로한다 [KoP99].
테스팅은 한 시스템의 품질에 대한 불확실성 레벨을 감소시킨다. 테스팅 활동의 레벨은 이 시스템이 동작하면서 가져오는 내재된 리스크에 따라 달라진다. 그리고, 얼마나 (테스팅에) 많은 시간과 비용을 들여야 하는지에 대한 결정은 불확실성의 레벨을 감소시키는데 사용된다 [KoP99].
3 테스트 레벨
테스트를 효과적으로 조직화하기 위해, 서로 다른 테스트 레벨들이 사용되어야 한다. 각 테스트 레벨은 다수의 요구사항 그룹 또는 기능적 또는 기술적인 명세들을 처리한다. 이 장의 내용은 주로 [KoP99]와 [ISE04]를 근간으로 한다.
3.1 로우 레벨 테스트
로우 레벨 테스트에는 예를 들면, 프로그램 같은 한 시스템의 독립된 컴포넌트들에 대한 개별적이거나 조합적인 테스팅이 포함된다. 시스템 개발의 시작부터 유닛, 프로그램, 모듈 테스트가 실행된다. 위에 언급된 개념들 간의 분리는 사용되는 프로그램 언어와 구조에 종속적이다. 이러한 테스트들은 대개 개발자에 의해 실행된다.
기술적인 명세를 충족해야 하는 해당 시스템의 가장 기초적인 파트들이 결정되고 나면, 시스템의 큰 파트들이 통합 테스트에서 테스트된다. 이때 초점은 시스템 파트 레벨에서 프로그램들 간의 인터페이스와 데이터 처리에 있다.
3.2 하이 레벨 테스트
하이 레벨 테스트는 전체로서의 완전한 제품 단위로 테스팅하는 것이 포함된다 [Kit95]. 로우 레벨 테스트가 실행되고 발견된 결함들이 수정된 후, 시스템이 기능적이고 기술적인 명세를 충족하는지 결정하기 위해 시스템 테스트가 수행된다.
시스템 테스트가 완성된 이후에, 그 시스템은 인수 (acceptance)를 위해 고객에게 제공된다. 인수 테스트의 실행은 실제 환경을 대표할 수 있는 환경을 요구한다.
특히 하이 레벨 테스트들은 개별화된 프로세스로 간주되어야 한다. 지난 경험은 훌륭한 테스트 프로세스 디자인이 로우 레벨 테스트 단계보다 하이 레벨 테스트 단계에서 더 중요하다는 것을 보여준다.
4 테스팅과 관련된 문제들
이 장은 일반적으로 테스트 프로세스 개선에 필요하며, 테스팅과 관련된 포괄적인 문제들을 지적한다. 이 장의 내용은 주로 [KoP99]에 바탕을 두고 있다.
4.1 원시적인 테스팅
테스팅의 원시적인 형태는 시스템이 현장 배치 단계에 들어가기 전에 짧게 테스팅이 시작되며, 누군가 가용한 사람이 수행하는 활동을 의미한다. 대개 이 활동은 시스템이 (현업에) 배치되거나 최근까지 아무런 새로운 결점이 발견되지 않은 경우에 중단된다. 결과적으로 이 시스템은 비싼 비용과 재작업 그리고 재테스팅을 초래하는 몇몇 결점들을 여전히 안고 있는채로 받아들여 진다.
4.2 Current state of affairs (현재의 상태)
잘 관리되어진 테스트 프로세스의 중요성을 인식하는 것은 오늘날 많은 조직에서 점점더 일반화되어 가고 있다. 테스트는 실행하기 전에 계획되고 준비되어야 하며, 명세에 기반하여야 한다. 조직 내부에도 어떤 것이 테스트되고 어떤 것이 테스트되지 않아도 되는지에 대한 통찰력이 존재한다. 하지만, 테스팅에는 여전히 시간, 인력, 리소스, 전문가가 부족하다. 테스팅은 개발 사이클의 개발 후반부 싸이클에 포함되고 종종 값비싼 재작업과 재테스트를 이끌어낸다. 테스트가 중단되는 경우, 여전히 그 시스템이 어떤 품질 수준인지는 명확하지 않다.
4.3 신규 개발
현재 시장 환경에서의 경쟁을 따라잡기 위해서 조직들은 신규 제품에 대한 출시 시간을 계속적으로 줄여나가야 한다. 비록 개발 프로세스가 더 빨라져도, 특정 기간 동안에 만들어진 에러의 수가 감소한다는 아무런 증거가 없다. 경험 부족, 기술적 복잡성의 증가가 이러한 상황을 정당화한다. 심지어 테스트 프로세스가 현재의 상황을 이성적으로 만족시키는 것처럼 보여도, 미래에는 이것이 적용되지 않을 것임이 명백하다.
5 테스트 프로세스의 개선
5.1 테스트 프로세스 개선의 필요성
윗 장에서 언급한 문제의 근원적인 이유는 제어되지 않거나 약점있게 조직화된 테스트 프로세스에 있다. 테스트 프로세스 개선의 필요성이 있다. Koomen과 Pol [KoP99]에 따르면, 테스트 프로세스 개선의 개념은 다음과 같이 정의된다:
전체적인 정보 서비스와 관련되어 테스트 프로세스의 품질, 비용 그리고 준비 시간 (lead time)을 최적화하는 것.
여기서의 품질은 테스트되는 대상의 품질과 관련되어 테스트 프로세스에 의해 얻어진 통찰력의 수준을 의미한다. 시스템이나 프로그램의 품질은 이 정의의 일부분이 아니다. 질적으로 향상된 테스트 프로세스의 자연적인 결과는 테스트되는 시스템의 품질보다 낫지 않다. 테스팅 그 자체는 시스템에 품질을 높여줄 수 없다. (Testing itself does not add quality to the system.) 사실상 테스팅은 가능한 품질을 결정하고, 이러한 정보를 전달하여 다른 이들이 품질을 개선하도록 한다.
전체 정보 서비스와 관련하여 그 테스트 프로세스가 나타내는 것은 그 자신이 아니다. 더 값싸고 더 효율적인 테스팅은 그 자체로 목적이 되지 않아야 한다. 테스팅은 전체 정보 서비스의 더 나은 성능에 기여해야 한다.
개선된 테스트 프로세스의 목적은 수정 비용을 최소화하기 위해서 그 문제의 근원에 가능한 한 가깝도록 그리고 가능한 한 초기에 시스템의 품질에 대한 정보를 전달할 수 있도록 결함을 발견하는 것이다. 전체 평가와 테스트 레벨들은 가능한 한 초기에 가장 중요한 결함들을 발견하고 전체 전략의 최적화를 달성하기 위해 서로 간에 신중하게 조정되어야 한다 [KoP99].
테스팅은 테스트 매니저, 방법론 전문가, 테스팅 엔지니어 등의 역할이 가진 특별한 테스팅 스킬을 요구하는 전문화된 작업이되어야 한다. 전체 테스트 프로세스의 품질과 진행은 측량되어야 하고, 그 결과는 더 나은 테스트 프로세스 개선을 위한 입력으로 사용되어야 한다 [KoP99].
5.2 테스트 프로세스 개선 단계들
테스트 프로세스의 개선은 다른 프로세스의 개선과 비교될 수 있다. 테스트 프로세스 개선에서 대개 다음의 단계들이 사용된다 [KoP99]:
1. 목표와 고려 대상을 결정한다. 테스팅의 품질 특성들이 결정된다. 즉, 테스팅을 더 빠르게, 더 싸게 또는 더 높은 커버리지를 달성하도록 목표를 잡을 것인가? 어떤 테스트 프로세스들이 가장 개선 필요가 있나, 개선 프로세스가 얼마나 오랫동안 지속되어야 하나, 얼마만큼의 노력을 들여야 하나?
2. 현재 상황을 파악한다. 현재 상황의 강점과 약점을 결정한다.
3. 필요한 상황을 파악한다. 현재 상태에 대한 분석과 개선 목표를 바탕으로, 요구되는 상황과 필요한 액션을 결정한다.
4. 변경 액션을 시행한다. 제안된 개선 활동들이 계획에 맞추어 시행되고, 상황 체크가 목표를 달성했는지를 확인하기 위해 시행된다.
참고하는 모델과 테스트 프로세스를 비교함으로써, 테스트 프로세스의 강점과 약점이 더 명확해 진다. 참조의 모델은 테스트 방법론이나 테스트 프로세스 개선을 위한 모델이 될 수 있다.
Koomen과 Pol [KoP99]에 따르면, 일반적인 소프트웨어 프로세스 개선 모델은 (예를 들면, SPICE나 CMM) 테스트 프로세스의 단계적인 개선을 위한 참조가 되기에 불충분하다고 한다. 추상화의 수준이 높기 때문에, 테스트 프로세스의 개선은 종종 하나의 단계로 처리된다.
또한, TMM (Testability Maturity Model), TIM (Test Improvement Model), TMM (Testing Maturity Model)은 같은 몇몇 모델들은 특히 테스트 프로세스 개선을 위해 디자인 되었다. 하지만, 실용적인 개선 단계를 충분히 담고 있지 못하며, 상세하지도, 지시적이지도 않다.
6 TPI 모델
이 장에서 TPI 모델이 설명된다. 이 장의 내용은 [KoP99], [Sog04] 그리고 [TMa04]에 바탕을 두고 있다.
6.1 TPI 모델의 일반적인 설명
테스트 프로세스 개선 모델은 서로 다른 관점으로 부터 테스트 프로세스를 관찰하여야 한다. 예를 들어, 테스트 툴의 사용, 테스트 명세화 기법 그리고 리포팅 같은 것들이다. 모든 핵심영역은 성숙도 수준으로 세분화될 수 있다. TPI 모델에서 이것들은 핵심영역이라 불리운다. 모든 핵심 영역은 전체 테스트 프로세스의 성능에 관해서 동등하게 중요성을 가지지는 않으며, 서로 다른 핵심 영역들과 수준 간에 일정한 의존관계가 존재한다. 그러므로 테스트 성숙도 매트릭스가 사용된다.
수준별로 분류되었는지 객관적으로 확인하기 위해, 하나 또는 그 이상의 체크 포인트들이 각 레벨마다 할당된다. 그 체크 포인트는 요구사항에 해당한다. 만일 한 테스트 프로세스가 특정 수준의 모든 체크 포인트들을 통과했다면, 그 프로세스는 그 수준으로 분류된다.
테스트 프로세스의 현재 상태를 매핑시키는 것외에 핵심 영역들과 수준들 또한 이 상황으로 가는 중간 단계와 필요 상황을 정의하는데 사용될 수 있다. 그 모델에 포함되어진 개선 제안의 부가적인 도움은 특정 성숙도 레벨에 도달하기 위해서 필요한 제안과 지시를 제공한다.
TPI 모델의 주요 개념은 그림 1과 같이 형상화된다.
그림 1. TPI 모델 [Sog04]
TPI 모델은 경험에서 도출되었고, 현재 테스트 프로세스의 강점과 약점을 결정하는 참조의 틀을 제공한다. 그리고, 이 테스트 프로세스에 대한 현실적이고 구체적인 개선 액션을 도출해낸다.
6.2 TMap 모델
TMap [TMap04]은 5.2장에서 언급한 모델에서 도출된 몇몇 측면들 뿐 아니라 구조적인 테스팅을 위한 방법론으로 TPI 모델의 근간으로 쓰인다. TMap 방법론은 4개의 기초로 이루어져 있는데, 이러한 기초들은 개발 싸이클과 연관된 테스트 활동의 라이프 싸이클 (L), 좋은 조직 (O), 올바른 인프라와 도구 (I), 활동을 가속화하기 위한 적절한 기법 (T)이다.
이러한 기초들은 전체에 영향을 주며, 각 테스트 프로세스 안에서 각 기초들에 어느 정도의 주의를 기울여야 한다. 균형잡힌 테스트 프로세스를 위해서, 이 기초들의 개발은 균형을 맞추어야 한다.
6.3. 핵심 영역과 수준
구조적인 테스트 프로세스 하에서 각 기초의 서로 다른 측면을 살펴봄으로써, 20개의 핵심 영역 전체가 TPI 모델로 인식될 수 있다. 이러한 핵심 영역들은 전체 테스트 프로세스를 커버한다.
하나의 테스트 프로세스 내에 핵심 영역들이 조직화되는 방식은 그 프로세스의 성숙도를 결정한다. 하지만, 각 핵심 영역은 동일하게 다루어지지 않을 것이다. 즉, 각 테스트 프로세스는 고유의 강점과 약점을 가지고 있다.
핵심 영역의 상태에 대한 통찰력을 가지기 위해서, 그 모델은 점차 상승하는 수준을 제공한다 (대개는 A 부터 D). 평균적으로, 각 핵심 영역에 대해서 3~4개의 수준이 존재한다. 각각의 상위 수준은 그 이전 수준보다 시간 (더 빠르고), 비용 (더 값싸고), 품질 (더 나은) 형태를 보인다.
각 수준은 각 핵심 영역에 대한 어떤 정도의 요구사항으로 구성된다. 또한 이 특정 수준의 요구사항은 (즉, 체크포인트) 하위 수준의 요구사항으로 구성된다. 예를 들어, 레벨 B의 테스트 프로세스는 레벨 A와 B 양쪽의 요구사항을 만족한다. 만일 테스트 프로세스가 레벨 A의 요구사항을 충족하지 못한다면, 가장 낮은 수준으로 간주되고, 특정 핵심 영역의 해당 수준으로 정의되지 않는다.
핵심 영역의 서로 다른 영역의 설명은 테이블 1에서 찾을 수 있다.
테이블 1 기초들을 포함하는 서로 다른 핵심 영역의 수준 [KoP99]
예를 들어, 그 테스트 프로세스는 발견된 결함과 사용한 시간에 대한 개요를 담아 주단위로 리포트한다. 그 결함에 우선순위가 정의되어 있지 않고, 테스트 진행이 리포트에 언급되어 있지 않다면, 그 프로세스는 레벨 A의 리포팅 핵심 영역으로 분류된다.
6.4 체크포인트
체크포인트에 근거해서 테스트 프로세스가 평가된다. 그리고, 각 핵심 영역에 대해서 적절한 수준이 정의된다. 핵심 영역 각각의 다음 수준은 개선과 일치한다. 또한 그 체크포인트들은 누적식이다. 즉, 레벨 B로 분류되려면 그 테스트 프로세스는 레벨 B와 레벨 A 양쪽의 체크포인트에 대해서 긍정적으로 답변되어야 한다.
예: 테스트 툴 핵심 영역에 대한 체크포인트
계획과 제어 툴 (레벨 A)
체크포인트:
* 자동화된 툴 (표준적인 워드 프로세싱 이상의)이 결함 관리를 위해 사용되며, 최소한 계획과 제어 2가지 활동에 사용된다.
실행과 분석 툴 (레벨 B)
체크포인트:
* 최소한 2개 종류의 자동화 툴이 테스트 실행에 사용된다. 예를 들면, 캡쳐 & 플레이백 툴, 테스트 커버리지 툴 등이다.
확장적인 테스트 프로세스의 자동화 (레벨 C)
체크포인트:
* 자동화된 툴 (표준적인 워드 프로세싱 이상의)이 계획 단계를 위해 사용되며 (추정, 계획, 진행 모니터링, 구성 관리와 결함 관리), 준비, 명세화 그리고 실행 (전체적으로 최소한 5가지 종류의 툴이 사용되어야 한다)에 사용된다.
* 테스트 팀은 이러한 툴들의 비용 대비 수익 비율에 대한 통찰력을 가지고 있다.
6.5 테스트 성숙도 매트릭스
각 핵심 영역에 대한 수준을 결정한 이후에 어떤 개선 단계들을 취할 것인지에 대해서 심사숙고해야 한다. 왜냐하면, 모든 핵심 영역들과 수준들이 동일하게 중요하지는 않기 때문이다. 예를 들어, 좋은 테스트 전략 (테스트 전략 핵심 영역의 레벨 A)는 테스트 방법론의 사용 (방법론 핵심 영역의 레벨 A)보다 중요하다.
이러한 우선순위와 더불어 서로 다른 핵심 영역들의 수준들 간에 의존관계가 있다. 예를 들어, 발견된 결함 (메트릭 핵심 영역의 레벨 A)에 대해 통계가 수집되기 전에, 테스트 프로세스는 결함 관리 핵심 영역의 레벨 B로 분류되어야 한다. 의존 관계의 일치는 많은 수준들과 핵심 영역들 간에서 발견된다.
그러므로, 수준들과 핵심 영역들은 하나의 테스트 성숙도 매트릭스 내에서 상호간에 관계가 있다. 매트릭스의 수직 축은 핵심 영역을 나타내고, 수평 축은 성숙도의 단계를 나타낸다. 매트릭스에서 각 레벨은 테스트 성숙도의 어떤 단계와 연결된다. 이것은 테스트 성숙도의 13단계를 의미한다. 서로 다른 수준들간에 빈 공간은 그 스스로는 아무런 의미가 없다. 하지만, 하나의 핵심 영역에 대해 더 높은 성숙도 수준을 달성하는 것은 다른 핵심 영역들의 수준과 연관됨을 의미한다. 서로 다른 수준들간에는 등급이 존재하지 않는다. 테스트 프로세스가 레벨 B를 전체적으로 충족하지 못한다면, 레벨 A에 머무르게 된다.
테이블 2에서 테스트 성숙도 매트릭스의 구조를 설명한다.
테이블 2 테스트 성숙도 매트릭스 [Sog04]
대개 테스트 성숙도의 단계는 3가지 카테고리로 나누어진다:
제어됨. 1에서 5단계는 주로 테스트 프로세스의 제어와 관련된다. 테스트 프로세스는 사전에 정의된 전략에 맞추어 단계별로 실행된다. 테스트 명세 기법이 테스팅에 사용되며, 결함은 기록되고 리포트된다. 테스트웨어와 테스트 환경은 잘 제어되며, 테스트 인력은 충분히 훈련되었다.
효율적임. 6에서 10단계는 테스트 프로세스를 더 효율적으로 하는데 목적이 있다. 효율성은 예를 들면, 테스트 프로세스의 자동화, 상호간의 테스트 프로세스 간의 더 나은 통합, 시스템 개발팀 내의 다른 인력과의 더 나은 통합을 통해 달성될 수 있다.
최적화됨. 현재 상황에서 효율적인 테스트 프로세스는 미래에고 효율적이지는 않을 것이다. 11에서 13단계는 테스트 프로세스의 최적화를 달성하고, 테스트 프로세스의 지속적인 개선이 조직의 작업 방식에 일부분이 될 것인지에 집중한다.
이 매트릭스의 주요 목적은 현재 테스트 프로세스의 강점과 약점을 보이고, 개선을 위해 제안이나 액션을 우선순위화 하는것을 지원하는 것이다. 테스트 프로세스의 현재 상태는 명확하게 보여질 수 있다. 이 매트릭스가 왼쪽에서 오른쪽으로 사용되면, 낮은 성숙도의 핵심 영역이 먼저 개선되는 것이다.
테이블 3의 예제에서, 테스트 프로세스는 테스트 전략 (레벨이 A보다 낮다)의 핵심 영역의 가장 낮은 레벨에도 미치지 못한다. 이 조직은 라이프 싸이클 모델 (레벨 A)에 따라 작업하고 있고, 테스터들은 명세가 완료된 직후에 작업에 참여한다 (레벨 A).
Table 3 현재 상태 [Sog04]
이러한 레벨에 기초하여, 개선은 논의되어야 한다. 예를 들어, 선택은 고수준 테스트 (레벨 B로의)와 라이프 싸이클 모델 (역시 레벨 B로의)의 테스트 전략을 결합해서 내려진다. 더 초기에 작업에 참여하는 것은 이 시점에서 필요한 것은 아니라고 결론지었다. 요구되는 상황은 테이블 4에 표시했다.
Table 4 요구되는 상황 [Sog04]
6.6 개선 제안
개선 액션들은 달성을 기대하는 더 높은 수준의 형태로 정의할 수 있다. 더 높은 수준의 달성을 위해 체크포인트가 상당한 도움이 된다. 추가적으로, TPI 모델은 테스트 프로세스 개선에 대한 개선 제안들을 포함하고 있다. 이것은 또 다른 형태의 힌트와 아이디어이며, 테스트 성숙도의 특정 수준을 달성하는데 도움이 될 것이다.
예: 개선 제안
테스트 전략 핵심 영역의 레벨 A에서 하나의 고수준 테스트를 위한 테스트 전략.
개선 제안:
* 테스트 전략을 결정하는데 엔드 유저, 시스템 관리자, 프로젝트 관리자 같은 다양한 관심 인력을 포함시킨다.
* 현재 작업 방식의 리스크를 지적하거나 어떤 테스팅이 더 값싸고 빠른지를 지시하여 인식을 고양시킨다.
체크포인트의 사용과는 달리, 개선 제안은 강제적이지 않다. 하지만, 각 수준은 다수의 개선 제안들을 가지고 지원될 수 있다.
7 결론
현재 소프트웨어 개발은 빠른 속도로 진행되고 있다. 소프트웨어 개발 프로세스의 생산성은 지속적으로 증가하고 있으며, 고객에 의해 어느 때보다 더 높은 품질을 요구받고 있다. 현재에는 만족스러운 것으로 보이는 테스트 프로세스가 미래에는 개선이 필요한 것으로 인식될 가능성이 매우 농후하다.
TPI 모델은 현재 테스트 프로세스의 상황을 분류하는 객관적인 절차를 제공한다. 추가적으로, 이 모델은 핵심 영역, 수준 그리고 개선 제안의 형태로 테스트 프로세스의 개선을 지원한다. 개선은 우선순위에 근거한 제어되고 있는 개선 단계들을 사용해서 달성된다.
TPI 모델은 실용성에 기반을 두고, 구조적인 테스트 방법론을 따른다. TPI는 객관적인 것으로 간주된다. 체크포인트에 의해서 해당 테스트 프로세스가 현재 위치하고 있는 핵심 영역의 수준이 결정된다. 서로 다른 성숙도 수준과 핵심 영역들, 그리고 그 의존 관계들은 테스트 성숙도 매트릭스에서 표현된다. 또한, 개선 제안은 개선 액션에도 사용된다.
하지만, TPI 모델의 사용이 자동적으로 현재 상황과 필요 상황 그리고, 개선된 테스트 프로세스에 대해 자동적으로 올바른 분석을 해주는 것은 아니라는 사실을 명심해야 한다. 이 모델은 테스트 프로세스의 구조적인 개선에 대한 툴, 그리고 조직 내의 더 나은 의사소통을 위한 툴로써 간주되어야 한다. 이 모델이 사용되는 것과 상관없이, 테스트 프로세스의 개선에는 참여한 사람들의 높은 수준의 지식과 전문성을 요구된다.
참고문헌
ISE04 ISEB Foundation Certificate in Software Testing course material, Grove Consultants, Kista, Sweden, 2004
Kit95 Kit, E., Software Testing in the Real World: Improving the Process. ACM Press, Essex, England, 1995
KoP99 Koomen, T. and Pol M., Test Process Improvement: A practical step-bystep guide to structured testing. ACM Press, London, England, 1999
Sog04 TPI home pages, Sogeti Nederland B.V., 2004. http://www.sogeti.nl/index.html?/iospagina.cfm?uNr=150 [27.9.2004]
TMa04 TMap home pages, TMap - Sogeti Nederland B.V., 2004, http://www.tmap.net [4.10.2004]
-----------------------------------------------------------------------------------------------------
테스팅은 종종 비용이 많이 들고, 제어되지 않는 프로세스인 것처럼 인식된다. 테스팅은 시간이 매우 많이 걸리고, 계획된 것보다 비용이 더 들며, 종종 테스트 프로세스의 품질에 대해서 불충분한 개념을 제공한다. 그러므로, 정보 시스템의 품질과 비즈니스의 리스크를 결정하기 어려워질 수 있다.
많은 조직들은 테스트 프로세스의 개선이 그러한 문제들을 해결할 수 있다고 인식한다. 하지만, 실제 상황에서 프로세스의 제어와 개선을 위해 어떤 단계를 정의해야 하는지, 어떤 순서로 정의해야 하는지 결정하기 어렵다고 판명되고 있다.
TPI (Test Process Improvement) 모델은 테스트 프로세스 개발의 실용적인 지식과 경험을 바탕으로 개발되어져 왔다. TPI는 조직 내부의 테스트 프로세스의 성숙도를 재는 어떤 관점을 제공한다. 이러한 이해를 바탕으로 이 모델은 점진적으로 제어가능한 테스트 프로세스 개선 단계들을 정의하는데 도움을 준다.
이 문서에서 TPI 모델의 구조와 내용이 소개된다. 또한 테스트 프로세스 개선과 그 도전과제들의 일반적인 측면들이 논의된다.
ACM Computing Classification System (CCS): D.2.4, D.2.5, K.6.3
Keywords: test process improvement, test process maturity, test maturity matrix
CONTENTS
1 INTRODUCTION
2 PURPOSE OF TESTING
3 TEST LEVELS
3.1 LOW LEVEL TESTS
3.2 HIGH LEVEL TESTS
4 PROBLEMS CONCERNING TESTING
4.1 PRIMITIVE TESTING
4.2 CURRENT STATE OF AFFAIRS
4.3 NEW DEVELOPMENTS
5 IMPROVING THE TEST PROCESS
5.1 THE NEED FOR TEST PROCESS IMPROVEMENT
5.2 TEST PROCESS IMPROVEMENT STEPS
6 THE TPI MODEL
6.1 GENERAL DESCRIPTION OF THE TPI MODEL
6.2 THE TMAP MODEL
6.3. KEY AREAS AND LEVELS
6.4 CHECKPOINTS
6.5 TEST MATURITY MATRIX
6.6 IMPROVEMENT SUGGESTIONS
7 CONCLUSIONS
REFERENCES
1 소개
테스팅은 종종 비용이 많이 들고, 제어되지 않는 프로세스인것처럼 인식된다. 테스팅은 시간이 매우 많이 걸리고, 계획된 것보다 비용이 더 들며, 종종 테스트 프로세스의 품질에 대해서 불충분한 개념을 제공한다. 그러므로, 정보 시스템의 품질과 비즈니스의 리스크를 결정하기 어려워질 수 있다.
많은 조직들은 테스트 프로세스의 개선이 그러한 문제들을 해결할 수 있다고 인식한다. 하지만, 실제로는 프로세스의 제어와 개선을 위해 어떤 단계들을 정의해야 하는지, 어떤 순서로 정의해야 하는지 결정하기 어렵다고 판명되고 있다.
TPI (Test Process Improvement) 모델은 테스트 프로세스 개발의 실용적인 지식과 경험을 바탕으로 개발되어져 왔다. TPI는 조직 내부의 테스트 프로세스의 성숙도를 재는 어떤 관점을 제공한다. 이러한 이해를 바탕으로 이 모델은 세분화되고 제어가능한 테스트 프로세스 개선 단계들을 정의하는데 도움을 준다 [Sog04].
이 세미나 자료의 목적은 TPI 모델의 구조와 내용을 기술하고 보이는 것이다. 이 세미나 자료는 다음의 순서로 구성되었다. 2장과 3장은 테스트 레벨의 서로 다른 측면과 테스팅에 대한 개관을 보이고, 4장은 테스팅과 테스팅 프로세스에 관한 일반적인 문제들을 논의한다. 5장은 테스트 프로세스 개선의 서로 다른 단계들을 서술한다. 6장은 TPI 모델을 설명한다. 마지막으로, 7장에서는 이 문서를 요약한다.
2 테스팅의 목적
정보 시스템의 개발에서 테스팅 활동은 다음과 같이 정의된다 [TMa04]:
테스팅은 정보 시스템의 특징들을 목표로 하여 계획, 준비, 실행, 분석하고, 정보 시스템의 특성을 확립하는 것을 목표로 하며, 요구되는 상태와 실제 상태 간의 차이를 증명하는 프로세스이다.
테스트 계획과 준비 활동들은 테스팅이 그 테스트되는 대상이 전달될 때 시작되는 프로세스로 간주되어서는 안 된다는 사실을 강조한다. 하나의 테스트 프로세스는 어떤 측정활동이 수행되기 전에 정확하게 계획하고 준비하는 단계들을 필요로한다 [KoP99].
테스팅은 한 시스템의 품질에 대한 불확실성 레벨을 감소시킨다. 테스팅 활동의 레벨은 이 시스템이 동작하면서 가져오는 내재된 리스크에 따라 달라진다. 그리고, 얼마나 (테스팅에) 많은 시간과 비용을 들여야 하는지에 대한 결정은 불확실성의 레벨을 감소시키는데 사용된다 [KoP99].
3 테스트 레벨
테스트를 효과적으로 조직화하기 위해, 서로 다른 테스트 레벨들이 사용되어야 한다. 각 테스트 레벨은 다수의 요구사항 그룹 또는 기능적 또는 기술적인 명세들을 처리한다. 이 장의 내용은 주로 [KoP99]와 [ISE04]를 근간으로 한다.
3.1 로우 레벨 테스트
로우 레벨 테스트에는 예를 들면, 프로그램 같은 한 시스템의 독립된 컴포넌트들에 대한 개별적이거나 조합적인 테스팅이 포함된다. 시스템 개발의 시작부터 유닛, 프로그램, 모듈 테스트가 실행된다. 위에 언급된 개념들 간의 분리는 사용되는 프로그램 언어와 구조에 종속적이다. 이러한 테스트들은 대개 개발자에 의해 실행된다.
기술적인 명세를 충족해야 하는 해당 시스템의 가장 기초적인 파트들이 결정되고 나면, 시스템의 큰 파트들이 통합 테스트에서 테스트된다. 이때 초점은 시스템 파트 레벨에서 프로그램들 간의 인터페이스와 데이터 처리에 있다.
3.2 하이 레벨 테스트
하이 레벨 테스트는 전체로서의 완전한 제품 단위로 테스팅하는 것이 포함된다 [Kit95]. 로우 레벨 테스트가 실행되고 발견된 결함들이 수정된 후, 시스템이 기능적이고 기술적인 명세를 충족하는지 결정하기 위해 시스템 테스트가 수행된다.
시스템 테스트가 완성된 이후에, 그 시스템은 인수 (acceptance)를 위해 고객에게 제공된다. 인수 테스트의 실행은 실제 환경을 대표할 수 있는 환경을 요구한다.
특히 하이 레벨 테스트들은 개별화된 프로세스로 간주되어야 한다. 지난 경험은 훌륭한 테스트 프로세스 디자인이 로우 레벨 테스트 단계보다 하이 레벨 테스트 단계에서 더 중요하다는 것을 보여준다.
4 테스팅과 관련된 문제들
이 장은 일반적으로 테스트 프로세스 개선에 필요하며, 테스팅과 관련된 포괄적인 문제들을 지적한다. 이 장의 내용은 주로 [KoP99]에 바탕을 두고 있다.
4.1 원시적인 테스팅
테스팅의 원시적인 형태는 시스템이 현장 배치 단계에 들어가기 전에 짧게 테스팅이 시작되며, 누군가 가용한 사람이 수행하는 활동을 의미한다. 대개 이 활동은 시스템이 (현업에) 배치되거나 최근까지 아무런 새로운 결점이 발견되지 않은 경우에 중단된다. 결과적으로 이 시스템은 비싼 비용과 재작업 그리고 재테스팅을 초래하는 몇몇 결점들을 여전히 안고 있는채로 받아들여 진다.
4.2 Current state of affairs (현재의 상태)
잘 관리되어진 테스트 프로세스의 중요성을 인식하는 것은 오늘날 많은 조직에서 점점더 일반화되어 가고 있다. 테스트는 실행하기 전에 계획되고 준비되어야 하며, 명세에 기반하여야 한다. 조직 내부에도 어떤 것이 테스트되고 어떤 것이 테스트되지 않아도 되는지에 대한 통찰력이 존재한다. 하지만, 테스팅에는 여전히 시간, 인력, 리소스, 전문가가 부족하다. 테스팅은 개발 사이클의 개발 후반부 싸이클에 포함되고 종종 값비싼 재작업과 재테스트를 이끌어낸다. 테스트가 중단되는 경우, 여전히 그 시스템이 어떤 품질 수준인지는 명확하지 않다.
4.3 신규 개발
현재 시장 환경에서의 경쟁을 따라잡기 위해서 조직들은 신규 제품에 대한 출시 시간을 계속적으로 줄여나가야 한다. 비록 개발 프로세스가 더 빨라져도, 특정 기간 동안에 만들어진 에러의 수가 감소한다는 아무런 증거가 없다. 경험 부족, 기술적 복잡성의 증가가 이러한 상황을 정당화한다. 심지어 테스트 프로세스가 현재의 상황을 이성적으로 만족시키는 것처럼 보여도, 미래에는 이것이 적용되지 않을 것임이 명백하다.
5 테스트 프로세스의 개선
5.1 테스트 프로세스 개선의 필요성
윗 장에서 언급한 문제의 근원적인 이유는 제어되지 않거나 약점있게 조직화된 테스트 프로세스에 있다. 테스트 프로세스 개선의 필요성이 있다. Koomen과 Pol [KoP99]에 따르면, 테스트 프로세스 개선의 개념은 다음과 같이 정의된다:
전체적인 정보 서비스와 관련되어 테스트 프로세스의 품질, 비용 그리고 준비 시간 (lead time)을 최적화하는 것.
여기서의 품질은 테스트되는 대상의 품질과 관련되어 테스트 프로세스에 의해 얻어진 통찰력의 수준을 의미한다. 시스템이나 프로그램의 품질은 이 정의의 일부분이 아니다. 질적으로 향상된 테스트 프로세스의 자연적인 결과는 테스트되는 시스템의 품질보다 낫지 않다. 테스팅 그 자체는 시스템에 품질을 높여줄 수 없다. (Testing itself does not add quality to the system.) 사실상 테스팅은 가능한 품질을 결정하고, 이러한 정보를 전달하여 다른 이들이 품질을 개선하도록 한다.
전체 정보 서비스와 관련하여 그 테스트 프로세스가 나타내는 것은 그 자신이 아니다. 더 값싸고 더 효율적인 테스팅은 그 자체로 목적이 되지 않아야 한다. 테스팅은 전체 정보 서비스의 더 나은 성능에 기여해야 한다.
개선된 테스트 프로세스의 목적은 수정 비용을 최소화하기 위해서 그 문제의 근원에 가능한 한 가깝도록 그리고 가능한 한 초기에 시스템의 품질에 대한 정보를 전달할 수 있도록 결함을 발견하는 것이다. 전체 평가와 테스트 레벨들은 가능한 한 초기에 가장 중요한 결함들을 발견하고 전체 전략의 최적화를 달성하기 위해 서로 간에 신중하게 조정되어야 한다 [KoP99].
테스팅은 테스트 매니저, 방법론 전문가, 테스팅 엔지니어 등의 역할이 가진 특별한 테스팅 스킬을 요구하는 전문화된 작업이되어야 한다. 전체 테스트 프로세스의 품질과 진행은 측량되어야 하고, 그 결과는 더 나은 테스트 프로세스 개선을 위한 입력으로 사용되어야 한다 [KoP99].
5.2 테스트 프로세스 개선 단계들
테스트 프로세스의 개선은 다른 프로세스의 개선과 비교될 수 있다. 테스트 프로세스 개선에서 대개 다음의 단계들이 사용된다 [KoP99]:
1. 목표와 고려 대상을 결정한다. 테스팅의 품질 특성들이 결정된다. 즉, 테스팅을 더 빠르게, 더 싸게 또는 더 높은 커버리지를 달성하도록 목표를 잡을 것인가? 어떤 테스트 프로세스들이 가장 개선 필요가 있나, 개선 프로세스가 얼마나 오랫동안 지속되어야 하나, 얼마만큼의 노력을 들여야 하나?
2. 현재 상황을 파악한다. 현재 상황의 강점과 약점을 결정한다.
3. 필요한 상황을 파악한다. 현재 상태에 대한 분석과 개선 목표를 바탕으로, 요구되는 상황과 필요한 액션을 결정한다.
4. 변경 액션을 시행한다. 제안된 개선 활동들이 계획에 맞추어 시행되고, 상황 체크가 목표를 달성했는지를 확인하기 위해 시행된다.
참고하는 모델과 테스트 프로세스를 비교함으로써, 테스트 프로세스의 강점과 약점이 더 명확해 진다. 참조의 모델은 테스트 방법론이나 테스트 프로세스 개선을 위한 모델이 될 수 있다.
Koomen과 Pol [KoP99]에 따르면, 일반적인 소프트웨어 프로세스 개선 모델은 (예를 들면, SPICE나 CMM) 테스트 프로세스의 단계적인 개선을 위한 참조가 되기에 불충분하다고 한다. 추상화의 수준이 높기 때문에, 테스트 프로세스의 개선은 종종 하나의 단계로 처리된다.
또한, TMM (Testability Maturity Model), TIM (Test Improvement Model), TMM (Testing Maturity Model)은 같은 몇몇 모델들은 특히 테스트 프로세스 개선을 위해 디자인 되었다. 하지만, 실용적인 개선 단계를 충분히 담고 있지 못하며, 상세하지도, 지시적이지도 않다.
6 TPI 모델
이 장에서 TPI 모델이 설명된다. 이 장의 내용은 [KoP99], [Sog04] 그리고 [TMa04]에 바탕을 두고 있다.
6.1 TPI 모델의 일반적인 설명
테스트 프로세스 개선 모델은 서로 다른 관점으로 부터 테스트 프로세스를 관찰하여야 한다. 예를 들어, 테스트 툴의 사용, 테스트 명세화 기법 그리고 리포팅 같은 것들이다. 모든 핵심영역은 성숙도 수준으로 세분화될 수 있다. TPI 모델에서 이것들은 핵심영역이라 불리운다. 모든 핵심 영역은 전체 테스트 프로세스의 성능에 관해서 동등하게 중요성을 가지지는 않으며, 서로 다른 핵심 영역들과 수준 간에 일정한 의존관계가 존재한다. 그러므로 테스트 성숙도 매트릭스가 사용된다.
수준별로 분류되었는지 객관적으로 확인하기 위해, 하나 또는 그 이상의 체크 포인트들이 각 레벨마다 할당된다. 그 체크 포인트는 요구사항에 해당한다. 만일 한 테스트 프로세스가 특정 수준의 모든 체크 포인트들을 통과했다면, 그 프로세스는 그 수준으로 분류된다.
테스트 프로세스의 현재 상태를 매핑시키는 것외에 핵심 영역들과 수준들 또한 이 상황으로 가는 중간 단계와 필요 상황을 정의하는데 사용될 수 있다. 그 모델에 포함되어진 개선 제안의 부가적인 도움은 특정 성숙도 레벨에 도달하기 위해서 필요한 제안과 지시를 제공한다.
TPI 모델의 주요 개념은 그림 1과 같이 형상화된다.
TPI 모델은 경험에서 도출되었고, 현재 테스트 프로세스의 강점과 약점을 결정하는 참조의 틀을 제공한다. 그리고, 이 테스트 프로세스에 대한 현실적이고 구체적인 개선 액션을 도출해낸다.
6.2 TMap 모델
TMap [TMap04]은 5.2장에서 언급한 모델에서 도출된 몇몇 측면들 뿐 아니라 구조적인 테스팅을 위한 방법론으로 TPI 모델의 근간으로 쓰인다. TMap 방법론은 4개의 기초로 이루어져 있는데, 이러한 기초들은 개발 싸이클과 연관된 테스트 활동의 라이프 싸이클 (L), 좋은 조직 (O), 올바른 인프라와 도구 (I), 활동을 가속화하기 위한 적절한 기법 (T)이다.
이러한 기초들은 전체에 영향을 주며, 각 테스트 프로세스 안에서 각 기초들에 어느 정도의 주의를 기울여야 한다. 균형잡힌 테스트 프로세스를 위해서, 이 기초들의 개발은 균형을 맞추어야 한다.
6.3. 핵심 영역과 수준
구조적인 테스트 프로세스 하에서 각 기초의 서로 다른 측면을 살펴봄으로써, 20개의 핵심 영역 전체가 TPI 모델로 인식될 수 있다. 이러한 핵심 영역들은 전체 테스트 프로세스를 커버한다.
하나의 테스트 프로세스 내에 핵심 영역들이 조직화되는 방식은 그 프로세스의 성숙도를 결정한다. 하지만, 각 핵심 영역은 동일하게 다루어지지 않을 것이다. 즉, 각 테스트 프로세스는 고유의 강점과 약점을 가지고 있다.
핵심 영역의 상태에 대한 통찰력을 가지기 위해서, 그 모델은 점차 상승하는 수준을 제공한다 (대개는 A 부터 D). 평균적으로, 각 핵심 영역에 대해서 3~4개의 수준이 존재한다. 각각의 상위 수준은 그 이전 수준보다 시간 (더 빠르고), 비용 (더 값싸고), 품질 (더 나은) 형태를 보인다.
각 수준은 각 핵심 영역에 대한 어떤 정도의 요구사항으로 구성된다. 또한 이 특정 수준의 요구사항은 (즉, 체크포인트) 하위 수준의 요구사항으로 구성된다. 예를 들어, 레벨 B의 테스트 프로세스는 레벨 A와 B 양쪽의 요구사항을 만족한다. 만일 테스트 프로세스가 레벨 A의 요구사항을 충족하지 못한다면, 가장 낮은 수준으로 간주되고, 특정 핵심 영역의 해당 수준으로 정의되지 않는다.
핵심 영역의 서로 다른 영역의 설명은 테이블 1에서 찾을 수 있다.
테이블 1 기초들을 포함하는 서로 다른 핵심 영역의 수준 [KoP99]
6.4 체크포인트
체크포인트에 근거해서 테스트 프로세스가 평가된다. 그리고, 각 핵심 영역에 대해서 적절한 수준이 정의된다. 핵심 영역 각각의 다음 수준은 개선과 일치한다. 또한 그 체크포인트들은 누적식이다. 즉, 레벨 B로 분류되려면 그 테스트 프로세스는 레벨 B와 레벨 A 양쪽의 체크포인트에 대해서 긍정적으로 답변되어야 한다.
예: 테스트 툴 핵심 영역에 대한 체크포인트
계획과 제어 툴 (레벨 A)
체크포인트:
* 자동화된 툴 (표준적인 워드 프로세싱 이상의)이 결함 관리를 위해 사용되며, 최소한 계획과 제어 2가지 활동에 사용된다.
실행과 분석 툴 (레벨 B)
체크포인트:
* 최소한 2개 종류의 자동화 툴이 테스트 실행에 사용된다. 예를 들면, 캡쳐 & 플레이백 툴, 테스트 커버리지 툴 등이다.
확장적인 테스트 프로세스의 자동화 (레벨 C)
체크포인트:
* 자동화된 툴 (표준적인 워드 프로세싱 이상의)이 계획 단계를 위해 사용되며 (추정, 계획, 진행 모니터링, 구성 관리와 결함 관리), 준비, 명세화 그리고 실행 (전체적으로 최소한 5가지 종류의 툴이 사용되어야 한다)에 사용된다.
* 테스트 팀은 이러한 툴들의 비용 대비 수익 비율에 대한 통찰력을 가지고 있다.
6.5 테스트 성숙도 매트릭스
각 핵심 영역에 대한 수준을 결정한 이후에 어떤 개선 단계들을 취할 것인지에 대해서 심사숙고해야 한다. 왜냐하면, 모든 핵심 영역들과 수준들이 동일하게 중요하지는 않기 때문이다. 예를 들어, 좋은 테스트 전략 (테스트 전략 핵심 영역의 레벨 A)는 테스트 방법론의 사용 (방법론 핵심 영역의 레벨 A)보다 중요하다.
이러한 우선순위와 더불어 서로 다른 핵심 영역들의 수준들 간에 의존관계가 있다. 예를 들어, 발견된 결함 (메트릭 핵심 영역의 레벨 A)에 대해 통계가 수집되기 전에, 테스트 프로세스는 결함 관리 핵심 영역의 레벨 B로 분류되어야 한다. 의존 관계의 일치는 많은 수준들과 핵심 영역들 간에서 발견된다.
그러므로, 수준들과 핵심 영역들은 하나의 테스트 성숙도 매트릭스 내에서 상호간에 관계가 있다. 매트릭스의 수직 축은 핵심 영역을 나타내고, 수평 축은 성숙도의 단계를 나타낸다. 매트릭스에서 각 레벨은 테스트 성숙도의 어떤 단계와 연결된다. 이것은 테스트 성숙도의 13단계를 의미한다. 서로 다른 수준들간에 빈 공간은 그 스스로는 아무런 의미가 없다. 하지만, 하나의 핵심 영역에 대해 더 높은 성숙도 수준을 달성하는 것은 다른 핵심 영역들의 수준과 연관됨을 의미한다. 서로 다른 수준들간에는 등급이 존재하지 않는다. 테스트 프로세스가 레벨 B를 전체적으로 충족하지 못한다면, 레벨 A에 머무르게 된다.
테이블 2에서 테스트 성숙도 매트릭스의 구조를 설명한다.
테이블 2 테스트 성숙도 매트릭스 [Sog04]
제어됨. 1에서 5단계는 주로 테스트 프로세스의 제어와 관련된다. 테스트 프로세스는 사전에 정의된 전략에 맞추어 단계별로 실행된다. 테스트 명세 기법이 테스팅에 사용되며, 결함은 기록되고 리포트된다. 테스트웨어와 테스트 환경은 잘 제어되며, 테스트 인력은 충분히 훈련되었다.
효율적임. 6에서 10단계는 테스트 프로세스를 더 효율적으로 하는데 목적이 있다. 효율성은 예를 들면, 테스트 프로세스의 자동화, 상호간의 테스트 프로세스 간의 더 나은 통합, 시스템 개발팀 내의 다른 인력과의 더 나은 통합을 통해 달성될 수 있다.
최적화됨. 현재 상황에서 효율적인 테스트 프로세스는 미래에고 효율적이지는 않을 것이다. 11에서 13단계는 테스트 프로세스의 최적화를 달성하고, 테스트 프로세스의 지속적인 개선이 조직의 작업 방식에 일부분이 될 것인지에 집중한다.
이 매트릭스의 주요 목적은 현재 테스트 프로세스의 강점과 약점을 보이고, 개선을 위해 제안이나 액션을 우선순위화 하는것을 지원하는 것이다. 테스트 프로세스의 현재 상태는 명확하게 보여질 수 있다. 이 매트릭스가 왼쪽에서 오른쪽으로 사용되면, 낮은 성숙도의 핵심 영역이 먼저 개선되는 것이다.
테이블 3의 예제에서, 테스트 프로세스는 테스트 전략 (레벨이 A보다 낮다)의 핵심 영역의 가장 낮은 레벨에도 미치지 못한다. 이 조직은 라이프 싸이클 모델 (레벨 A)에 따라 작업하고 있고, 테스터들은 명세가 완료된 직후에 작업에 참여한다 (레벨 A).
Table 3 현재 상태 [Sog04]
Table 4 요구되는 상황 [Sog04]
개선 액션들은 달성을 기대하는 더 높은 수준의 형태로 정의할 수 있다. 더 높은 수준의 달성을 위해 체크포인트가 상당한 도움이 된다. 추가적으로, TPI 모델은 테스트 프로세스 개선에 대한 개선 제안들을 포함하고 있다. 이것은 또 다른 형태의 힌트와 아이디어이며, 테스트 성숙도의 특정 수준을 달성하는데 도움이 될 것이다.
예: 개선 제안
테스트 전략 핵심 영역의 레벨 A에서 하나의 고수준 테스트를 위한 테스트 전략.
개선 제안:
* 테스트 전략을 결정하는데 엔드 유저, 시스템 관리자, 프로젝트 관리자 같은 다양한 관심 인력을 포함시킨다.
* 현재 작업 방식의 리스크를 지적하거나 어떤 테스팅이 더 값싸고 빠른지를 지시하여 인식을 고양시킨다.
체크포인트의 사용과는 달리, 개선 제안은 강제적이지 않다. 하지만, 각 수준은 다수의 개선 제안들을 가지고 지원될 수 있다.
7 결론
현재 소프트웨어 개발은 빠른 속도로 진행되고 있다. 소프트웨어 개발 프로세스의 생산성은 지속적으로 증가하고 있으며, 고객에 의해 어느 때보다 더 높은 품질을 요구받고 있다. 현재에는 만족스러운 것으로 보이는 테스트 프로세스가 미래에는 개선이 필요한 것으로 인식될 가능성이 매우 농후하다.
TPI 모델은 현재 테스트 프로세스의 상황을 분류하는 객관적인 절차를 제공한다. 추가적으로, 이 모델은 핵심 영역, 수준 그리고 개선 제안의 형태로 테스트 프로세스의 개선을 지원한다. 개선은 우선순위에 근거한 제어되고 있는 개선 단계들을 사용해서 달성된다.
TPI 모델은 실용성에 기반을 두고, 구조적인 테스트 방법론을 따른다. TPI는 객관적인 것으로 간주된다. 체크포인트에 의해서 해당 테스트 프로세스가 현재 위치하고 있는 핵심 영역의 수준이 결정된다. 서로 다른 성숙도 수준과 핵심 영역들, 그리고 그 의존 관계들은 테스트 성숙도 매트릭스에서 표현된다. 또한, 개선 제안은 개선 액션에도 사용된다.
하지만, TPI 모델의 사용이 자동적으로 현재 상황과 필요 상황 그리고, 개선된 테스트 프로세스에 대해 자동적으로 올바른 분석을 해주는 것은 아니라는 사실을 명심해야 한다. 이 모델은 테스트 프로세스의 구조적인 개선에 대한 툴, 그리고 조직 내의 더 나은 의사소통을 위한 툴로써 간주되어야 한다. 이 모델이 사용되는 것과 상관없이, 테스트 프로세스의 개선에는 참여한 사람들의 높은 수준의 지식과 전문성을 요구된다.
참고문헌
ISE04 ISEB Foundation Certificate in Software Testing course material, Grove Consultants, Kista, Sweden, 2004
Kit95 Kit, E., Software Testing in the Real World: Improving the Process. ACM Press, Essex, England, 1995
KoP99 Koomen, T. and Pol M., Test Process Improvement: A practical step-bystep guide to structured testing. ACM Press, London, England, 1999
Sog04 TPI home pages, Sogeti Nederland B.V., 2004. http://www.sogeti.nl/index.html?/iospagina.cfm?uNr=150 [27.9.2004]
TMa04 TMap home pages, TMap - Sogeti Nederland B.V., 2004, http://www.tmap.net [4.10.2004]
