테스트 케이스를 평가하는 뮤테이션 테스트 (Mutation Testing)

3 Comments

테스트 케이스가 얼마나 잘 작성했는지 평가하는 것은 “보통 얼마나 많은 결함을 찾았나?” 또는 “커버리지 (Coverge)가 얼마나 되나?”를 통해서 평가 받을 수 있을 것이다.

그리고 또 하나 Mutation Testing을 통해서도 평가 받을 수 있을 것이다.
원본 프로그램을 수정 한 Mutant를 테스트 케이스를 수행해서 수정된 부분으로 인해 실패한 테스트 케이스가 있는지를 통해서 테스트 케이스가 얼마나 테스트를 잘 하고 있는지 평가 할 수 있다.

즉, c = a+b; 라는 코그를 c = a-b; 수정 후 테스트 케이스를 돌려 실패한 테스트 케이스가 있는지 확인하는 것이다.

보통 생성한 총 Mutant 분에 테스트 케이스가 실패해서 Mutant임이 밝혀진 Killed Mutant 수인 Mutant Scroe로 테스트 케이스 수준을 평가한다.

Mutant Score = # of Killed Mutant / # of Total Mutant

Ref
[1] Mutation Testing 관련 Papers http://ise.gmu.edu/~ofut/rsrch/mut.html
[2] Mutation Testing 소개 PDF http://agile.csc.ncsu.edu/testing/MutationTesting.pdf

[테스트 단상] (거창하게) “패러다임이 변하고 있으니 테스트가 조금 더 각광받지 않을까요?

4 Comments

지극히 주관적인 의견이지만 전자 제품은 텔레비전 뿐인 산골에서의 망상 (illusion)은 아니라고 생각되어 몇 글자 적어 봅니다.

소프트웨어 테스트가 현실 (일정과 인력)을 만났을 때, 아마 가장 많이 연상되는 단어는 “트레이드 오프 (trade off)”일 것입니다.

- 출시가 얼마 남지 않았기 때문에
  (어느 정도의 결함을 안고서라도 “타임 투 마켓”이 더 우위에 있기 때문에)
- 개발 인력이 턱없이 부족하기 때문에

와 같은 이유로 테스트는 (어쩔 수 없이) 뒷전으로 밀려나는 경우가 많은 것 같습니다.
그렇지 않은 경우를 찾는 것이 더 힘들겠죠.

저의 제목과 이 포스트에서 말하고자하는 것은 무엇일까요?
그 것은 무엇이라고 정의할 수는 없지만 그 “변화”가 “테스트”에 유리하게 흘러간다는 것입니다.

기존에 테스트를 어렵게 만든 것 큰 이유 중의 하나는, 개발 자체에 소요되는 비용 (인력/시간)일 것입니다.

제가 패러다임 운운한 것은 이 개발에 대한 비용이 점점 줄어들 것 같기 때문입니다.
즉, 개발 비용이 줄어들기 때문에 다른 것에 남는 비용을 (물론 전체 비용을 줄여 버릴 수도 있지만) 다른 곳으로 돌릴 여지가 많아진다는 것입니다.

동의할 수도 있고 동의하지 않을 수도 있지만 “개발 비용”이 줄어들 것 같다는 것에 대한 몇 가지 현상들을 거론해보면 다음과 같습니다.

※ 물론, SE나 공중 부양을하고 있는 몇몇 언어의 순수 이론자 (doctrinaire)들의 말을 하기 시작한다면 끝도 없을 것입니다. 저는 제가 주로 보고 느낀 것들에 대해서 쓰겠습니다.

- 통으로 만들던 것들을 점점 레이어를 나누어 프레임워크, 플랫폼이라는 말을 하면서 개발하려고 합니다. (reusability를 이용한 생산성 향상이겠죠?)

- Visual C++ Team 블로그에서도 C++의 미래를 system programming을 위한 최적화 언어로 이야기한 적이 있습니다. 즉, 그 만큼 system level 이상에서 무언가 만들기 위한 고급 언어들이 많아졌고 그들의 한결같은 특징은 높은 생산성입니다.

- Java, C/C++ 등으로 열심히 플랫폼 (or 프레임워크)를 만들던 사람들이 파이어폭스 (정확히는  Gecko 겠죠?)를 플랫폼 자체로 사용하려고 합니다. 안드로이드 (Android)를 보는 시각도 같겠죠.

- 일본의 어떤 회사들은 perl을 사용한다고 해도 모든 것들을 창조한다고 합니다. 하지만 점점 더 “잘 가져다 쓰는 사람”들의 창조물을 더 이상 구태의연한 변명으로 덮어 버릴 수 없게 되어갑니다.

- 이제는 특정 OS (e.g. MS Windows)에서 나 홀로 (standalone) 애플리케이션을 만들던 시대는 점점 가버리고 환상적인 웹 기반 애플리케이션의 시대가 오고 있는 것 같습니다.

- (불특정의) 내가 고집하고 대대로 계승할 것만 같던 기술들에 대해 정체성을 느끼기 시작합니다.

- 더 이상 Java는 예전의 달팽이에 볼품없던 외관을 가졌던 그 Java가 아닌것 같습니다.

좀 더 많은 것들을 이야기 할 수도 있겠지만, 왠지 어느 양심수의 독백과 같은 풍으로 글이 흘러가는 것 같아서 줄이겠습니다.

하지만 말하고 싶은 것은
너무나 빨리 (쉽게라는 말은 하지 않겠습니다) 멋진 것들을 만들 수 있게 되어가고
“잘 만드는 사람” 보다는 “잘 이용해서 가져다 쓰는 사람”이 필요해지고
개발 그 자체의 비용이 줄어 들어감에 따라 이제는 생각 (기획)하고 품질(테스트를 포함하는)을 위해 투자할 비용이 넉넉해지는 것 같습니다.

그렇습니다.

[SE] 코드 인스펙션 (Inspection)이 가장 효과적이라는 권위있는 증거 자료 논문

27 Comments

최근에 본 논문 중에 괜찮은 것이 있어 하나 소개합니다.

소프트웨어 엔지니어링 (Software Engineering, SE) 그 중에서도 품질 보증 (Software Quality Assurance, SQA) 분야에서 아래와 같은 이론은 누구나 알고 있는 자명한 사실일 것입니다.

결함을 늦게 발견할 수록 결함을 수정하는 비용은 증가한다. 즉, 소프트웨어 결함은 조기에 발견할 수록 비용을 절감할 수 있다. 그런 결함 발생 예방 활동 중 대표적인 것이 코드 인스펙션 (Inspection)과 리뷰 (Review)활동이라고 할 수 있을 것이다.

그런데 만약 당신의 상관이나 조직 구성원 중 누군가가 코드 리뷰를 해보지도 않고서 또는 형식적으로 어설프게 해보고

“코드 인스펙션하면 얼마나 효과적인데? 코드 짜고 테스트 케이스 짜서 돌려보는게 더 낫지 않어?”

라는 질문을 던진다면, 주관적인 설득의 무기밖에 소지하고 있지 못한 자신을 발견할 것입니다.

서론이 좀 길었지만, 이런 상황에서 권위 있는 사람의 정량적 실험에 관한 그리고 미국 국방성 (DoD)에 제출한 논문 한편이 큰 도움이 될 것같습니다.

소개할 논문은 논문 저자가 ROI를 측정하기 위해 유사한 소프트웨어 개발 환경에서 Inspection, PSP, TSP, SW-CMM, ISO9001, CMM를 적용한 사례들도 이야기해주는데 국내의 활동과는 너무나 다른 것 같습니다.
가령, 코드 인스펙션으로 한 번의 미팅에서 보는 코드 라인을 240줄로 잡고 있습니다. 240줄! 물론 공백과 주석은 뺐겠지만 국내에서는 상상할 수 없는 라인 수 일 것입니다.

※ 글 중 [ <number> ] 는 참고 문헌입니다.

논문 소개

논문의 제목은 아래와 같고 여기에서 PDF 버전을 다운로드 받을 수 있습니다.

인스펙션, PSP, TSP, SW-CMM, ISO 9000, CMMI의 ROI를 어떻게 예측할 것인가?

How to Estimate ROI for Inspections, PSPsm, TSPsm, SW-CMMâ, ISO 9000, and CMMIsm

저자는 David F. Rico 입니다.
저자 David F. Rico에 대해서 먼저 소개하면 그의 컨설팅 홈페지이에 나와있는 소개 처럼,

소프트웨어 프로세스와 품질 향상에 관한 세계적인 기술 리더로써 15개 이상의 SW-CMM 레벨 2~5 적용 과제를 미국 NASA, 미 공군, 해군, 일본 기업들에서 이끌거나 참여했으며 특히 Software Engineering에 대한 ROI (Return Of Investment) 관련 책과 논문으로도 유명합니다.

이 논문은 미 국방성 (DoD)에 제출된 논문으로 결과부터 말씀 드리면 아래 그래프와 같이 여러 활동 중에서 코드 인스펙션 (inspection)이 ROI 측면에서 가장 효과적이라는 것입니다.

즉, 투자한 비용 대비 가장 효과가 높다는 겁니다.

ROI 측정 방법 [2]

David F. Rico가 ROI를 측정하기 위한 방법을 간단히 소개하면 아래와 같습니다.

  • Benefit/Cost Ratio (B/CR)
    이익을 투자한 비용으로 나눈 것입니다.
    이익/투자 비용
  • Return on Investment (ROI%)
    이익에서 투자 비용을 빼고 이 것을 다시 투자 비용으로 나누어 백분율을 계산
    (이익 – 투자 비용) / 투자 비용 × 100

즉, 위의 두 ROI 측정 방법을 이용해서, 각 활동을 위해 수행 인원들의 교육 비용, 수행 인원들의 활동 시간에 따른 비용을 투자 비용으로 계산하고 전체 소프트웨어 개발 기간 동안 절감된 시간과 그에 따른 비용을 이익으로 계산했습니다.

그 결과가 Benefit/Cost Ratio 상으로도 Inspection이 가장 뛰어납니다.

각 활동들의 수행 내역과 결과를 보면 아래와 같습니다.

전제

  • 한 프로젝트는 4명의 멤버가 수행합니다.
  • 한 사람의 한 시간당 인건비는 $100 입니다.
  • 개발할 소프트웨어는 SLOC가 10,000입니다.

1. Inspection

1. 교육 비용 (Training cost)

Inspection 교육 비용의 평균은 410$이고 한 사람당 24시간 정도 소요되며 한 시간당 인건비는 $100이며 4명을 교육 시켜야 하기 때문에 교육 비용은 다음과 같습니다.

한 사람당 교육 비용 + 24시간 교육을 받는 동안 그 사람의 인건비

= $410 + (24 × $100) = $410 + $2,400 = $2,810

네 사람을 교육 시켜야 하기 때문에 (4 × $2,810) 총 교육 비용은 $11,240 이 듭니다.

2. Inspection 수행 비용

SLOC (Source Line Of Code )가 10,000 일 때 한 시간 동안 Inspection할 SLOC가 240으로 잡을 때 41.67 번의 Inspection을 하고, 한 번 Inspection을 할 때 계획 (planning), overview, 준비 (planning), 회의 (meeting), rework, follow-up 등에 소요되는 시간이 17시간이 들기 때문에 전체 수행 시간은 41.67 × 17로 708.33 시간이 소요됩니다.

시간당 인건비가 $100이기 때문에 총 수행 비용은 $70,833이 듭니다.

※ 미 국방성 (DoD)에 제출한 논문이고 유명한 논문이지만 정말 믿지 못할 만큼 성실하고 자세히 Inspection을 수행하는 것 같습니다.

3. 총 비용 (Total Cost)

교육 비용과 Inspection 수행 비용을 합치면 $11,240 + $70,800 = $82,073이 들었습니다.

4. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

10,000 SLOC의 소프트웨어를 개발하는 동안 훈련된 Inspector에 의해 Inspection이 수행되고 나서 문제가 발생해서 유지.보수 해야 하는 시간이 총 11,806시간이 들었다고 합니다.

※ 유지.보수는 코드가 잘 못 작성된 것을 추후에 발견해서 고치거나 Integration 또는 Unit/Integration/System Test에서 결함이 발생되어 수정한 시간을 모두 포함했을 것입니다.

이 것은 Inspection을 수행하지 않았을 때 든 유지.보수 시간이 41,800인 것을 29,994 시간만큼 줄인 효과입니다.

즉, Inspection을 수행하고 나니 그렇지 않을 때 보다 29,994 시간이 절약되었고 이 것은 시간 당 인건비 $100을 감안하면 $2,999,400의 절감효과 (benefit)이 생긴 것입니다.

5. B/CR (Benefit/Cost Ratio)

이익을 투자한 비용으로 단순히 나눈 B/CR의 경우는 $2,999,400 / $82,073 = 36.54로 약 37:1의 효과를 가지고 왔습니다.

6. ROI%

이익에서 투자한 비용을 빼고 그 것을 투자한 비용으로 나누어 백분율 (×100)로 표현하는 ROI%의 경우는 (이익 – 투자 비용) / 투자 비용 × 100 이므로

(2,999,400 – 82,073) / 82,073 × 100 = 3,554.55 % 이므로 3,555%가 됩니다.

2. PSP (Personal Software Process)

psp

※ PSP는 위키페이지에서 간략한 설명을 볼 수도 있습니다. 필자도 몇 년 전 PSP 교육을 받아보았는데, PSP는 카네기 멜론 (Carnegie Mellon) 대학에서 만들어진 것으로 원칙이 자신이 맡은 코드를 단 한번에 컴파일을 성공하는 것입니다. 많은 사람들이 코드를 작성하면서 중간 중간에 컴파일을 하면서 에러나 결함을 잡는 것에 비해 PSP는 코드 작성 전이나 코드 작성 중 많은 리뷰 활동을 통해서 이와 같은 것을 가능하게 합니다. 실제 MS에서도 적용 후 놀라운 효과를 보기도 했습니다. 그리고 코딩 시간 및 리뷰를 통해 잡은 에러를 분류/분석해서 정량화 함으로써 문제점을 파악하고 유사 도메인이 과제에 대한 Estimation의 근거 자료로도 쓰일 수 있습니다.

1. 교육 비용

※제가 알기로는 PSP를 교육할 수 있는 자격증은 카네기 멜론 대학에서 이수할 수 있습니다. 그 만큼 교육을 받는 비용도 비싸겠죠?

Software Engineering Institute (SEI)에서 한 사람이 교육을 받는 비용은 $5,000이고 2주간의 항공, 숙박 비 등에 $5,400이 추가로 들며 총 교육 기간은 10일 (80시간)이 소요됩니다. 그리고 각 수업 시간 (1시간) 마다 수업 외의 1시간씩이 더 필요합니다. (제가 교육을 받을 때도 숙제 등의 시간이 많이 필요했었습니다). 즉, 총 160시간 (80+80)이 소요됩니다.

교육비와 부대 비용에 160시간에 대한 인건비 ($100/h)를 계산해보면,

$5,000 + $5,400 + 16,000으로 $26,400이 들고 이 것을 네 명으로 곱하면 총 교육비용은 $105,600입니다.

※ 실제 효과 (benefit)은 PSP가 Inspection에 비해서 높지만 이와 같이 비싼 교육비 때문에 ROI는 낮게 됩니다.

2. PSP 수행 비용

동일한 10,000 SLOC에 대해서 PSP를 적용했을 때 시간당 코딩 할 수 있는 SLOC는 25입니다. ※설명 드린 것처럼 코드를 작성하기 위해 디자인이나 Pseudo 코드, 리뷰, 측정을 할 것이 많습니다. 즉, 10,000 SLOC의 소프트웨어를 개발하기 위해 400시간이 소요되어 총 비용은 $40,000이 됩니다. (※ 4명이 각각 자신의 모듈을 PSP에 따라 작성하기 때문에 Inspection과 달리 4를 곱하지 않습니다)

3. 총 비용 (Total Cost)

총 비용은 교육 비용 $105,600에 수행 비용 $40,000을 더한 $145,600입니다.

4. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

10,000 SLOC의 소프트웨어에 대한 코드 작성 이후의 유지.보수 비용은 앞에서 이야기 했듯이 41,800 시간이 소요됩니다. PSP의 경우는 이 유지.보수 시간이 0시간으로 됩니다.

※실제 시스템 시험까지 모든 결함이나 설계 문제가 나타나지 않는다는 결론 같은데 쉽게 납득은 되지 않습니다. 하지만 PSP를 정말 제대로 수행했다면 그 많은 설계 검토 과정과 리뷰, Pseudo 코드 작성과 그 것을 코드로 작성하고 작성 중에도 리뷰를 하는 과정을 생각해보면 전혀 틀린 말도 아닌 것 같습니다.

그리고 10,000 SLOC의 일반적인 (without PSP) 코드 작성 시간은 5,088 시간이며 PSP로 코드 작성을 한 시간은 242시간이 됩니다. 즉, 4,846시간을 추가로 절감할 수 있습니다.

※ 이 또한 실제 코딩을 하는 시간은 PSP가 훨씬 적습니다. 그 이 전 단계가 많은 시간을 요하지…

유지.보수 시간을 41,800 시간 줄였고 코드 작성 시간도 4,846시간 줄여서 46,646시간을 줄였습니다.

이 것을 시간당 $100의 인건비를 생각하면 전체 절감 비용 (benefit)은 $4,664,600이 됩니다.

5. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $4,664,600 / $145,600 = 32.03 이어서 32:1이 됩니다.

※ Inspection은 $2,999,400 / $82,073 = 36.54이었습니다. 즉 이익은 적었지만 교육 비용과 수행 비용이 적었습니다.

6. ROI%

이익 – 총 비용 / 총 비용 × 100 은 ($4,664,600 – $145,600) / $145,600 × 100 = 3,103.708%로 3,104% 입니다.

3. TSP (Team Software Process)

tsp

※ TSP에 대한 위키 페이지는 여기입니다. TSP는 PSP의 개인 활동을 팀 활동으로 확대한 것으로 생각하시면 됩니다.

1. 교육 비용

PSP와 같이 SEI에서 교육을 받아야 하고 교육 비용 $4,000에 부대 비용 $2,700이 들며 일주일의 교육 기간이 필요합니다. 즉, 40시간이 소요되어 시간 당 인건비를 곱하면 $4,000의 인건비가 한 사람당 소요됩니다. TSP를 한 사람이 교육 받는데 드는 비용은 $10,700입니다.

그런데 위에서도 설명 했듯이 TSP는 PSP를 팀 활동으로 확대한 것이기 때문에 PSP도 교육받아야 합니다. 그래서 PSP의 한 사람당 교육에 소요되는 $26,400을 더하면 한 사람이 TSP를 수행하기 위해 교육 받는 비용은 $37,100이며 이 것을 네 사람에게 교육해야 하기 때문에 총 비용은 $148,400이라는 천문학적인 비용이 소요됩니다.

※즉, TSP도 효과는 좋으나 교육 비용이 높아서 PSP나 Inspection에 비해 ROI가 낮습니다.

2. TSP 수행 비용

TSP로 10,000 SLOC 소프트웨어를 개발할 경우 한 시간당 작성될 수 있는 코드는 6.12 SLOC (PSP에 비해서 좀 더 해 야할 일이 많습니다) 이어서 1,634시간의 시간이 필요합니다. 그래서 총 수행 비용은 $163,400이 됩니다. [4]

3. 총 비용 (Total Cost)

총 비용은 교육 비용과 수행 비용을 합한 $148,400 + $163,400 = $311,800입니다.

4. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

PSP와 같이 10,000 SLOC의 소프트웨어 개발에 대한 코드 작성 후 유지.보수 시간인 41,800을 모두 줄일 수 있고, 10,000 SLOC의 소프트웨어 코딩을 위한 5,088 시간도 1,634시간 만 들기 때문에 추가 적으로 3,454시간을 절감 할 수 있습니다.

전체 절감한 시간은 41,800 + 3,454 = 45,245시간이 되어 총 절감 비용은 $4,525,400이 됩니다.

5. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $4,525,400 / $311,800 = 14.51 이어서 14:1이 됩니다.

※ 이 부분은 논문 저자가 잘못 한 것 같습니다. 다른 부분은 모두 올림을 했는데 여기서는 소수점 이하를 버림으로 처리해서 14가 되었습니다. -_-;; 거장에게 메일을 한 번 보내볼까 생각 중입니다.

6. ROI%

이익 – 총 비용 / 총 비용 × 100 은 ($4,525,400- $311,800) / $311,800 × 100 = 1,351.37%로 1,351% 입니다.

 

4. SW-CMM (Capability Maturity Model)

※ CMM으로도 알려져 있는 SW-CMM은 CMMI (Capability Maturity Model Integration)으로 대처되었습니다. 마찬가지로 Carnegie Mellon 대에서 만들어진 것으로 조직의 프로세스를 성숙 단계로 두고 평가하는 모델로 잘 알려져 있습니다.

이후에 나올 SW-CMM, ISO09001, CMMI들은 앞에서 적용한 Integration, PSP, TSP와는 다르게 프로젝트를 수행하는 조직에 해당 모델을 적용하고 심사를 하는 비용을 투자 비용으로 보고 있습니다.

SW-CMM의 경우는 레벨 3까지 조직의 성숙도를 올린 후에 평가를 한 비용은 투자 비용으로 계산하고 있습니다.

1. 레벨 2 적용 비용 (Deployment Cost (Level 2)

SW-CMM을 4개의 프로젝트를 수행하는 소프트웨어 조직에 적용하는 비용은 다음과 같이 측정했습니다.

※즉, 10,000 SLOC의 소프트웨어를 5명이 개발하는 과제가 4개 있는 조직에 대해서 적용하고 있습니다.

6개의 정책에 대해 66시간, 24개의 절차 (procedure)에 대해 512시간, 34개의 문서에 대해 264시간, 76개의 work authorization에 대해 304시간, 116개의 기록 (records)에 대해 464시간, 136개의 보고서에 대해 544시간, 76개의 회의록에 대해 304시간이 소요되어 총 2,458시간이 소요되었고 시간당 인건비 $100을 고려하면 비용은 $245,800입니다 [5].

2. 레벨 3 적용 비용 (Deployment Cost (Level 3)

레벨 2로 조직의 성숙도를 올린 후 그 조직을 레벨 3으로 올리기 위한 비용은 다음과 같습니다.

7개의 정책 (policies)에 대해 77시간, 14개의 절차 (procedures)에 대해 154시간, 80개의 문서에 대해 1,280시간, 44개의 work authorization에 대해 176시간, 148개의 기록에 대해 592시간, 84개의 보고서에 대해 336시간, 48개의 회의록에 대해 192시간이 들어 총 소요 시간은 2,807시간이고 시간당 인건비 $100을 곱하면 비용은 $280,700입니다.

3. 평가 준비 비용 (Assessment Preparation Costs)

우리의 실험 조직에 대해 SW-CMMI를 평가하기 위한 준비 비용은 다음과 같습니다.

13개의 Indoctrination (평가를 위해 사전 교육 과정 정도로 볼 수 있겠습니다) 마다 2시간이 소요되고 이 것을 4개의 과제에 대해서 5명에게 수행해야 하기 때문에 13 × 2 × 4×5가 되어 520시간이 필요하고, response conditioning 코드 (이 것도 마찬가지로 평가를 위한 사전 과정)가 13개가 있고 각 2시간이 소요되어 4개의 과제를 위해 5명에게 필요한 시간은 520시간입니다. 그리고 4개 과제 5명에게 각각 40시간이 드는 예행 심사를 수행해야 하기 때문에 4×5×40의 800시간이 추가로 소요됩니다 [5].

전체 준비 비용은 13개의 Indoctrination 코스와 13개의 response conditioning 과정, 예행 심사의 시간을 더하면 총 1,840시간이 들어서 총 비용은 $184,000이 듭니다.

4. SW-CMM을 적용하기 위한 비용

SW-CMM의 레벨2와 레벨3을 적용한 비용과 평가 준비 비용을 모두 더 하면 $245,800 + $280,700 + $184,000이 되어 $710,500이 소요되었습니다.

5. SW-CMM으로 심사 (assessment)한 비용

이 비용은 Inspection이나 PSP, TSP에서는 각 방법을 적용한 비용과 유사할 것입니다.

SW-CMM으로 조직의 성숙도를 심사하는데 드는 비용은 다음과 같습니다.

3,208시간의 내부 준비 시간이 필요하고

4개 과제의 5명에게 62시간의 계획시간과 234시간의 준비, 646시간의 자체 평가와 57시간의 follow-up 시간을 모두 더하면 1,000시간 (※ 우리의 저자가 또 1을 빼 먹었거나 소수점 자리 계산으로 1,000이 된 것 같습니다. )이 필요하고 이 것의 비용은 시간당 인건비 $100을 고려하면 $100,000이 필요합니다. 여기에 심사 비용 $40,000을 더하면 총 심사 비용은 $140,000입니다.

※ SW-CMM은 자체적으로 심사하는 것이 아니고 외부 심사위원에게 심사를 받는 것입니다.

6. SW-CMM의 총 비용

SW-CMM을 위해 투자한 비용은 SW-CMM 레벨2와 3을 적용한 비용과 평가 준비 비용 심사 비용을 모두 합해서 $710,500 + $140,000이 되어 $850,500이 됩니다.

7. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

SW-CMM 3레벨을 적용한 10,000 SLOC 과제 4개에 대한 이득은 다음과 같습니다.

Inspection으로 27,867의 유지.보수 시간이 줄어들어 4개의 과제에 대해 전체 111,466시간이 절감되었고, SW-CMM 레벨 3를 적용하면 코드 생산성이 2배 증가한다는 Diaz의 보고[6]에 따라 한 과제당 2,544시간의 시간이 절감되어 4과제에 대해서 10,176시간이 줄어들었습니다.

총 절감한 시간은 111,466 + 10,176가 되어 121,642시간이고 비용은 $12,164,200이 됩니다.

8. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $12,164,200 / $850,500 = 14.30 이어서 14:1이 됩니다.

역시 효과는 높지만 그 만큼 투자 비용이 높아서 TSP와 같은 B/CR을 보입니다.

9. ROI%

이익 – 총 비용 / 총 비용 × 100 은 ($12,164,200 – $850,500) / $850,500 × 100 = 1,330%입니다.

5. ISO9001

ISO9001은 품질 관리에 대한 표준으로 다음 사항 등을 포함하고 있습니다.

  • 주요 프로세스에 대한 절차
  • 각 효과를 확인하고 모니터링 하는 것
  • 기록
  • 결함 확인과 수정
  • 리뷰활동

1. 적용 비용

El Emam의 비용 모델[7]에 따라 20명인 조직에 ISO9001모델을 적용하는데 드는 비용은 다음과 같습니다.

※SW-CMM부터는 5명이 한 조가 되어 4개의 프로젝트를 하는 조직에 대한 적용 사례이기 때문에 조직의 구성원이 20명입니다.

ISO9001 등록 준비를 위해 2,184의 준비 시간이 필요해서 시간당 인건비 $100을 곱하면 $218,396의 비용이 필요합니다 (분까지 포함해서)

2. 심사 비용

심사 준비를 하는데 각 구성원이 32시간이 필요해서 20명의 조직원을 곱하면 640시간의 준비 기간이 필요해서 준비 비용은 $64,000입니다. 그리고 여기에 심사 비용인 $48,000을 더하면 총 심사 비용은 $112,000입니다.

3. ISO9001의 전체 투자 비용

ISO9001의 적용 비용과 심사 비용을 합치면 $218,396+$112,000이 되어 $330,396의 비용이 듭니다.

4. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

ISO9001을 적용하면 15%의 유지.보수 비용 절감 효과가 있다고 하기 때문에,

앞에서 거론했듯이 10,000SLOC과제의 유지.보수 비용이 41,800시간이므로 15%는 6,270시간의 절감이 있고 이 것은 4개의 과제마다 효과가 나타나므로 6,270×4가 되어 25,080시간의 유지.보수 시간 절감 효과가 발생합니다.

또한, ISO9001을 적용하면 13%의 생산성이 증가한다고 합니다. 따라서 SLOC가 10,000이 소프트웨어의 코드 작성 시간이 5,088시간의 13%는 661시간이며 이 것이 4개의 과제에 나타나므로 총 코드 작성 시간의 절감은 2,646시간입니다.

전체 절감 시간은 유지.보수 시간 절감과 코드 작성 시간 절감을 더해서 25,080 + 2,646이 되어 27,726시간이며 시간당 인건비 $100을 곱하면 이득은 $2,772,600이 됩니다.

5. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $2,772,600 / $330,396 = 8.39 이어서 8:1이 됩니다.

비용은 SW-CMM보다 낮지만 이익도 낮습니다.

6. ROI%

이익 – 총 비용 / 총 비용 × 100 은 ($2,772,600 – $330,396) / $330,396 × 100 = 739%입니다.

6. CMMI (Capability Maturity Model Integration)

cmmi

SW-CMMI에서도 설명 드렸지만 SW-CMMI등을 통합한 조직 성숙도 모델로 카네기 멜론 (Carnegie Mellon)에서 만들어졌습니다.

※ CMMI는 4개의 프로젝트를 수행중인 조직에 대해서 적용한 것이고 각 프로젝트는 10명의 구성원이 있습니다. 즉 조직은 40명의 조직입니다.

1. CMMI 정책과 절차에 대한 비용 (CMMI Policies and Procedures)

CMMI의 정책과 절차들을 4개의 프로젝트에 적용하기 위한 비용은 다음과 같습니다.

레벨2를 위해 56개의 정책과 절차를 만드는데 필요한 시간은 2,091시간이고 레벨3를 위한 101개의 정책과 절차를 만드는 시간은 3,771시간이 필요해서 CMMI 레벨이 없는 조직을 CMMI 레벨3까지 끌어올리는 총 시간은 5,862시간이고 비용은 $100을 곱해서 $586,200입니다. 이 것은 전체 소프트웨어를 만드는데 필요한 시간으로 코드 작성까지를 전체 프로세스의 반으로 생각할 때 비용은 $293,100입니다.

2. CMMI를 수행했다는 산출물 작성 비용 (CMMI Evidence of Use)

CMMI를 레벨에 맞게 제대로 수행했다는 증거를 위한 산출물 작성 비용은 다음과 같습니다.

(이 것은 참고 문헌의 Rico[8]을 보십시오)

CMMI 레벨2는 138개의 산출물을 작성하기 위해서 10,304시간이 필요하고 레벨3의 275개의 산출물을 작성하기 위해서 20,533시간이 필요합니다. 총 산출물 작성 시간은 30,837시간이 마찬가지로 시간당 인건비 $100을 곱하면 총 비용은 $308,370입니다. 이 것도 코드 작성까지를 전체 프로세스의 반으로 본다면 비용은 $1,541,850이 됩니다.

3. CMMI 적용 비용 (CMMI Implementation Costs)

CMMI 정책과 절차를 적용하기 위한 비용과 산출물 작성 비용을 합하면 $293,100 + $1,541,850이 되어 총 $1,834,950이 됩니다.

4. CMMI 심사 준비 비용 (Assessment Preparation Costs)

심사를 준비하기 위해 20개의 Indoctrination (평가를 위해 사전 교육 과정 정도로 볼 수 있겠습니다)이 각 2시간씩 필요하고 이 것을 조직 구성원 40명에게 수행해야 하기 때문에 20×2×40이어서 1,600시간이 필요합니다.

그리고 각 2시간씩 필요한 20개의 response conditioning 코스도 40명에게 수행해야 하기 때문에 20×2×40이어서 1,600시간이 또 필요합니다.

또한 예비 심사 (mock assessment)를 각 구성원이 40시간씩 수행해야 하기 때문에 추가로 1,600시간이 더 필요합니다.

총 심사 준비 비용은 Indoctrination과 response conditioning 코스 그리고 예비 심사를 더하면 4,800시간이 되어 $480,000이 됩니다.

이 또한 전체 프로세스에 드는 비용이어서 코드 작성까지를 전체 프로세스의 반으로 본다면 $240,000이 됩니다.

5. CMMI의 적용과 심사 준비를 위한 총 비용

CMMI 정책과 절차를 적용하고 필요한 산출물을 만들고 심사를 준비하기 위한 비용은 $293,100 + $1,541,850 + $240,000이 되어서 $2,074,950이 됩니다.

6. 심사 비용 (Assessment Cost)

※David F. Rico가 잘 못 쓴 것 같은데 CMMI 적용 부분에서는 4개의 프로젝트를 각 10명 수행하는 것으로 CMMI 적용과 심사 준비 비용을 산출하다가 여기서 잠시 4개의 프로젝트를 5명이 수행하는 것으로 계산을 하고 있습니다. 이 부분도 메일을 보내볼까 생각 중입니다.

CMMI 심사 비용은 다음과 같이 산출됩니다.

CMMI 심사를 위해 계획을 하고 평가 단계 (appraisal stage)준비를 위해 636시간이 소요되며 평가 단계 (appraisal stage)를 수행하기 위해 1,018시간이 필요합니다. 그리고 보고 단계 (report stage)를 위해 106시간이 들어서 총 1,760시간이 예상되어 시간당 인건비 $100을 곱하면 $176,000이 필요합니다.

여기에 심사 비용 $64,615가 추가되면 총 심사 비용은 $240,615가 됩니다.

7. CMMI를 위한 총 투자 비용

CMMI 적용과 심사 준비 비용에 심사 비용을 더하면 $2,074,950 + $240,615가 되어 $2,315,565가 총 투자 비용이 됩니다.

8. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

CMMI 레벨3인 조직의 Inspection을 통한 코드 작성 이후 유지.보수 시간의 절감은 SLOC 10,000 소프트웨어에 대해 27,867시간입니다. 4개의 프로젝트이므로 4×27,867이 되어 총 111,466 (※ 곱하기가 좀 이상하지만) 시간이 유지.보수 시간에서 절감됩니다.

또한 CMMI 레벨3인 조직은 그렇지 못한 조직에 비해 SLOC 10,000 소프트웨어에 대해 2,544 시간을 코드 작성에서 줄일 수 있습니다. 이 것을 4개의 프로젝트로 확산하면 10,176시간이 코드 작성 시간에서 절감됩니다.

유지.보수 시간의 절감된 시간과 코드 작성의 절감된 시간을 더하면 111,466 + 10,176이 되어 121,642시간이 총 절감되어 비용은 $12,164,200이 됩니다.

5. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $12,164,200 / $2,315,565 = 5.25이어서 5:1이 됩니다.

6. ROI%

이익 – 총 비용 / 총 비용 × 100 은 ($12,164,200 – $2,315,565) / $2,315,565 × 100 = 425%입니다.

각 방법론 비교 표

위에서 Inspection, PSP, TSP, SW-CMM, ISO9001, CMMI의 투자 비용과


  교육 수행 총 비용 이득 B/CR ROI%
Inspection 11,240 70,833 82,073 2,999,400 37:1 3,555
PSP 105,600 40,000 145,600 4,664,600 32:1 3,104
TSP 148,400 163,400 311,800 4,525,400 14:1 1,351
  적용 심사        
SW-CMM 710,500 140,000 850,500 12,164,200 14:1 1,330
ISO9001 218,396 112,000 330,396 2,772,600 8:1 739
CMMI 2,074,950 240,615 2,315,565 12,164,200 5:1 425

어느 정도 예상했던 결과가 나옵니다.

  • Inspection이 이득은 가장 낮지만 투자 비용이 훨씬 낮아 ROI가 가장 높습니다.
  • CMMI가 Inspection에 비해 4배 가까이 이득이 높지만 총 비용이 30배 이상 들어서 가장 ROI가 낮습니다.

생각해보기

1. 그들을 먼가 정직하게 하고 있다.

Inspection이 적은 투자 비용으로 큰 효과를 볼 수 있어 ROI가 가장 높다는 자명한 결론 이전에 생각해볼 것은 “그들은 정말 제대로 한다” 입니다.

10,000 SLOC의 소프트웨어를 한 번 인스펙션 할 때 보는 코드 라인수가 240줄입니다. 그래서 41.67번의 미팅이 필요했다고 합니다. 그러면 240줄을 한 시간 동안 준비하고 인스펙션하고 수정할까요? 아닙니다. 한 번의 인스펙션을 위해 소요되는 시간을 17시간으로 잡고 있습니다.

당신의 상사가 그리고 동료 또 부하직원이 240줄을 인스펙션 하기 위해 17시간을 소요하고 있다는 것이 상상이 될까요?

논문이니깐… 이라고 생각될 수 있지만 저자와 제출처 등 논문의 명성을 보면 꼭 그렇게 생각할 수도 없습니다.

2. Measurement의 중요성

측정 (Measurement)을 제대로 해야 평가 (Assessment)도 제대로 하고 예측 (Estimation)도 할 것입니다. “정말 이런 내용들을 다 측정했을까”라는 생각이 될 정도로 많은 항목들을 일관성과 목적을 가지고 제대로 측정한 것 같습니다. 그래서 유명한 논문이 나왔겠죠.

※ 논문의 본 주제로 잠시 돌아가겠습니다.

3. 낮은 비용과 리스크가 적은 것을 선택

인스펙션이나 PSP가 좋은 예가 될 것입니다. 효과 (returns) 극대화를 생각하기 이전에 실패할 수도 있다는 위험 (risk)를 고려한다면 낮은 비용으로 투자를 하는 것이 안전할 것입니다. 모든 방법이 모든 과제와 상황에 성공한다는 보장은 없을 것입니다.

CMMI를 주창해서 도입하고 2백만 달러가 넘는 돈을 투자하고 실패한다면? 상상하고 싶지 않을 것입니다.

4. 비용 집약적인 것을 피하라

이 논문은 인스펙션을 광고하기 위한 논문은 아니지만 낮은 비용으로도 높은 이득 (returns)을 볼 수 있다는 것을 보여줌으로써 비용에 허덕이는 조직에게 단비와 같은 근거를 마련해줍니다.

References

논문에서 사용한 참고 문헌들 입니다.

[1] Rico, D. F. (2002). Software process improvement: Modeling return on investment (ROI). 2002 Software Engineering Process Group Conference (SEPG 2002), Phoenix, Arizona and 2002 International Conference on Software Process Improvement (ICSPI 2002), Washington D.C. http://davidfrico.com/sepg02.pdf http://davidfrico.com/dacs02.pdf

[2] Rachlin, R. (1997). Return on investment manual: Tools and applications for managing financial results. Armonk, NY: M. E. Sharpe.

[3] Rico, D. F. (2000). Using cost benefit analyses to develop software process improvement (SPI) strategies (Contract Number SP0700-98-D-4000). Rome, NY: Air Force Research Laboratory—Information Directorate (AFRL/ IF), Data and Analysis Center for Software (DACS). http://www.dacs.dtic.mil/techs/abstracts/rico.html

[4] Humphrey, W.S. (2000). The team software processsm (TSPsm). (CMU/SEI-2000-TR-023). Pittsburgh, PA: Software Engineering Institute.

[5] Rico, D. F. (n.d./2001). SEI level 2 thru 5: Cost model [WWW document]. URL http://davidfrico.com/sw-cmm-costpdf.htm

[6] Diaz, M., & Sligo, J. (1997). How software process improvement helped motorola. IEEE Software, 14( 5), 75-81.

[7] El Emam, K., & Briand, L. C. (1997). Costs and benefits of software process improvcment (IESE-Report 047.97/E). Kaiserslautern, Germany: University of Kaiserslautern, Fraunhofer-Institute for Experimental Software Engineering.

[8] Rico, D. F. (n.d./2001). Capability maturity model integration: CMMI introductory overview [WWW document]. URL http://davidfrico.com/cmmipdf.htm

[9] Carnegie Mellon University (2001). Standard CMMISM appraisal method for process improvement (SCAMPISM), Version 1.1: Method definition document CMU/SEI-2001-HB-001. Pittsburgh, PA: Software Engineering Institute (SEI).

MS에서는 테스터를 SDET라고 부른다.

18 Comments

지난 몇 주 동안 VC++ 팀 블로그의 포스트들을 정리해서 소개해드렸습니다. 주로 소프트웨어 테스트 관련된 글들이었습니다.


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

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

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

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

VC++ 팀 블로그에서 처음 보는 용어를 보고 이 포스트를 작성하게되었습니다.

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)

i_t_st.gif테스트는 소프트웨어 개발 프로세스에서 제품의 품질을 향상시키고 고객의 니즈 (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++ 팀 블로그에 게재되는 글들을 통해 그들의 테스트 활동을 엿보면, 마이크로소프트의 위 글이 절대 말뿐인 것은 아님을 알 수 있습니다.

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

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

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

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

6 Comments

이번에 소개해 드릴  MS의 Visual C++팀 블로그의 내용은 VC++ 라이브러리 개발팀의 리더인 Ale Contenti의 빌드 프로세스에 관한 글입니다.

(※ 바르셀로나에서 11월5일부터 시작하는 TechEd에 참가하기 위해서 그 전에 휴가를 내서 이탈리아에 있으면서 포스트를 했다는군요. 글을 쓴 것은 11월1일입니다. 부럽습니다. -_-)

※ Check-in은 ClearCase와 같은 소스 코드 형상 관리 (Source code Configuration Management, SCM) 도구에서 코드를 수정하기 위해서 Check-out (“나 지금 이거 고치고 있소” 라고 알리는 행위, lock과도 조금 유사한)을 하고 수정 후 서버에 있는 소스에 반영하는 행위입니다. 여러 사람이 코드에 접근해야 하니 이와 같은 절차가 필요하겠죠. ClearCase가 이 과정이 엄격하다면 SVN과 같은 경우는 자유롭지만 책임이 따른다고 해야겠죠. 아무튼…

Visual Studio의 대부분은 VC++ 라이브러리 팀에서 매일 밤 9시부터 빌드되어진다고 합니다 (금요일과 토요일은 제외라는 군요). 이전에 소개해드린 VC++ 팀의 포스트를 보면 MS VC++ 팀은 매일 빌드하고 매일 테스트를 하니 당연하겠죠.

VC++ 라이브러리들은 Visual Studio의 다른 부분들이 사용하는 것이기 때문에 가장 먼저 빌드됩니다.

IDE이니 가장 먼저 생각되는 라이브러리는 C-Runtime (CRT) 라이브러리일 것입니다. #include <stdio.h>와 같이 사용되는 것들이겠죠? 이 CRT 라이브러리는 다음과 같이 세 가지 파트로 나누어져 있습니다.

- 라이브러리 헤더 파일 (위에서 예로 든 stdio.h)

- 라이브러리 (msvcrt.lib)

- DLL들 (msvcr90.ll)

라이브러리 팀에서는 위의 것들을 빌드해서 바이너리 폴더에 복사해서 릴리즈한다고 합니다.
그리고 헤더 파일들과 라이브러리는 VC++ 컴파일러인 cl.exe나 C# 컴파일러인 csc.exe등과 같이 Visual Studio의 다른 모듈들이 라이브러리 헤드 파일과 라이브러리를 이용해서 컴파일 될 수 있게 또 다른 폴더로 복사되다고 합니다.

※ 흔히 중.대형 프로젝트에서 라이브러리들을 빌드하는 과정과 유사할 것입니다.

아무튼 이와 같이 VC++ 라이브러리들은 다른 모듈들이 의존성 있게 항상 사용되기 때문에 다음과 같은 특성을 가집니다.

- 대부분의 Visual Studio 모듈들은 항상 최신 VC++ 라이브러리 (CTR, STL, ATL, MFC)를 가지고 빌드됩니다.

- 대부분의 Visual Studio 모듈들은 실행 시에 최신 VC++ DLL들을 로딩하게 됩니다.

- VC++ 라이브러리에 통합이 일어나면 이것은 모든 나머지 Visual Studio 모듈에 영향을 주게 됩니다.

- VC++ 라이브러리 헤더 파일과 라이브러리의 모든 변경은 다른 모듈들이 올바르게 빌드되고 동작할 수 있기 위해서 주의 깊은 테스트가 필요하게 됩니다.

이와 같이 아주 중요한 VC++ 라이브러리의 Check-in이 다른 모듈들에게 문제를 일으키지 않게 하기 위해서 VC++ 라이브러리 팀들은 Check-in 시 다음과 같은 과정을 거친다고 합니다.

- 방대한 Regression (회귀) 테스트

- 테스트를 통과했고 빌드에 문제가 없는지를 자동으로 확인하는 check-in 시스템 (각주1 참고)

코드 변경 시 관련된 유닛 테스트 케이스도 수정이 일어나며 Regression 테스트도 업데이트시킵니다.

자동화 check-in 시스템은 20개 이상의 머신을 통해서 다른 Visual Studio 모듈들을 빌드해보고 수 많은 테스트 케이스를 수행한다고 합니다. 모든 것이 문제가 없다고 판단될 때 자동화 시스템은 (그들은 이 것을 “the gauntlet (건들렛)” J라고 부릅니다) check-in을 수행하고 check-in 관련 메일을 발송한다고 합니다.

이 전글들에서도 소개 드렸지만 MS의 테스트 케이스는 상상을 초월하게 많습니다. (IDE 팀의 8개 test suite 중 1개의 test suite이 가진 테스트 케이스가 2만개 정도라고 하니…)

check-in 시 마다 많은 테스트 케이스를 20개의 머신에서 수행한다고 하니 – 물론 자동화되었다고는 하지만 – 극성처럼 보일 수도있을 겁니다.

하지만 그런 꼼꼼한 확인이 없다면 라이브러리를 다른 모듈들이 안전하게 사용할 수 없을 것입니다.

한 개의 컴포넌트에서 발생한 문제를 찾고 수정하는 시간이 그런 컴포넌트 10개가 모인 상태에서 문제를 찾고 수정하는 시간의 1/10이 아니라 그 것보다 훨씬 많기 때문이겠죠.

여러분! 여러분은 당신의 모듈 (라이브러리 더 나아가 프로그램)을 사용하는 유저를 위해 얼마나 자신의 모듈을 테스트하시는지요?

저 자신부터 부끄러워집니다.

각주 1: Visual Studio Team System

자동 check-in 시스템은 이미 MS Visual Studio Team System에 도입되어 사용되어지고 있습니다.

check-in 시 원하는 확인 작업을 자동으로 수행해줍니다. 지정된 테스트 케이스가 자동으로 수행할 뿐만 아니라 팀의 코딩 스탠다드 체크까지 해주는 것으로 알고 있습니다.

Older Entries