How To Design Practical Test Cases by Tsuneo Yamaura (1998, IEEE Software)

Howtodesignpracticaltestcases_Yamaura(IEEE, 1998).pdf

* 역자주: IEEE 소프트웨어 잡지에 이런 내용이 실리는 것에 대해서 참으로 놀라울 따름이다. 내용이 거의 소프트웨어 테스팅의 핵심 및 중요한 부분을 모두 망라하는 아티클이다! 내가 최초에 이런 아티클을 어떻게 알게 되었냐면, 그나마 소프트웨어 공학 책중에서 가장 깔끔하게 번역되고 원전에 충실한 이안 썸머빌의 "소프트웨어 공학 제 7판"에서다. 이 책의 pp. 531을 보면 레퍼런스에 언급되어 있다. 여기에 뭐라고 나와있나면...

 결점이 거의 없는 소프트웨어를 인도하는 데 매우 좋은 평판을 가지고 있는 일본 기업으로부터 시험 사례 설계 방법을 다룬 논문이다. (T. Yamaura, IEEE Software, 15(6), November 1998.)

아, 이 얼마나 극찬의 얘기인가! 이 사실에서 (물론 번역을 해보니 정말 그렇지만) 알 수 있는 건 다음과 같다고 생각한다.

1. IEEE에 소프트웨어 테스팅 주제로 글이 실린다. (누가 IEEE 소프트웨어 과월호를 가지고 계신 분이 있다면 연락 바란다. 갠적으로 친하게 지내고 싶다! ^^)
2. 일본 기업도 소프트웨어 테스팅에서 유명한 저명 인사는 없지만 실제적으로 매우 핵심과 이론들을 잘 사용하고 알고 있다.
3. 이안 썸머빌 같은 유명한 공학 교수가 자기 책에 인용할 정도로 대단하다.
4. 역시 모국어로 영어를 쓰는 사람들이 아닌 제 3 국인의 영어는 그나마 번역하기 참 평이하다. ^^

번역을 위해 잠도 안자고 여러 날을 고생했다. 고생한 역자를 생각해서 이글을 보는 분들은 다음의 내용을 지켜주셨으면 한다.

* PDF 자체는 역자가 인터넷에서 찾은 것으로 누군가 스캔을 한 것을 PDF화 한 것 같다. 이것을 재배포하는 것은 여러분들의 맘이겠지만, 번역을 해놓은 글을 다른 곳에 옮겨다 두거나 심지어 자기가 한 것처럼 하는 행동은 하지 않으셨으면 한다. (솔직히 나 이거 번역하느라 고생 많았다. ^^)
* 어딘가 번역한 내용을 옮기고 싶은 충동이 강하게 들때는 꼭 역자인 쥔장에게 문의바란다. (아니면 번역한 것 보지 않고 본인들이 직접 번역하시든지... ㅋㅋ)
* 번역한 내용을 옮기는 경우 원전 표기를 지켜 주십사 당부 드린다.

자 아래에 번역 나가신다~~

How To Design Practical Test Cases by Tsuneo Yamaura, 1998 IEEE

pp. 30

히다치 소프트웨어에서 우리 소프트웨어는 프로그램 내부의 모든 버그중 0.02 퍼센트만이 유저 사이트에서 발생하는 그런 놀라운 품질을 가졌었다. 한 개의 전형적인 프로젝트가 - 100,000 라인의 코드를 개발하기 위해 12달동안 10명의 엔지니어들이 작업하는 - 1,000개의 버그를 내재한다면, 최대 한개는 유저 사이트에서 드러날 것이다. 우리는 현대적인 툴이나 예술적인 방법론을 사용하지 않았다. 오히려 단순히 프로그램을 테스트하고 발견된 버그를 수정했을 뿐이다.

우리의 비밀은 디버깅과 테스팅을 시작하기 전에 모든 테스트 케이스들을 문서화한 것이다. 미리 작성된 테스트 케이스들은 놀라운 이득을 제공하는데, 우리의 모든 품질 보증 활동은 이 시점에서 시작한다.

그림 1은 1990년의 히다치 소프트웨어 개발 프로젝트의 각각의 단계에서 발견된 버그의 비율을 나타낸다.(좀더 최근의 데이터는 계속 수집중이지만, 이것과 극적인 차이를 보이지는 않을 것이다.) 프로젝트의 시작 이후 발견된 모든 버그중 단지 0.02 퍼센트가 고객의 사이트에서 드러났다. 그러한 높은 품질은 우리가 미리 작성된 테스트 케이스를 운용하지 않았다면, 달성할 수 없었을 것이다.

그림 1. 1990년도 프로젝트의 개발 단계 동안의 버그 발견

DOCUMENTING TEST CASES

문서화된 테스트 케이스들은 몇가지 중요한 점에서 당신의 개발 프로세스에 이익이 될 수 있다.

• 테스트 케이스의 디자인과정은 또 다른 관점에서 스펙을 분석할 수 있는 기회를 제공한다.
• 동일한 테스트 케이스들을 반복할 수 있다.
• 누군가 다른 사람이 당신을 위해 테스트 케이스들을 수행할 수 있다.
• 당신은 쉽게 테스트 케이스들의 품질을 검증할 수 있다.
• 당신은 초기에 목표 소프트웨어의 품질을 추정할 수 있다.

A new viewpoint

테스트 케이스들은 기능적인 스펙의 또 다른 해석을 제공한다. 테스트 케이스를 디자인하는 것은 잠시간의 생각할 여지를 제공할 것인데 말하자면 다음과 같은 것이다. "아하, 내가 이런 저런 조건들을 고려하지 않았었구나. 그 스펙이 정말로 옳은 걸까?" 이런 방식으로 드러난 버그는 찾아내기 더 어렵거나 시스템 통합 단계 같은 이후 단계에서는 수정하는데 많은 시간과 비용이 필요할 것이다. 대략, 당신은 테스트 케이스를 디자인하면서 시스템의 버그의 10퍼센트를 잡아낼 수 있으며, 이것이 놀라운 이득이다.

Repeating test scenarios

당신은 모든것이 문서화되어 있다면, 쉽게 어떤 테스트 케이스들을 재반복할 수 있다. 테스트 케이스의 재사용은 버그를 재현하게하며, 이것은 발견된 버그가 올바르게 수정되었는지에 대해 확신을 가지는데 도움이 된다.

Passing the test along

당신이 테스트 조건, 입력 데이터 세트, 기대 결과을 명세화한다면, 누군가 다른 사람에게 테스트를 수행하도록 요청할 수 있다. 이것은 프로젝트 진행이 늦어진 경우에 특히 가치가 있는 것으로 판명될 것이다. 추가적인 프로그래머를 프로젝트에 추가하는 것은, 종종 스케줄을 늘어지게 하여 더 많은 지연의 원인이 된다. 왜냐하면, 그 프로젝트 엔지니어들은 새로운 투입 인원을 교육시키기 위해 소중한 시간을 들여야 하기 때문이다. 만일 테스트 케이스들이 올바르게 문서화되었다면, 새로 투입된 인원은 작성된대로 테스트 케이스들을 수행할 수 있다.

Validating test case quality

물론 당신은 소프트웨어에 구현된 모든 기능이 수행되었는지 확신하기 위해 테스트 케이스들을 테스트해야 한다. 또한, 그 테스트 케이스들이 정상, 비정상, 경계 케이스등 간에 잘 균형잡혀 있는지 점검하고, 그들의 전체적으로 충분한지 평가해야 한다. 임의나 랜덤 테스팅으로는 충분치 않을 것이다. 말하자면, 당신이 명확하게 테스트 케이스들을 문서화하지 않는다면, 당신은 그들의 품질 메트릭과 성공을 정확하게 평가할 수 없다.

Estimating software quality

만일 테스트 케이스들이 올바르게 개발되었다면, 연못속의 물고기와의 유사점을 적용함으로써 디버깅 동안에 목표 소프트웨어의 품질을 쉽게 추정할 수 있다. 즉, 당신이 1000개 중 100개의 테스트 케이스들을 수행한 이후에 4개의 버그를 발견했다면, 상식적으로 소프트웨어는 전체적으로 약 40개의 버그를 지니고 있을 것이다. 예술적인 수준의 소프트웨어 신뢰성 이론은 간단치 않다. 하지만 이런 방법은 빠르고 쉬운 추정은 소프트웨어의 품질에 대한 대강의 아이디어를 제공한다.

SCHEDULE, COST, AND PERSONNEL

당신은 이제 테스트 케이스들을 문서화하는 것이 얼마나 유용한 것인지 알았을 것이다. 하지만, 모든게 공짜는 없다. 당신은 이익을 누리기 위해서 시간, 비용, 인원을 투자해야 한다. 관건은 당신이 필요한 것이 어느정도냐 일 것이다. 여기에 약간의 통계적인 데이터를 가지고 대강의 아이디어를 설명한다.

그림 2. 매트릭스 기반의 테스트 시트.

100,000라인의 코드를 가진 C 기반의 소프트웨어를 개발하는데 10명의 엔지니어가 평균 12개월 동안 작업을 해야하는 프로젝트를 가정하면, 평균적인 프로젝트는 다음의 단계들에 12개월을 배분할 수 있다.

• 요구사항 명세화: 2달
• 디자인: 3달
• 코딩: 2달
• 디버깅: 3달
• 테스팅 (QA팀에 의해 수행): 2달

히다치 소프트웨어에서는 프로젝트가 디버깅을 완료하면, 그 제품은 QA 부서로 보내져서, 약 2달을 사용하여 그 소프트웨어가 출시할만한가를 평가받게 한다. 테스터들이 치우침이 없고 고객의 요구사항을 이해해야 하기 때문에, 그들은 프로그래머들의 테스트 수트를 결코 재사용하지 않고, 오히려 원점에서 모든 테스트 아이템들을 재디자인한다.

테스트 케이스 밀도 즉, "얼마나 많은 테스트 케이스들이 필요할까?"는 테스팅에서 가장 중요한 엔지니어링 이슈중 하나 이다. 너무 적은 테스트 케이스들은 손쉬운 버그들을 못 찾게될 것이고, 너무 많은 테스트 케이스들은 시간의 부족을 불러올 것이다.

시행착오에 근거한 우리의 30년간의 경험적인 연구에서 적절한 테스트 케이스 밀도는 10에서 15개의 LOC당 하나의 테스트 케이스의 수준으로 모아졌다. 이것은 100,000 LOC의 제품이 약 10,000개의 테스트 케이스들을 필요로 하며, 프로그래머당 1,000개를 의미한다. 1,000개의 테스트 케이스들 중 약 100개는 코드 인스펙션 단계에서 체크될 것이고, 그들 전체는 머신 디버깅 단계에서 체크될 것이다. (이것의 의미는 코드 인스펙션 단계에서의 첫번 100개의 테스트 케이스는 머신 디버깅과 중복된다.) 우리의 연구에 기초할때 이러한 숫자들은 비현실적인 것으로 보이지 않는다. 평균적인 프로그래머는 코드 인스펙션 단계에서 100개의 테스트 케이스들을 수행하는데 2주일이 걸린다. (하루에 10개 케이스) 그리고 머신 디버깅 단계에서 1,000개의 테스트 케이스들을 수행하는데 2달이 걸린다. (하루에 25개 케이스) 열명의 프로그래머가 테스트 케이스들을 디자인하는 데는 2주일이 걸릴것이다. (프로그래머당 하루에 100개의 테스트 케이스를 가정) 이것은 전체 프로젝트에서 2.8퍼센트에 해당한다.

STEPS FOR DEBUGGING AND TESTING

시스템적인 테스팅은 6개의 핵심 절차들을 따른다.

1. 테스트 케이스들의 집합을 디자인한다.
2. 테스트 케이스들을 체크한다.
3. 테스트 케이스를 기초로 코드 인스펙션을 수행한다.
4. 테스트 케이스를 기초로 머신 디버깅을 수행한다.
5. 디버깅 동안에 품질 관련된 데이터를 수집한다.
6. 디버깅 동안에 데이터를 분석한다.

Designing test cases

테스트 케이스를 디자인하는데 유일한 한가지 규칙이 있다. 모든 기능을 커버해야 하지만, 너무나 많은 케이스들을 만들지 말라는 것이다. 우리는 매트릭스 기반의 테스트 시트를 사용해 필요한 모든 기능을 수행해 보았고, 동치 분할과 경계값 분석을 적용해 중복적인 테스트 케이스들을 제거했다. 필요할 때는 상태 변이 모델, 결정 테이블, 데이터흐름 모델에 기반한 다른 테스트 방법도 사용했다.

그림 2는 우리가 적용한 매트릭스 기반의 테스트 시트를 나타낸다. 첫째 단계는 모든 조건들을 아이템화하고 그 다음 가능한 모든 조합들을 고려하는 것이다. 이런 단계는 중요한 결점들을 드러나게 하는데, 왜냐하면 이런 방식으로 테스트 케이스들을 디자인하는 것은 또 다른 모델에 기초해서 소프트웨어를 재디자인하는 것을 의미한다. 말하자면, 결정 테이블인 것이다.

그림 1의 모든 테스트 케이스는 테스트 디자인을 하는 동안에 버그를 드러내지 못하는 것을 제외하고는 각각의 기대 결과들을 가지고 있다는 것을 주목하라. 또한 당신은 테스트 케이스가 정상, 비정상, 경계 케이스들을 체크하는지에 대해서 명시할 필요가 있다. 이것은 테스트 케이스들의 품질을 평가하는데 필수적이다. 그리고 당신은 테스팅 순서를 나타내는 테스팅 우선순위를 명시해야 한다.

1970년대 초반에 우리는 테스트 케이스의 단계조건을 기술하는데 자연어를 적용했다. 예를 들면,

• 양식에 있는 사람이 65세이거나 더 많을때:
• 사람의 연간 수입이 $10,000 또는 적을때:
• 사람이 A-1지역에 살때: ... (조건들의 중첩이 더 깊어진다)

이러한 접근법은 종종 우리로 하여금 다양한 조건의 조합(또는 테스트 아이템간에 놓침)을 간과하게 만들었다. 우리는 1970년대 중반부터는 매트릭스 기반의 테스트 디자인으로 이전했다.

동치 분할로 잘 알려져 있는 테스팅 기법은 동일 도메인을 대표하는 단일한 값을 사용하는 것이다. 나이에 따른 입장료의 예를 들면, 6세이하는 입장료를 받지 않으며, 12세까지는 $5, 18세까지는 $8 그리고 19세 이상은 $10이라고 가정하자. 각각의 도메인에서 당신은 도메인 0<=age<=6에 대해서는 "2세", 도메인 6<age<=12는 "10세", 도메인 12<age<=18은 "14세", 도메인 18<age에는 "43세"의 테스트 케이스들을 선정할 수 있을 것이다. "43세"와 "50세"를 선정하는 것은 각각이 화이트박스 테스팅에 대해서 서로 다른 도메인을 나타내는 경우 이외에는 과도한 것이다.

경계값 분석은 잘 알려져 있는 또 다른 테스팅 기법으로 버그들이 도메인의 경계에 존재하는 경향이 있다는 아이디어를 근거로 한다. 따라서, 위의 입장료 예에서는 -1, 0, 6, 7, 12, 13, 18, 19의 나이를 테스트할 필요가 있다.

우리는 경험적인 연구를 통해 아래와 같은 테스트 케이스 디자인 기준 (또는 교훈)을 도출하였다.

• 앞에서도 언급했듯이 테스트 케이스의 최적화되고 실용적인 밀도는 10에서 15 LOC당 한개이다. 일반적으로 언어 처리기는 배치 프로그램보다 더 많은 테스트 케이스들을 필요로 한다.(12 LOC 당 약 한 개의 테스트 케이스) 그리고, 온라인 프로그램은 언어 처리기보다 더 많은 수를 필요로 한다. (10 LOC당 한 개)
• 화이트 박스 테스팅의 관점에서는 IF 구문의 숫자가 LOC 보다 더 나은 지표를 제공한다. 왜냐하면, 이것이 프로그램 내의 실행 가능한 경로의 숫자와 직접적으로 연관되어 있기 때문이다. 가장 에러가 잘 유발되는 구조는 루프이다. 화이트 박스 테스팅에서 당신은 0, 1, 2, 평균적인 숫자, max-1, max, max+1개의 횟수로 반복을 테스트해야 한다.
• 기본적이고 정상적인 케이스들은 전체 테스트 케이스들 중에 60퍼센트 이하를 구성하고, 경계나 제한 케이스들은 10퍼센트 미만, 에러 케이스들은 15퍼센트 그리고 환경적인 테스트 케이스들(다른 OS에서는 프로그램이 어떻게 동작하는지, 성능 요구사항)은 15퍼센트를 구성해야 한다.
• 마지막 점검으로서 우리는 48시간 지속운용 테스트를 수행했다. 당신이 제공해야 하는 모든 것은 동일한 기본 기능들을 무한히 재반복하는 테스트 수트이다. 이러한 테스트는 메모리 릭, 데드락 그리고 연결 타임아웃과 연관된 많은 버그들을 드러나게 한다.

그림 3. 테스트 수행과 버그 발견의 예

몇가지 팁이 당신이 성공적이고 효과적으로 테스트 케이스들을 디자인하는데 도움이된다.

• 너무 많은 테스트 케이스들을 디자인하지 말라. 특히 문법 테스팅(syntax testing)에 그렇다. 만일 당신이 12개중 6개 파라메터의 에러 조합을 고려하고 있다면, 최종적으로는 수천개의 테스트 케이스들을 겪게될 것이다. 이것은 수행하는데 몇 달이 걸릴수도 있다. 현실은 누군가(대부분은 당신이 되겠지만)가 테스트를 수행해야 한다는 것이다. 이런 상황을 고려하고 디자인하면 계획된 기간 안에 완료될 수 있을 것이다.
• 유사한 소프트웨어가 개발되었던 이전 프로젝트를 참조하라. 그 프로젝트가 테스트 수트를 가지고 있다면, 반드시 무슨일이 있더라도 그것을 획득하라. 당신이 그것들을 재사용할 수 없을지라도, 당신에게 통찰력을 제공해 줄 것이다.
• 당신이 어떤 테스트 케이스들을 코드 인스펙션 단계에서 실행할 것인지, 머신 체킹 단계에서는 어떤 테스트 케이스들을 실행할 것인지 지정하라. 코드 인스펙션에서는 전체 테스트 케이스들중 약 10퍼센트만 사용하는 것을 추천한다. 이렇게 되면, 소프트웨어의 주요한 지점들을 추적하기 시작하는데 도움이 된다.
• 소프트웨어 엔지니어는 본인들이 잘 알고 있는 기능들에 대해서는 너무 많은 테스트 케이스를 만들고, 친숙하지 않은 기능들에 대해서는 너무 적게 만드는 경향이 있다. 이런 수치가 비정상적인 것인지 판단하기 위해 LOC에 기반하거나 IF문들의 수를 가지고 테스트 케이스 수와 비교하라.

Checking test case quality

테스트 케이스들은 당연히 테스트되어야 한다. 당신의 테스트 케이스 디자인이 완료되면, 그것의 정확성과 적절성을 다음에 근거하여 평가한다.

• 테스트 케이스들이 모든 기능들을 커버하는가
• 정상, 비정상, 경계 그리고 환경적인 테스트 케이스들 간의 균형이 맞는가
• 코드 인스펙션(제공하기 어려운 조건들에 대한 체크 그리고 쉽고 효율적으로 수정할 수 있는 버그들의 발견을 가능하게 하는)과 머신 실행(테스팅 시간을 소모하는)간의 균형이 맞는가
• 블랙 박스와 화이트 박스 테스팅 간의 균형이 맞는가
• 기능적인 테스트와 성능 테스트 간의 균형이 맞는가

Code inspection

우리의 경험적인 연구는 모든 버그중 21.5퍼센트가 이 단계에서 발견되었다고 나타낸다. 이 전체 숫자중 나는 대강 코드 인스펙션에서 절반, 테스트 케이스 디자인 과정에서 나머지가 드러났다고 추정한다. 코드 인스펙션에서와 마찬가지로 테스트 케이스들 중 10퍼센트를 체크하기 위해 디버깅 시간의 25에서 33퍼센트를 할당하는 것을 권장한다.

이 단계에서 발견된 결점들을 기록한다. 이것은 어떤 버그들이 수정되지 않고 남아 있는지, 어디에, 어떤 유형의 버그가 될 것인지, 어떤 모듈이 더 많은 결점을 지니고 있는지를 말해줄 것이다. 당신이 테스트 케이스들을 성공적으로 수행했다면, 완료한 날짜를 테스트 케이스 시트에 기록한다.

그림 4. 테스트 진행의 분석

Machine debugging

이 단계는 간단하다. 단지 실제 머신(또는 시뮬레이터)에서 테스트 케이스를 수행하고 그 결과 기록이 통과인지 실패인지 유지하는 것이다. 테스트 케이스가 하나의 결점을 드러냈다면 누가 무엇을, 언제, 버그의 증상, 그리고 테스트 케이스 ID와 같은 정보를 기록하여 버그 리포트를 완성한다. 이러한 정보 없이는 버그가 출현할 때까지 이미 수정된 버그라고 생각하게 될 것이다.

머신 디버깅을 시작하기 전에, 가능하다면 테스트 수트로서 테스트 케이스들을 구현한다. 테스트 수트란 자동적으로 테스트 케이스들을 수행하고 실제 결과와 기대 결과를 비교하여 "통과"인지 "실패"인지를 판단해 주는 프로그램이다. 이것은 많은 이점을 제공한다. 비록 테스트 수트 구현에 시간이 걸려도(테스트 수트의 엔진의 작업량은 작다. 작업중 95퍼센트 이상은 실행 커맨드의 제공과 기대 결과를 정의하는데 사용된다.) 당신이 자리에 없는 동안 컴퓨터가 프로그램을 디버그하도록 함으로써 한 번 완성되고 나면, 대단히 많은 시간이 절약된다. 멍청하지만 비용이 많이드는 타이핑 에러들은 완전히 제거될 수 있고, 당신이 최종 출시 일자를 맞춰야 하는데 프로그램은 여전히 변경되고 버그 수정되어야 할 때, 소프트웨어 개발의 마지막 단계에서 기능적인 악화를 체크하는 도구로서 테스트 수트를 사용할 수 있다.

테스트 수트를 구현할 때 기억해야 할 중요한 한가지 사실은, 다음 테스트 케이스로 넘어갈 때 모든 데이터가 재초기화 되었는지 확인해야 한다는 것이다. 하나의 테스트 케이스가 실행되지 않았다면, 이전 케이스의 버그가 테스트 수트를 종료시켰기 때문이다. 앞부분의 버그가 이어지는 버그를 가려버릴 수 있다. 그리고 이러한 것들은 이전 버그가 완전하게 수정되지 않으면 드러나지 않을 것이다.

Collect data for quality analysis

문서화된 테스트 케이스들의 유용성을 극대화하기 위해서는 발견된 모든 결점들의 기록을 유지해야 한다. 그들의 증상, 심각성, 누가 발견했는지 그리고 언제, 어떤 테스트 케이스 ID에 의해 발견되었는지, 그것이 존재하는 모듈이 무엇인지, 언제 수정되었는지가 이에 해당된다.

마찬가지로 프로젝트 매니저는 성공적으로 수행된 테스트 케이스의 수, 발견되고 수정된 수에 대한 일일 기록을 수집해야 한다. 이것들은 일일 정보를 그래프로 그릴 수 있게 하고 그림 3과 같이 더많은 테스트 케이스들을 수행하기 위한 목표 계획을 세울수 있게 한다.

Analyze the data

그림 3과 같은 다이어그램은 소프트웨어 품질과 예상 출시일을 제어하는데 유용한 정보를 제공한다. 당신이 이러한 데이터를 어떻게 해석해야 하나?

첫째, 성공적으로 실행된 테스트 케이스들의 목표 수치와 실제 수치, 발견된 버그의 목표 수치와 실제 수치의 차이를 분석한다. 이것은 이전 디버깅 단계에서의 문제점을 집어내는데 도움을 줄 것이다. 그림 4는 그러한 4개의 다이어그램을 보여준다. 그림 4a는 제어 목표를 나타내며, 그림 4b는 소수의 테스트 케이스를 실행해서 많은 버그가 발견됨을 나타낸다. 이것은 대개 이전 프로세스로 부터 원인이 있는데, 모듈 디자인 같은 단계가 올바르게 완료되지 않았거나 테스트되지 않았음을 나타낸다. 매우 심각한 경우는 디버깅을 중단하고 이전 프로세스로 회귀해야 한다. 그림 4c는 프로그래머가 계획한대로 테스트 케이스들을 수행할 수 없음을 나타낸다. 그러므로, 아주 소수의 버그만이 발견되었다. 이런 경우 프로그래머가 디버깅을 할 수 없음을 의미하는데 이런 경우 그들이 디버깅에 친숙해질때까지 전문가에게 감독을 하라고 요청한다. 그림 4d는 두 가지 가능성이 있다. 테스트 케이스들이 적절하게 버그를 발견해 내지 못한 것이거나 소프트웨어가 많은 버그를 지니고 있지 않은 경우이다. 전자는 물론 후자보다 가능성이 많다. 개선책은 더 효과적인 테스트 케이스들을 만드는 것이다.

둘째, 만일 당신이 연속적으로 10일동안 10개의 버그를 찾았다면, 오늘이 당신이 10개의 버그를 찾은 마지막 날이 될 가능성은 없다. 버그 발생은 결코 갑자기 멈추는 법이 없고 오히려 서서히 감소한다. 버그 누적 커브로 부터, 당신은 언제 커브가 평평해지는지, 당신이 달성해야 하는 품질 목표의 일자는 언제인지 추정할 수 있다. 우리는 더 정확한 추정을 위해서 Gompertz 커브나 Logistic 커브를 사용했다 하지만 직관적인 관찰만으로도 강력한 도구가 될 수 있다.

셋째, 버그 리포트로 부터의 통계적인 데이터는, 예를 들어 가장 일반적인 버그가 무엇인지 또는 어떤 모듈이 에러 경향이 있는지를 보여줄 수 있다. 이러한 종류의 소프트웨어 메트릭은 "사실에 기반한" 품질 제어 파라메터로 작용한다.

마지막으로, 당신이 어떤 종류의 결점을 프로그래머들이 만드는 경향이 있는지 분석하게 하여 패턴을 따르는 에러들을 찾게 한다. 메모리 릭, 파일을 닫지 않은 상태로 두는 것 등과 같은 버그 유형을 말한다. 이것은 아마 프로젝트 매니저의 업무가 될 것이다. 하지만, 이것이 좀더 복잡한 문화적이고 조직적인 이슈들의 존재를 드러내게 할 수 있다.

프로젝트가 문서화된 테스트 케이스들과 미리 작성된 테스트 케이스들에 기반한 QA 접근법을 운용하지 않으면 어떤 일이 벌어질까? 1,000개의 버그 중 코드 인스펙션 동안에 단지 5퍼센트만 발견되었다고 가정하고(그림 1의 버그 분포에 기반하면 215개 버그), 머신 디버깅(631개 버그)은 발견하지 못하면(43개 버그), 개발 라이프사이클의 끝 부분에 나타나거나 더 심한 경우 고객의 사이트에서 나타날 것이다. 우리의 데이터는 이러한 결점 각각을 발견하고 수정하는데 2~3일만 요구되었다는 점을 나타낸다. 이것은 당신이 출시에 원하는 수준으로 제품 품질을 올리는데 추가적으로 86~130일을 필요로 함을 의미한다. 우리는 테스트 케이스들을 문서화하는데 2주를 사용했고, 또 다른 2주는 디버깅 단계에서 (이미 작성된) 테스트 케이스들을 수행하는데 사용했다. 결국, 4주동안의 작업이 4~6달을 절약하게 한 것이다. 이것만으로도 테스트 케이스 문서화의 유용성이 정당화된다.

REFERENCES

1. A. Onoma and T.Yamaura, "Practical Steps Toward Quality Development", IEEE Software, Sept. 1995,pp.68-77.

2. G.J.Myers, The Art of Software Testing,John Wiley & Sons, NewYork, 1979

3. T.Yamaura, "Standing Naked in the Snow", American Programmer, Vol. 5, No. 1, 1992,pp. 2-9.

4. T.Yamaura, "Why Johny Can't Test", IEEE Software, Mar./Apr. 1998, pp. 113-115

About the Author

Tsuneo Yamaura is a senior engineer at Hitachi Software Engineering. His research interests include testing methodologies, software metrics, development paradigms, software modeling, and CASE.

Yamaura received a BS in electrical engineering from Himeji Institute of Technology and was a visiting scholar at the University of California, Berkeley. He is a member of IEEE Computer Society and ACM.

Address questions about this article to Yamaura at Hitachi Software Engineering, 6-81 Onoe-cho, Naka-ku, Yokohama, 244 Japan; e-mail yamaur_t@soft.hitachi.co.jp

{끝}