TestCrunch

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]

이번달에는 http://www.ddj.com/dept/debug/196603549에 기고된 아티클을 번역해 보았다. 전반적으로 애자일 프랙티스에 대해 언급하고 있는데, 역시나 아직 개념 정리가 명확히 되지 않았으므로 또는 역자의 한계로 내용이 조금 어설픈 감이 있다. ^^

12/12, 2006
Agile Testing Strategies

Scott Ambler

스코트가 여기서 보인 바와 같이, 당신 시스템의 품질은 당신이 행한 테스팅 활동의 품질 만큼만 좋아진다.

스코트는 DDJ 선임 기고 편집자이며 수많은 IT 서적의 저자이다. 그는 www.ambysoft.com/ scottAmbler.html에서 연락할 수 있다.

지난 몇개월 전부터 나는 애자일 프로젝트에서의 테스팅에 대해서 우리가 어떻게 해야 하는지 수많은 사람들로 부터 질문을 받아왔다. 애자일 개발자들은 명백하게 "테스트에 중독된" 사람들이다. 이번 기고에서 나는 애자일 소프트웨어 개발 프로젝트에서 사용되는 테스팅에 대한 몇가지 전략을 탐색할 것이다. 경고의 말: 비록 우리가 명백히 이전의 우리 전세대들로 부터 물려받은 일련의 테스팅 방법론을 따르지 않더라도, 나는 이전의 고전 방식에서 몇가지 트릭을 여전히 배울 수 있다고 생각한다.

철학적인 기초를 다지면서 시작해 보자.

* 첫째, 당신은 가능한 한 빨리 테스트를 하기 원할 것인데, 이것은 시간이 지나면서 결함 한 개의 잠재적인 영향력이 기하급수적으로 커지기 때문이다 (이것이 항상 사실은 아니다. 하지만, 신경써야 하는 문제이다.) 사실상, 많은 애자일 개발자들은 테스트 우선 접근법 (test-first approach)을 선호한다.
* 둘째, 당신은 가능한 한 자주, 더 중요한 것들을, 가능한 한 효과적으로 테스트하기 원할 것인데, 이것은 결함을 발견할 가능성을 높이기 위한 것이다. 비록 이러한 짧은 기간의 반복에서 비용이 증가하더라도, 이전의 연구들은 테스팅에 많은 투자를 할 수록 향상된 품질로 인해서 시스템의 TCO(total cost of ownership)가 감소된다는 것을 보여주고 있다.
* 셋째, 당신은 당신의 상황에서 충분한 테스팅을 하고 싶을 것이다. 즉, 상업적인 뱅킹 소프트웨어는 지역내 걸 스카우트의 회원 관리 소프트웨어 보다는 더 테스팅에 많은 투자를 해야한다.
* 네째, 페어 프로그래밍이나 다른 사람과 함께 모델링하는 것 같은 페어 테스팅(pair testing)은 대단히 훌륭한 아이디어이다. 나의 일반적인 철학은 소프트웨어 개발은 수영과 많이 닮아 있다는 것이다. 즉, 홀로 수행하면 극도로 위험하다.

라이프싸이클 전체를 통틀어 테스팅하기

그림 1은 테스팅의 의도를 위한 애자일 라이프싸이클의 고수준 레벨을 보여준다. (상세한 설명은 www.ddj.com/dept/architect/188700850의 "Initiating an Agile Project"에서 찾아보라). 애자일 프로젝트는 우리가 그 프로젝트의 기초를 세우는 단계인 짧은 초기화 단계 (반복 0)를 종종 겪는다. 이후, 진화적인 방식으로 (반복적이거나 점진적인) 그 시스템을 개발하는 제작 단계가 이어진다. 결국 시스템을 선보이는 End Game 단계를 거쳐, 그 시스템을 운영하고 유저를 지원하는 프로덕션 단계로 나아간다. 일련의 부기맨(boogeyman)을 두려워 말라. 초기화 단계는 요구사항 정의 단계가 아니며, End Game 단계는 테스팅 단계가 아니다.

그림 1: 애자일 라이프싸이클 동안의 테스트 활동들


테스팅 활동들은 라이프싸이클 동안에 각기 다르다. 통합 0 단계동안에 당신은 초기 셋업 작업들을 수행한다. 이것에는 외부 "조사" 테스팅 팀이 될 수 있는 사람들을 식별하고, 테스팅 툴을 식별하며 잠재적으로 설치하고, 필요한 경우 사용성 테스팅 랩 같은 희귀한 리소스들의 일정을 잡기 시작하는 것이 포함된다. 만일 당신의 프로젝트에 데드라인이 존재한다면, 그 프로젝트가 End Game에 진입해야 하는 프로젝트의 일정을 확인하기 원할 것이다. 좋은 소식은 제작 반복 기간 동안에 증가된 테스팅이 End Game 동안에 덜 테스팅하도록 만든다는 것을 발견할 것이라는 점이다.

상당한 양의 테스팅이 제작 반복 기간 동안에 발생한다. 기억하라. 애자일 주의자들은 자주 테스트하고, 일찍 테스트하며, 대개 테스트 우선의 개발 방식을 취한다. 이것은 이해관계자의 현재 관심사에 대해서 confirmatory testing을 하는 것으로, 대개는 유닛 레벨에서 마일스톤 단위로 수행된다. 이것은 훌륭한 출발점이다. 하지만, 테스팅 과정 전체를 의미하는 것은 아니다. (이것이 우리가 왜 다수의 통합 레벨에서 위험 기반의 조사식 테스팅을 필요로 하는지에 대한 이유이다.) 스타일에 상관없이, 당신의 진정한 목적은 테스트 하는 것이어야 한다. 테스트를 계획하는 것이 아니다. 그리고, 확실히 어떤 시점에서 희망적으로 테스트를 어떻게 할 것인지를 기술한 문서에 있지 않다. 애자일주의자들은 여전히 계획하고 있고 우리는 여전히 문서를 작성한다. 하지만, 우리의 초점은 실제 테스팅과 같은 높은 가치를 지닌 활동들에 있다.

End Game 동안에 당신은 아마도 그 릴리즈에 대해서 전체 시스템/인수 테스팅을 포함하여 최종 테스팅 활동을 수행하여야 할 것이다. 당신이 그렇게 하도록 미리 정했다면 (의료 소프트웨어 개발과 같은 생명 중시의 환경에서는 일반적이다) 또는 당신의 조직이 그것을 필요로 하는 고객과 서비스 레벨의 협약을 맺었다면 진실이된다. 운좋게도, 당신이 제작 반복 기간 동안에 효과적으로 테스트해왔었다면, 당신의 최종 테스팅 활동들은 직관적이며 빠른 것이 증명될 것이다. 만일 당신이 End Game 기간 동안에 "심각한 테스팅"의 유형을 일부라도 수행하고 있다면, 당신의 팀은 당신이 찾은 결함에 대해서 조치를 취할 시간이 충분치 않기 때문에 곤란을 겪을수도 있다.

제작 반복 기간 동안의 테스팅

애자일 프로젝트에서 대다수의 테스팅은 제작 반복 기간 동안에 발생한다. 당신의 테스팅 활동은 시스템과 마찬가지로 제작 과정을 거치면서 진화한다. 그림 2는 2개의 제작 반복 기간을 묘사하며, 팀에 의해 병렬적으로 수행되는 confirmatory testing과, 이상적으로는 독립적인 테스트 팀에 의해 수행되는 investigative testing 활동을 나타낸다. (나는 테스팅 커뮤니티 내에서 사상적 리더인 Michael Bolton으로 부터 "confirmatory"와 "investigative" 테스팅의 개념을 가져왔다.) 비록 작은 프로젝트의 경우 독립적인 테스트 팀이 항상 가용한 것은 아니지만, 적극적으로 추천된다. Confirmatory testing은 이해관계자들이 최근까지 정의한 대로 시스템이 충족하는지 확인하는데 집중한다. 반면에 investigative testing은 개발팀이 고려하지 못한 문제들을 발견하는데 집중한다.

그림 2: 애자일 개발 라이프싸이클 동안의 점진적인 테스팅


두가지 측면의 confirmatory testing이 있다. 애자일 인수 테스팅과 개발자 테스팅이 그것인데, 이 두개 모두 라이프싸이클 동안에 지속적인 리그레션 테스팅을 할 수 있도록 자동화된다. Confirmatory testing은 애자일에서 스펙에 대한 테스팅과 같은 것이다. 사실상, 우리는 요구사항 명세의 주요 부분이 작동하도록 인수테스트를 고려하고, 우리 개발자 테스트는 디자인 스펙의 주요 부분들이 작동하도록 고려한다. 이 두 가지 개념 모두는 가능할 때마다 하나의 근원적인 정보인 애자일 프랙티스에 적용된다. (?)

애자일 인수 테스팅은 전통적인 기능 테스팅과 전통적인 인수 테스팅을 혼합한 것인데, 개발팀과 그 이해관계자들이 집합적으로 작업 하기 때문이다. 개발자 테스팅은 전통적인 유닛 테스팅과 전통적인 클래스/컴포넌트/서비스 통합 테스팅의 혼합이다. 개발자 테스팅은 어플리케이션 코드와 데이터베이스 스키마 양쪽을 (자세한 정보는 www.ddj.com/architect에서 나의 기고 "Ensuring Database Quality"를 찾아보라) 확인하려고 노력한다. 당신의 목표는 코딩 에러를 찾고, 전체 패스(path) 테스팅이 불가한 경우 최소한의 커버리지를 수행하고, 시스템이 그 이해관계자들의 의도를 만족하는지 확인하는 것이다. 개발자 테스팅은 종종 하나의 테스트가 작성되고 충분한 제품 코드가 그 테스트를 충족하기 위해서 작성되는 테스트 우선적인 방식으로 수행된다 (상세 내용은 www.agiledata.org/essays/ tdd.html을 보라). 흥미롭게도, 이러한 테스트 우선 접근법은 상세 디자인 활동이 먼저이고 테스팅 활동은 그 다음인 것으로 고려된다.

자동화는 진화적인 프로젝트 상에서 리그레션 테스팅에 대한 필요가 계속 증가하기 때문에 제작 테스팅의 관점에서 중요하다. 맞춤 테스팅 프레임워크 (www.fitnesse.org) 는 아마도 요구사항 문서 툴일 텐데, 종종 애자일 인수 테스트를 자동화하는데 사용된다. 또한 유즈케이스와 시나리오 정의 또는 UML 액티비티 다이어그램이나 플로우 차트와 같은 프로세스 다이어그램으로 부터 인수 테스트 케이스를 생성할 수도 있으며, 툴은 정확하게 이것을 하기위한 시작점이 된다. Java를 위한 JUnit (www.junit.org)과 비주얼 베이직을 위한 VBUnit (www.vbunit.org) 같은, XUnit 프레임워크는 개발자 테스트를 자동화하는데 사용된다. HP의 Mercury's TestDirector (www.mercury.com/us/products/quality-center/testdirector) 또는 IBM의 Rational's TestManager (www-128.ibm.com/developerworks/rational/ products/testmanager)는 종종 오픈 소스의 대체물들보다 더 세련된 것으로 입증되었기에 고려하기 좋은 옵션들이다. FindBugs (findbugs.sourceforge.net) 같은 정적 코드 분석 툴은 가끔 소스 코드 내의 잠재적인 품질 문제를 확인하는데 도움을 주기 위해 실행되는 자동화 테스팅(툴)에 해당된다.

조사식 테스팅 (Investigative Testing)

내가 이 컬럼을 작성하고 있었을 때, 운좋게도 Dr. Cem Kaner가 발표하는 Toronto Association of Systems and Software Quality (TASSQ)에 참석할 수 있었다. Kaner는 Lessons Learned in Software Testing (Wiley, 2001)의 공저자로, 이 책은 소프트웨어 테스팅에서의 그의 사상과 경험이 기술되어 있다. 결과적으로, 내 자신의 아이디어를 개념화하는데 도움이 되었다. 특히, 나는 제작 반복 기간 동안의 조사식 테스팅 활동을 올바르게 기술하는데 어려움을 겪고 있었다. 하지만 Kaner의 발표는 내 경험과 합쳐져서 도움이 되었다.

별도의 테스트 팀이라고? 당신은 터무니 없는 소리를 하고 있군! 실제로, 독립적인 테스트 팀이 당신의 작업의 결과를 확인하기 위해 라이프싸이클 동안에 간격을 두어 시스템을 제출받는 것을 통해 상당한 가치를 제공한다. 애자일 팀은 각 제작 기간의 끝단에서 작동하는 소프트웨어를 만들어낸다. 그러므로, 당신은 그 시점에 테스트해야 할 새로운 것을 가지게 된다. 일반적인 프랙티스는 반복 주기에 상관없이 최소한 한 주에 한 번 새 버전의 시스템을 제공하는 것이다. 이것은 특히 End Game에 더욱 더 다가갈 수록 좋은 전략이다.

조사식 테스트 팀의 목표는 "무엇이 잘못될 것 같은가?"라는 질문을 하는 것으로, 개발팀이나 비즈니스 이해관계자들이 고려하지 못한 잠재적인 시나리오들을 탐색하는 것이다. 그들은 "이 시스템이 좋은가?" 아닌가 그리고 "이 시스템이 문서화된 스펙을 충족하는가?" 하는 질문에 답변하려고 노력할 것이다. Confirmatory testing 활동은 시스템이 의도를 충족하는지 아닌지 확인한다. 따라서, 그다지 많은 가치를 부여하지 못하는 작업이 반복된다. Kaner는 훌륭한 테스터들은 프로그래머들이 놓친 결함을 찾고, 개별 개발자들의 협소한 시야를 찾아내는 것이라는 아이디어를 발전시켰다.

조사식 테스터들은 결함 스토리의 형태로 잠재적인 문제를 기술한다. 이것은 애자일 결함 리포트와 동일한 것이다. 결함 스토리는 요구사항의 형태로 취급된다. 이것은 추정되고 우선순위가 매겨져서 당신의 요구사항 꾸러미에 쌓여진다. 하나의 결함을 수정해야될 필요성 자체도 요구사항의 한 가지 유형이다. 따라서, 또 다른 요구사항들과 같이 처리되기에 적합하다. 당신이 기대하는 것처럼, End Game 동안에 당신이 작업해야 하는 유일한 요구사항 유형은 결함 스토리들이다.

당신의 조사식 테스팅은 부하/스트레스 테스팅, 통합 테스팅 그리고 보안 테스팅과 같은 일반적인 이슈를 다룰 것이다. 시스템 그 자체와 지원 문서 간의 일치를 확인하는 시나리오 테스팅 또한 일반적이다. 당신은 또 유저 인터페이스가 대부분의 최종 사용자에게 보여지는 시스템이기 때문에 어떤 형태의 사용성 테스팅을 수행할 것이다. 그러므로, 사용성은 성공을 위해 중요한 이슈이다. UI에는 사람들이 읽는 문서와, 상호작용하는 화면 모두가 포함되며, 그 두가지 모두 테스트할 필요성을 암시한다.

훌륭한 조사식 테스팅 활동은 그것이 처리되는데 너무나 비용이 많이 들기 전에 개발자가 오랜 기간 놓친 문제들을 발견해 낸다. 또한 그 팀이 정기적으로 고품질의 작동하는 소프트웨어를 성공적으로 만들어 내었다고 경영진에 피드백을 제공하기도 한다. Kaner는 조사식 테스팅을 수행하는데 한 가지 올바른 방법만 있는 것은 아니며, 적용할 수 있는 한 가지 기법 리스트만 존재하는 것은 아니라고 지적한다. 당신의 활동들은 당신이 지원하는 프로젝트 팀의 목표를 반영해야 한다. 예를 들어, 그 시스템이 출시될 수 있는지 아닌지 결정하기 위한 목표인가? 시스템이 기존 다른 시스템들과 호환되는지를 확인해야 하나? 개발자들이 놓친 결함의 근원들을 지적함으로써 개발자 자신의 테스팅 활동에 문제가 있는지 확인하도록 도움을 주어야 하나? 당신 조직이나 관리자들이 소송당할 가능성을 줄여야 하나? 당신이 테스팅을 하는 상황은 어떻게 그리고 무엇을 테스트해야 하는지를 결정할 것이다. 즉, 각 프로젝의 상황이 서로 다를 뿐만 아니라, 그 상황은 프로젝트 전체 라이프싸이클을 지나면서 변경된다.

애자일 팀에 의해 수행되는 confirmatory testing의 형태는 테스팅 전체에서 단지 일부분일 뿐이다. 이것은 전통적인 스모크 테스팅과 비슷한 애자일 테스팅이다. 이것은 좋은 출발이며, 자동화된 리그레션 테스팅을 가지는 것은 진화식의 개발 기법에서 요구되는 안전망을 제공한다. 조사식 테스팅은 당신이 치명적인 "큰 그림" 이슈 뿐만 아니라, 지금까지 아무도 관심두지 않았던 "작은 그림" 이슈를 탐색하게 해주며, 이것은 일반적으로 confirmatory testing가 하지 못하는 것이다.

품질은 가장 먼저 처리해야 할 업무이다.

내가 여기에 기술한 테스팅 접근법은 전통적인, 다량의 문서와 시스템이 잘될 것이라는 희망을 가지고 벽너머의 테스터들에게 던져놓는 문서 중심의 접근법과는 다르다. 나의 경험으로는 당신 시스템의 품질은 당신이 행한 테스팅 활동의 품질과 같다. 통찰력있는 피드백을 주신 Michael Bolton, Cem Kaner, Renu L. Rajani, 그리고 Steve Robinson에게 감사한다.

Agile Testing Resources

당신은 당신의 테스팅 활동들을 어떻게 향상시킬 것인지에 대한 도발적인 아이디어들을 다음의 리소스에서 발견할 수 있다:

. Agile Testing Mailing List (tech.groups.yahoo.com/group/agile-testing).
. Context-Driven Software Testing Mailing List (tech.groups.yahoo.com/group/software-testing).
. "High-Volume Test Automation," by C. Kaner, W.P. Bond, and P. McGee (www.kaner.com/pdfs/HVAT_STAR.pdf).
. James Bach's blog (www.satisfice.com/blog).
. "Lessons Learned in Software Testing," by C. Kaner, J. Bach, and B. Pettichord (www.testinglessons.com).
. Michael Bolton's testing articles (www.developsense.com/articles).
. "Roadmap for Agile Testing" and "The Testing Team's Motto," by Brian Marick (www.testing.com/writings).
. "What Is Exploratory Testing?" by James Bach (www.satisfice.com/articles/what_is_et.shtml).

정말 어려운 번역이었다. 이 저자의 글 스타일을 보아 하니, CMM의 Text 또한 무지 어려울 것으로 예상(?) 된다. ^^

오역이나 잘못된 틀린 맞춤법은 당연히 모두 원저자의 잘못이 아닌, 번역자의 잘못이다! ^^

--------------------------------------------------------------------------------------------------------

Essence of CMM

Judy Bamberger, Solutions

나는 소프트웨어 개발 역학의 학생으로써, CMM에 당황했다. 나는 그것이 진심으로 소프트웨어 프로세스 문제를 지나치게 단순화하고 있으며, 소프트웨어 개발을 이해하고 있는 사람에게는 쓸모가 적고, 그렇지 않은 사람에게는 위험한 제안을 하는 것이라 생각했다. 이것이 왜 내가 Judy Bamberger에게 매혹되었는지에 대한 이유이다. Judy는 단순한 프로세스주의자가 아니다. 그녀는 열정적이며 독창적인 사상가이다. 지금까지 그녀는 CMM을 적용하고 있으며, 심지어 그것을 길들이고, 어려움을 헤쳐가며 그것을 만들어 낸다. (She makes it jump through hoops of fire.) 그녀는 CMM의 원문에는 어디에도 존재하지 않는 CMM의 지혜를 이끌어내었으며, 지혜를 제공하지 않는 원문은 어떤 것이라도 무시한다. 나는 그녀의 접근법에서 수많은 현실성을 느꼈으며, 그것이 더 나은 것이라고 믿고 싶다. - James Bach

얼마전에 나는 주요 상용패키지 소프트웨어 벤더의 사장과 얘기중이었다. 그는 자신의 회사가 개발한 아주 잘 적용되는 어떤 새로운 컨셉을 설명했다. 나는 그가 그것을 버그 위원회라 불렀던 것으로 기억한다. 그것은 알려진 잔존 결함을 리뷰하고, 변경 요청에 대해 정기적으로 미팅하며, 그것들의 충격을 논의하고, 무엇을 추가하고 수정할지 또는 그대로 둘 것인지 주요 기능 부서가 참여해 결정을 내리는 것이다.

나는 웃으며 물었다. "우리가 형상제어위원회(configuration control board)라 부르는 것을 빼고는, 우리가 당신이 '발견한' 바로 그것과 동일한 프로세스를 15년 동안 사용하고 있었다고 말한다면 당신은 어떻게 반응하겠어요?"
"오!" "나는 아마도 바로 당신을 무시했을 거요!" 그가 말했다.
나는 다시 한 번 배움의 열망을 가지고, 도움을 줄 준비를 하고 물었다. "어떻게하면 나의 15년의 경험을 당신과 공유해서, 당신의 조직이 나머지 업계부터 배우고, 이러한 것들을 스스로 개발하는 것보다 더 빠르게 이익을 얻을 수 있을까요?"
대답은 힘이 없었다. "나도 모르겠소." 하면서 허공을 응시했다.
그리고 나서 내가 마지막으로 물었다. "당신은 소프트웨어 CMM이나 어떤 추가적인 관점을 제공하는 다른 소프트웨어 개발 가이드라인을 알고 있나요?"
"예, 하지만 그것들중 어떤 것도 우리에게 적용되지 않아요. 우리는 매우 다르거든요." 그가 말했다.

상황 안에서의 CMM

나는 CMM의 주요 작성자였으며, V1.0에 대단히 많이 기여했으며, 모든 리뷰에 참석했다. 1991년 8월에 CMM 1.0이 릴리즈되고 난 후, 나는 CMM에 대한 심각하게 다양한 잘못된 오해들을 다루어야만 했다. 나는 CMM이 현존하는 기술 문헌중에 가장 잘못오해된 것중 하나라는 사실을 발견했다.

CMM (수많은 IEEE 표준과 가이드라인 역시도)은 소프트웨어 개발 산업의 제한된 부분에서 최고의 지혜들을 모으려고 시도했다. 하지만, 나는 그 자체의 크기와 표현의 밀집성 때문에, 많은 사람들이 CMM을 이해하는데 어려움을 겪는다는 사실을 발견했다.

나는 당신들과 마찬가지로 CMM이 거대하며, 우주항공산업이나 계약-발주 소프트웨어의 개발환경을 반영하고 있으며, 최초에는 그것들을 다루기 위한 목적이었다는 점에 동의한다 (도메인이나 기술적인 부분, 시스템 그리고 "사람 이슈"는 커버되지 않는다). 그리고 나 또한 당신들과 마찬가지로 그 (사용된) 언어가 이해하기 쉽지 않음에 동의한다 (영어도 있고 "CMM 식의 말투"도 있다).

이것들이 내가 자신들의 개발 프로세스를 개선하기 위한 한 가지 도구로 CMM을 선택한 조직과 함께 일하면서 겪은 어려움들이다.

내가 배운것은 CMM의 모든 것이, 이해하기에 얼마나 쉬운지는 고려되지 않았다는 점이다. 즉, 받아들이는 입장에 따라 제공된 순수한 의미의 텍스트가 과도하게 다른 의미(해석)가 되기 쉽다는 것이다.  또한 나는 이러한 의미들이 CMM을 읽는 이들의 감정을 얼마나 깊게 건드리는지도 바로 배웠다. 받아들이는 사람이 느끼는 중요성과 그 의미는, 오늘날까지 여전히 존재하는 수많은 CMM 단어를 리뷰하고 작성하던 시절에는 상상도 하지 못했던 것이었다.

CMM은 소프트웨어 개발의 훌륭한 사례들의 극히 작은 부분만을 다룬다.

이것은 나를 퍼즐로 인도했다. 만일 CMM이 실제로 거대하고, 우주항공산업이나 계약-발주 소프트웨어 개발환경을 반영하게 작성되었다면, CMM을 개정하고, 다른 사람들이 접근할 수 있도록한 저자로써의 나의 책임을 무엇일까?  내가 나의 고객들과 일할 때, 학생들을 가르칠 때, 커뮤니티와 공개된 장소에서 이야기할 때 나의 책임은 무엇일까? 최초의 커뮤니티가 아닌 CMM을 읽는 사람들의 책임은 무엇인가? 이 모든 것안에서 CMM "작성자(owners)"의 책임은 무엇일까?

나는 내가 통제할 수 있는 퍼즐의 한 부분은 (결국) 내가 어떻게 CMM을 다루는가 라는 결론내렸다. 따라서 나는 항상 고객 (또는 학생)이 어디에서 오는지 이해하려고 시도했다. 왜냐하면, 그들이 참고한 체계나 문제를 가지고 오기 때문이다. 나는 그들의 단어를 사용해서 그들의 세계에 CMM을 가져와서 CMM을 바로알리려 노력했다. 나는 내가 이러한 일을 아주 성공적으로 했었다고 말할 수 있다. 왜냐하면, 고객(또는 학생)들이 수행하고, 이해해야하는 책임이 있다는 것을 증명했기 때문이다.

내가 고객들과 일할 때, 우리는 CMM의 핵심(essence)과 그것을 가져옴으로써 얻을 수 있는 이득을 추구했다. 종종 이렇게 함으로써, 나는 성숙도 레벨이나 등급을 무시하곤 했다. 왜냐하면, 자주 우리는 그것들이 유용하기 보다는 해롭다는 것을 발견했기 때문이다. CMM의 여러 부분들이 고객이 가진 실제적인 문제를 처리할 것으로 생각되기 때문에, 고객들이 극도의 이익을 발견할 수 있는 CMM의 여러 부분들이 존재한다.

반복적인 레벨: 프로젝트의 안정화

나는 그들의 소프트웨어 개발이 "제어되지 않는다"고 믿는 수많은 팀, 프로젝트, 조직으로 부터 이야기를 들었다. 다음의 것들이 고객들이 가장 재난의 근원이 된다고 말하는 이슈들이다.

* 각 파일의 어떤 버전이 "공식적인" 것인지 알려지지 않음
* 한 사람의 수정사항이 다른 사람의 수정사항을 지워버림
* 한 버전의 기능이 이후 버전에 유지되지 않음
* 구현되어야 할 기능에 대해 마케팅부서의 관점과 개발부서의 관점이 다름 (종종 엔드 유저의 필요를 진정으로 이해하지 못함)
* 마지막 순간까지 기능이 변경되고, 외견상 임의적인 방식으로 변경 요청됨
* 개발 공약을 달성할 수 없고, 개발자들이 요구한 공약을 달성할 수 없다고 믿을 때 (공약의) "철회"가 불가능함
* 공약을 맞추기 위해서 완료해야 할 작업이 얼마나 되는지에 대한 통찰력이 부족함
* 각 개발자가 생산한 작업 산출물 간에 현저한 차이가 있고, 재작업이나 통합 동안에 매우 많은 혼란을 야기함
* 신규 개발과 재작업에 쏟아붓는 시간의 양이 증가하고 있음

그리고 감정적인 결과가 있다. 좌절, 동기감소, 애증, 기력소진 그리고 두려움이다 (솔직해 지는 것에 대한, 늦게 릴리즈하는 것에 대한).

나는 사람들이 직면한 이슈들을 이해하려고 시도하면서 시작했다. 나는 듣고, 관찰하고, 반영하고, 승인했다. 나는 사실들과 감정들로 이루어진 그들의 이슈를 청취했다. 그리고 이런 걱정들은 내가 알았던 것이고, 소프트웨어 산업의 많은 영역에서 나타나는 것이다.

이것이 반복적인 레벨에서 CMM이 요구하는 것이다. 개발자들은 그들이 고용된 목적, 즉 소프트웨어를 개발하기위해 통제하에 어떤 규칙들을 정의해야 한다. 이것이 반복적인 레벨에서의 CMM의 핵심이다.

* 릴리즈되는 제품에 통제를 확보하고, 개발중인 제품 파트의 통제를 확보하라. (CMM의 소프트웨어 형상관리 핵심 프로세스 영역)
* 기능 집합을 정의해서, 유저가 원하는 것이 마케팅이나 개발이 원하는 것인지 확실히 하고, 변경의 영향이 완전히 이해되도록 기능을 통제하라 (요구사항 관리 핵심 프로세스 영역).
* 기능 집합을 작업 추정에 사용하라 (약속된 모든 기능이 제공될 수 있도록 하기 위해). 그리고 일정과 다른 계획들을 만드는 데 추정을 사용하라. 가능한 한 많은 과거의 경험과 지식을 활용해라 (소프트웨어 프로젝트 계획 핵심 프로세스 영역).
* 일정과 계획을 가시화 하라. 그렇게 해서, 모든 사람들이 자신들의 목표와 그것을 달성하지 못한 경우 무슨일이 발생하는지 알게한다. 진행상황을 추적하고, 성공을 가늠하고, 일정을 뒤처지거나 기능 이 변경될 때의 영향력을 더 깊게 이해하라. 관리자들이 상태, 리스크 그리고 문제들을 알게 하라. 따라서, 그들이 도울 수 있다. 기본적인 가정들이 변경되면 일정과 계획들을 변경한다 (소프트웨어 프로젝트 추적과 감독 핵심 프로세스 영역).
* 계획이 무엇을 할 것인지, 개정하거나 따라야 할 표준과 관례가 무엇인지 명확히 언급하여 개발팀을 도와라. 그리고 불일치가 발생하는 곳을 확인하고 수정하라 (소프트웨어 품질 보증 핵심 프로세스 영역).

이 모든 것이 개발자, 관리자, 테스터, 마케팅부서등 모두가 기본적인 안정성과 가시성을 확립하는데 도움이 된다. 이러한 것들이 모든 사람에게, 직접적이든 간접적이든 가시적이되면, 더 많은 성공, 즐거움 그리고, 가치를 증진시키는 활동을 하는데 더 많은 시간을 사용할 수 있도록 한다.

그리고 무엇이 진정으로 내게 가치가 있는지는 이러한 컨셉이 나와 개인에 적용될 뿐만 아니라, 내가 코드를 작성하든지 개발 교육이나 제안서를 쓰든지, 다른 어떤 컨설팅 활동의 대부분을 하는데 있어 적용된다는 것이다.

무엇이 CMM이며, 무엇이 CMM이 아닌가?

CMM 의 저작자로서 나는 당신이 사람들과 함께 일하기 전에 어떤 CMM 레벨이 "되어야"한다고 또, y 년까지는 레벨 x를 달성해야 한다는 방식을 의도하지도, 디자인되지도 않았다고 믿는다. 나는 유일한 방법만이 있거나 그것이 CMM이라고 하거나, 또는 점점 더 유명해지는 것처럼 보이는 (필수) 요구사항이나 기타 다른 슬로건은 아니라고 믿는다.

CMM은 만인을 위한 모든 것이거나 시스템이나 소프트웨어 개발의 모든 가능한 측면을 커버하려고 의도되지 않았다. CMM 저작자, 기여자, 리뷰어로써 다년간의 작업을 통해 나로부터 가이드된 관점은, CMM은 소프트웨어 개발 프로젝트나, 시간이 지나면서 개선을 가능하게 하는 가이드라인의 모음을 제공하려는 의도였다. 이러한 가이드라인의 모음은 베스트 프랙티스, 소프트웨어 엔지니어링 교육과정, 실제 세계에서의 경험, 다른 산업에서 온 개념보완에 근거하고 있다. 그리고, 가장 중요한 것은, 이러한 가이드라인 모음은 단지 "반드시 해야하는" 아이템이나 요구사항이 아닌, 가이드라인이라는 점이다. 가이드라인은 해석되고, 맞춤되고 문화와 각각의 고유한 조직의 특성안에서 적용되어야 한다.

CMM에 대한 더 많은 정보는, http://www.sei.cmu.edu/products 를 보라.

공통적인 특징들: 마법은 없다

나는 한 번도 반복적인 레벨의 핵심(essence)이 마법과같이 나타나는 것을 본 적이 없다. 심지어 팀, 프로젝트 또는 조직이 반복적인 레벨의 활동을 수행하는데서 실재적인 이득을 얻었다고 인식해도 말이다. 여기에 다시 한 번, 질문하고 듣고, 관찰하고, 반영하고, 승인하도록 요청한다. 다음과 같은 질문을 요청한다.

    * 어떻게하면 당신이 훌륭한 프랙티스들을 발생하게 할 수 있나? 그리고
    * 당신이 그러한 프랙티스들을 행했는지 어떻게 평가할 수 있나?

이것이 CMM의 공통적인 특징의 핵심이다. 그러한 동인자(enabler)와 평가자(evaluator)는 사람들이 원하는것, 사실상 완료되는 것과 처음에 또는 언제라도 올바르게 행해지는 것을 확실히 하는데 도움이 된다. 훌륭한 동인과 평가 프랙티스는 개발자가 그들이 올바르게잘 일하고 있는지, 결과 산출물이 그들로 부터 충분한 가치를 얻어낼수 있는지 알도록 해준다.

동인자(Enablers)

동인에 대한 내 질문에서 (어떻게 당신은 훌륭한 프랙티스를 공유하고 추출해낼 수 있나? 어떻게하면 새로운 사람이 그것들의 속도를 따라갈 수 있나?), 나는 종종 다음과 같이 대답한다. 우리는 누군가에 책임을 할당한다. 우리는 훈련과 도구를 받는다. 우리는 체크리스트와 템플릿을 만든다.

동인에는 정책과 절차 또한 포함된다. 이제, 어떤 경우 내가 정책과 절차를 말하면, 사람들의 5인치두께의 바인더를 생각하는 것처럼 눈이 풀려버린다. (항상 5인치의 먼지를 커버한다!) 하지만, 정책과 절차에 대해 내가 의미하는 것은 주어진 크기, 경험 그리고 조직의 안정화등으로 이해될 수 있는 것이면 어떤 것이든 상관없다.

나는 종종 "노란색 접착 메모지의 형상관리 정책과 절차"의 진실을 얘기한다. 몇년 전에, 8비트 PC 밖에는 없었고, 윈도우 같은 것도 없었고, PC환경에서 아무런 형상관리 도구조차 없었다. 3명의 아주 영리한 사람이 4개의 서로 다른 시스템에 대해 거대한 소프트웨어 제품을 (아주 빠르게) 개발했다.

그들은 매우 영리했으므로, 서로간의 작업을 단순히 어떻게 하면 손쉽게 지울 수 있는지 발견해 냈다. 따라서, 그들은 다음과 같은 약속을 정의했고 지켰다. "만일 당신이 베이스라인으로 설정된 파일을 변경하고 싶다면, 베이스라인을 유지하는 머신으로 가야한다. 만일 당신이 노란 접착 메모지에서 파일의 이름을 발견하지 못한다면, 당신은 체크 아웃 할 수 있다. 하지만, 당신은 그 파일의 이름을 노란 접착 메모지에 적어놓은 이후라야 한다. 파일의 작업을 완료한 이후에 노란 접착 메모지를 제거한다. 어떤 파일도 당신의 환경에서 테스트될 때까지는 작업을 완료해서는 안 된다. 어떤 인터페이스나 공통 파일도 전체 모두의 사전 협의가 없이 변경되어서는 안 된다."

CMM에서 동인은 체크리스트, 템플릿, 훈련, 도구, 자금, 정책, 절차 같은 것을 포함한다. 이런 모든 아이템들은 사람들에게 일을 첫번에 또는 언제라도 제대로 할 수 있는 지식, 기술 도구를 제공한다. CMM의 용어로는 이것은 수행에 집중 그리고 공통 기능들을 수행할 능력이 있다.

CMM이 진정으로 가치있는 것은 그 컨셉이 내 비즈니스와 나에게 적용된다는 점이다.

평가자(Evaluators)

평가자에 대한 내 질문에서(당신이 어디에 있는지 어떻게 아는가? 당신의 프랙티스들이 당신이 보기에 잘 작동하는지 어떻게 아는가? 사람들이 자신들이 내려야 하는 결정을 내리는데 충분한 정보를 가지고 있는지 당신이 어떻게 알 수 있는가?), 나는 종종 다음과 같이 대답한다. 우리는 마일스톤을 체크한다. 리뷰를 유지하고 있으며, 프로젝트 관리자에게 상태 리포트나 또 다른 정보를 제공한다. 우리는 진행이나 품질 지표들을 게시하므로 모든 사람들이 볼 수 있다.

내가 지표(metric)에 대해 얘기할 때, 사람들은 종종 두려워한다. 왜냐하면, 그들은 지표에 얻기위해 사용하는 측정에 두려움이 있기 때문이다. 따라서, 나는 그들과 함께 작업할 때 이해할 수 있는 지표를 정의한다. 그리고, 그것은 그들이 원하는 것을 달성했는지 여부를 알도록 해준다. 내 고객에 적절한 지표를 끌어내기 위해 나는 3가지 질문을 사용한다.

    * 지금 우리가 어디에 있나?
    * 어디로 가고 싶은가?
    * 우리가 그곳에 도착했는지를 어떻게 알 수 있나?

내 고객들과 나는 이 질문에 대한 답을 얻기 위해 지표에 관한 브레인스토밍을 한다. 그런다음, 우리는 그들이 원하는 것을 어떻게 하면 잘 얻을 수 있는지를 결정하는, 측정하기 원하는 아이템들을 놓고 협상을 한다.

CMM 에서 평가자에는 어떤 것의 완성, 그 상태, 그 품질, 그 효과성의 여부를 알게 해주는 것들이 포함된다. 개발자, 프로젝트 관리자, 상급 관리자 같은 그것을 알기 원하는 사람에의해 정보가 사용되어, 그들이 시의적절하고 효과적인 방식으로 행동을 취하게 하는 것을 말한다. CMM의 용어로는 측정과 분석, 공통 기능의 구현 확인이 있다.

이 모든 것이, 함께 어우러져서, "여기서 우리가 어떻게 해야 하는가"에 대한 문화와 기억을 형성하는데 도움이 된다. 이것은 배움, 시의적절한 액션, 잘 전파된 방식, 시간이 지나면서의 (이루는) 개선의 근간이 된다.

그리고 내게 진정으로 가치가 있는 것은 이러한 컨셉이 내개, 개인에게 뿐만 아니라 어떤 활동, 내가 내 비즈니스를 수행할 때 효과적이 되도록 하는 노력에 적용되기 때문이다.

이것이 CMM이나 최소한 그 일부분의 핵심에 관한 나의 관점이다. 이제 당신의 차례이다. 다음을 시도해 보라.

1. 당신의 소프트웨어 개발 프로세스중에 어려움이 있거나, 개선을 위해 준비가 된 영역을 찾아보라.
2. 그러한 영역을 처리하는 몇가지 옵션들을 찾아보라.
3. 그러한 옵션들과 가까운 것으로 보이는 CMM 내의 핵심 프로세스 영역을 찾아라.
4. 핵심 프로세스 영역의 목적을 읽고, "이러한 목적으로 내가 얻을 수 있는 것은 무엇인지?" 질문하라.
5. 만일 목적들과 당신이 옵션으로 확인한 것들 간에 관계가 있다면, 핵심 프랙티스와 공통 기능을 좀더 심화해서 탐색하라.
6. 열린 사고를 유지하라. 당신이 배우는 만큼 보게되며, CMM의 단어 뒤에 숨은 핵심을 찾아라. 당신의 참조의 틀에서 그것을 찾아내고, 그것을 당신이 직면한 이슈를 처리하는데 주의깊게 사용하라.
7. 그러면 CMM의 핵심으로서 당신이 발견한 것을 내게 알려라. {끝}

Judy Bamberger는 소프트웨어 개발, 팀 리딩, 프로세스 개선 수행 그리고 교육에 20년의 경험이 있다. 또한 독립 컨설턴트인 그녀는 수많은 품질 도구들을 자신들의 핵심부분에 적용하여 최고로 선정된 클래스를 가르쳤으며, 자신들의 실제 팀과, 프로젝트 그리고 조직 상황에 그 내용을 적용한 학생들을 두고 있다.

예전에 MS의 Visual Studio Team Blog의 글 중에서 테스트 관련된 내용들을 번역한 적이 있어서 정리해서 링크를 걸어 봅니다.

전체적인 느낌은 누구나 다 알고 있지만 현실이라는 장벽 아래서 제대로 행하지 않는 것을 잘 행하고 있다는 느낌입니다.
그리고 아래 덧붙인 것처럼 SDET (Software Design Engineer in Test)라는 직군을 둘 만큼 중요성도 잘 인식하고 있는 것 같습니다.

MS Visual Studio 빌드 프로세스 - VC++ 라이브러리팀의 Check-in 프로세스

MS VC++ IDE QA팀에서 일어난 해프닝 - Hello World 사건 - 으로부터의 교훈

MS Visual C++ 개발팀의 QA팀 활동 내역 - 그들은 최고 일 수밖에 없다.

MS Visual C++ 라이브러리 개발팀의 Regression (회귀) 자동화 테스트 사례

SDET

테스트와 관련된 일을 하는 사람같은데 전체 이름을 종잡을 수 없었습니다. 그래서 구글에서 찾아보니

SDET - Software Design Engineer in Test

즉, 테스트 쪽 소프트웨어 설계 엔지니어라는 명칭이었습니다.

그리고 MS의 사이트에서 소개한 정의를 보면 다음과 같습니다.

Software Design Engineer in Test

소프트웨어 컴포넌트와 인터페이스를 좀 더 기술적으로 테스트하고 평가하며, 품질 평가를 위해 테스트 프로그램을 개발하고 테스트 효율성 향상을 위해 테스트 도구를 개발한다.

Software Design Engineer in Test
Tests and critiques software components and interfaces in more technical depth, writes test programs to assure quality, and develops test tools to increase effectiveness.

제가 왜 SDET의 Desgin Engineer에 볼드체 표시를 했을까요?

개 발팀 내 신입사원에게 개발자 유닛 테스트 (unit test)를 맡기고 시스템 테스트에는 아르바이트나 계약직을 사용하고 테스트 관련 업무를 하면 좌천되었다고 생각하는 국내의 현실에서 저희는 감히 Design Engineer라는 말을 테스트 엔지니어의 수식으로 사용할 수 없기 때문입니다.

SDET에 대해 설명하고 있는 MS 사이트의 내용을 보면 그들이 얼마나 테스트와 테스트 엔지니어를 중요시여기는지 아실 수 있습니다.

===================================================================

품질에 대한 열정 (A Passion for Quality)

테스트는 소프트웨어 개발 프로세스에서 제품의 품질을 향상시키고 고객의 니즈 (needs)를 제품에 올바르게 반영할 수 있는 아주 중요한 전략적 역할 (a critical strategic role)을 한다. 모든 마이크로 소프트의 제품들은 릴리즈 전에 테스트를 마쳐야 한다.

"You break it to build it"

※ 짧은 영어로 의역해보면 "무엇인가를 완성하기 위해서는 그것을 망가뜨려 봐야 한다." 즉 테스트를 통해서 결함 (defect)을 찾아봐야 한다. 일 것입니다.

이 모순된 말은 MS에서 테스트를 전문적으로 하는 사람들에게는 널리 통용되는 말이다.

MS 의 테스트 엔지니어는 제품의 요구 사항을 이해하기 위해 프로그램 매니저 (program manager)와 소프트웨어 디자인 엔지니어와 밀접하게 일하며 제품의 피쳐 (features)와 기능을 테스트를 통해 확인 (validate)하기 위해 테스트 계획 (test plan)과 테스트 케이스를 디자인하고 시스템 테스트를 통해서 버그를 찾아낸다. 그들의 일에 있어 테스트 전문성은 업무적으로 성장하거나 미래 주어질 프로젝트를 결정지을 주요한 척도이다.

마이크로소프트의 테스트 조직은 효과적인 많은 방법론과 도구를 개발했다. 기능 테스트 (functional testing), 네거티브 테스트 (negative testing), 고객 시나리오 테스트 (customer scenario testing), 스트레스 테스트 (stress testing), 성능 테스트 (performance testing), 확장성 테스트 (scalability testing), 인터내셔널 테스트 (international testing)을 모두 수행하며 모든 테스트 활동은 고객이 최고 품질의 제품을 받아 볼 수 있도록 하기 위함이다.

===================================================================

VC++ 팀 블로그에 게재되는 글들을 통해 그들의 테스트 활동을 엿보면, 마이크로소프트의 위 글이 절대 말뿐인 것은 아님을 알 수 있습니다.

마이크로소프트는 누구나 알고 있는 테스트의 주요한 활동들을 개발 프로세스 내에서 수행하고  테스트 엔지니어와 그들의 역할을 중요시여기고 있습니다.

마이크로소프트와 관련된 소프트웨어 활동 등을 보면 볼 수록 참 제대로 멋지게 일하는 구나라는 생각도 들지만 한편으로는 아래와 같은 반성도 해봅니다.

멋 진 구성원이 없다면 멋진 조직이 없을 것입니다. 즉, 마이크로소프트에서 자랑처럼 이야기하는 테스트활동은 그만큼 자질있는 구성원들이 있기때문에 가능할 것입니다. 국내의 소프트웨어 개발 여건이 또 국내의 테스터의 환경이 나쁘고 커리어 패스를 찾을 수 없다고 하기 전에 혹시 자신이 피해의식과 비관론에 젖어 무기력해 있지 않는지도 돌이켜봐야할 것입니다.