오리도 지랄하면 날 수 있다!!!!!!

http://www.zdnet.co.kr/news/enterprise/etc/0,39031164,39164694,00.htm

Justin James ( TechRepublic )   2008/01/02   
     
 
프로그래 머들은 특별한 사람이라고 평가되는 것을 좋아한다. 사실은 어떤 모범적인 프로그래머들은 다른 프로그래머들의 이상한 점을 개발자들의 커뮤니티 내에서도 발견한다. 아래에 10가지 타입의 프로그래머를 소개한다. 여러분은 이 중에 어떤 타입인가?

#1: 간달프(Gandalf)

이 프로그래머 타입은 ‘반지의 제왕’에 나오는 마법사 간달프와 닮았다. 이 타입의 외관은 턱수염을 기르고, 이상한 모자를 쓰고, 겨울에 망토 같은 외투를 입을지도 모르며, 좋게 보면 간달프와 같은 마법으로 팀을 위하고, 안 좋은 면은 팀원들이 간달프가 눈길을 걸어올라 오는 시간을 기다리듯이 그가 전산실에 오는 시간을 오랫동안 기다려야 한다는 것이다.

이런 타입은 실력이 아주 뛰어난 중요한 인물이지만 보통은 같이 일하기를 꺼려한다. 하지만 문제가 해결이 안 될 때는 간달프의 마법이 필요하듯 이런 타입의 도움도 필요한 법이다.

#2: 순교자

다른 업종에서는 순교자(The Martyr)는 워커홀릭이다. 하지만 개발 분야에서 순교자는 그 차원을 넘어 선다. 워커홀릭은 최소한 집에 가서 샤워하고 잠은 자기 때문이다. 순교자 타입은 다 먹은 피자 박스에 둘러싸인 책상에 엎드려 자는 것을 자랑스럽게 생각한다.

문제는 아무도 이렇게 일하는 것을 원하지 않았다는 것이다. 순교자 타입은 다른 팀원에게 부담스러운 말을 한다. “먼저들 들어가. 저녁 맛있게 먹고…. 나는 오늘밤에 3주 동안 해야 할 코딩을 모두 하고 들어갈래.”라는 식으로 말이다.

#3: 팬보이

팬보이(Fanboy)는 조심해야 한다. 이런 사람이 여러분 주의에 있다면, 그는 드래곤볼 Z와 건담 윙 중 어느 것이 재미있는지 또는 플레이스테이션3와 X박스 360중 어느 것이 더 좋은지에 관해 과장 좀 해서 3시간 동안은 이야기를 들어야 할 것이다.

팬보이의 책상 주변에는 일본에서 수입한 액션 피규어, 포스터 또는 장식품 등을 진열해 놓았을 것이다. 이들은 자신들이 가지고 있는 장식품을 가지고 생각하는 것을 좋아해서, 그 생각에 시간을 많이 허비한다. 이런 타입은 가끔 무엇 때문에 채용을 했는지 모를 때가 가끔 있다.

#4: 빈스 닐(Vince Neil): 미국 밴드 머틀리 크루의 리드싱어

마치 1984년으로 돌아간 것 같은 타입이다. 긴 머리카락, 찢어진 청바지에 큰 스카프를 목에 두르고 업무 시간 동안 본 조비, 데프 레퍼드(Def Leppard)와 같은 음악을 따라 흥얼거리며 일한다. 빈스 타입은 일반적으로 재미있고 경험도 많지만 발전이 없다. 게다가 힙합 스타일과 아웅다웅할지도 모른다. 이런 타입과 매일 일하는 것은 꽤 힘들 것이다.

#5: 닌자

닌자 타입은 여러분 팀의 MVP이지만, 아무도 누구인지 모른다는 것이다. 전설적인 자객처럼, 닌자 타입은 일을 하는 건지 안 하는 건지 모르지만 아침이 되면 결과물이 나와 있는 것을 발견할 수 있다.

여러분이 소스 제어 시스템을 가동하고, 새벽 4시에 한번 확인 해보라. 여러분은 닌자가 그 프로젝트를 알고 있을 것이라고 생각하지도 않았지만, 여러분이 일주일 동안 작업한 계획의 문제를 코드 레벨에서 확인하고 알려 두었을 것이다. 여러분이 다른 회의에 참석해 있을 때, 닌자 타입은 일을 하고 있을 테니 확인해 보라.

닌자 타입은 아주 비밀스럽게 일을 한다. 여러분은 그 사람의 이름조차 모르지만 모든 프로젝트마다 아주 깔끔하게 정리되어 있는 것을 볼 수 있다. 이런 타입은 신중하게 다가가야 한다. 이런 사람을 조직 내에서 순위를 매기거나 파일로 업무를 관리하려고 하지 마라. 닌자 타입은 혼자 일하는 전사이며, 관리 당하는 것을 싫어한다.

#6: 이론가(The Theoretician)

이 타입은 프로그래밍에 관해 알아야 하는 모든 것을 알고 있다. 이 타입은 애매한 프로그램 언어의 역사에 관해 4시간 정도 떠드는데 시간을 소비하거나 어떻게 프로그래밍 하면 런타임을 줄이고, 최적화 프로그래밍을 할 수 있는지에 대해 시간을 허비할 수 있다.

문제는 이런 타입은 소프트웨어 개발에 관한 것을 알지 못하고 있다는 것이다. 이론가 타입이 코딩을 하면 정말 말도 안 되게 ‘엘레강스’하다. 또 좋아하는 기술은 ‘반복’이며, 모든 코드는 최대한 꼬여 있어 읽는 데 시간이 많이 걸린다.

이런 타입은 주의가 산만해 쉽게 다른 일에 관심을 돌린다. 몇 시간이면 개발할 수 있는 일을 이런 타입은 석 달은 족히 걸린다. 왜냐하면 기존의 툴은 충분하지 않다며 새로운 라이브러리를 만들어 새로운 툴을 만들어 사용하려고 하기 때문이다.

이런 타입은 잘만 컨트롤 하면 아주 잘 활용할 수 있다. 프로젝트에서 정확히 할 일에 대한 범위를 정해 주고 다른 일에 시간을 허비하지 못하게 한다면 말이다.

#7: 코드 카우보이(The Code Cowboy)

이 타입은 절대 스스로 멈추는 법이 없다. 이런 타입은 거의 항상 최고의 프로그래머이며, 다른 사람보다 두세배는 빠르게 일을 할 수 있다. 하지만 문제는 그렇게 빠르게 하는 일의 반을 대충 한다는 것이다. 소스 컨트롤 하는 코드 확인에 시간이 걸리고, 외부 컨피규레이션 데이터 저장에 시간이 걸리고, 다른 사람과 대화중에 생각을 이해하는 데도 시간이 걸린다.

이 타입의 코드는 스파게티처럼 혼란스럽다. 이유는 프로그래밍 하면서 리팩토링 하는 것이 절대 일어나지 않게 빨리 하기 때문이다. 프로그래밍 책에 예제로 되어 있는 “이렇게 하지 마세요”라고 7페이지에 걸쳐 중요하게 설명되어 있는 것과 비슷하게 프로그래밍을 했지만 신기하게도 프로그램은 돌아간다.

코드 카우보이 타입은 다른 사람과 함께 일을 잘 하지는 못한다. 그리고 여러분이 이런 타입 두 명을 같은 프로젝트에 투입시키면, 서로의 변화에 대해 인정을 하지 않고 싸우기 때문에 확실히 실패 한다.

이 타입은 정확하게 해야 하는 프로젝트보다 납기 일정이 더욱 중요한 프로젝트에 투입하는 것이 좋고, 코드는 항상 일정 전에 완성되어 있을 것이다. 코드 카우보이는 ‘시끄러운 닌자 버전’이라고 보면 된다. 닌자가 정교한 외래 수술을 하는 것에 비유한다면, 코드 카우보이는 성난 소처럼 저돌적으로 자신의 길을 달려가는 것에 비유할 수 있다.

#8: 공수부대요원(The Paratrooper)

여러분은 영화에서 적지 깊숙이 침투하여 비밀스럽게 업무를 수행하는 특공대 요원을 본적이 있을 것이다. 이 타입은 소프트웨어 개발 세계에서 ‘공수부대 요원’이라고 한다. 이 요원은 다 죽어 가는 프로젝트를 살리기 위해 마지막으로 보내는 프로그래머이다.

이 요원은 장기 프로젝트에 대해서는 부족하지만, 그들의 최대 자산은 친숙하지 않는 코드를 배워서 작업을 하는 불가사의한 능력이다. 다른 프로그래머들은 이러한 것을 충분히 배워서 프로젝트를 실행하는 데 몇 주 내지 몇 달이 걸릴지도 모르지만, 공수 부대 요원들은 몇 시간 또는 하루 정도면 충분하다.

이 요원들은 그 코드의 핵심을 알 정도로 배우지는 못하지만, 전체의 팀이 실패할지도 모르는 곳에서 성공할 수 있는 것을 의미한다.

#9: 보통사람(Mediocre Man)

“충분히 좋다”라고 듣는 것이 이 ‘보통사람’ 타입에게서 들을 수 있는 최고의 찬사이다. 이 이름에 속지 말아라. ‘보통사람’이라는 타입에는 엄청난 다양함이 있다. 그리고 이들은 다른 팀원들보다 더 나쁜 코드를 만드는 데 시간이 더 걸린다.

이 타입들의 특징은 느리고 침착하게 하지만 프로젝트가 언제 끝날지 모르며, 회사에 오랫동안 일을 하기 위해 항상 “충분히 좋다”라는 슬로건을 외친다.

이런 타입을 인터뷰 할 때 그들은 많은 프로젝트에 관여한 사실을 여러분에게 이야기 하겠지만 실제로 관여한 프로젝트는 많지 않다. 이러한 타입을 알아내는 것은 쉬운데 그들이 한 일에 대한 자세한 질문을 하면 아마 갑자기 건망증 증세를 보일 것이다. 이런 타입을 채용한다면 퇴사시키는 데 몇 년은 걸릴 것이다.

#10: 이반젤리스트(The Evangelist)

여러분이 어떤 환경에 처해 있더라도, 이반젤리스트는 지금 사용하고 있는 툴, 프로세스를 버리고 다른 것들로 대체해 업무 향상을 할 수 있다고 주장한다. 이반젤리스트는 실제로 이론가(The Theoretician)와 정반대이다. 이들은 솔직하고, 소프트웨어 개발에 관하여 많이 알지만 실질적으로 프로그래밍 작업은 거의 하지 않는다.

이들은 자신이 프로젝트 매니저나 부서장이라고 마음속으로 생각하고 있으나 지식이나 프로젝트 경험은 부족하다. 따라서 이들은 순수하게 경영자 역할을 할 수 있으므로 다른 사람들은 이들이 변혁을 시도하는 것을 참을 필요가 있다. @

 결점이 거의 없는 소프트웨어를 인도하는 데 매우 좋은 평판을 가지고 있는 일본 기업으로부터 시험 사례 설계 방법을 다룬 논문이다. (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

{끝}

인수 테스트

인수 테스트는 고객이 개발된 시스템을 최종 인수하기 전 제공된 기능과 성능이 고객의 요구사항과 일치하는지를 고객이 주관하여 최종으로 실행하는 것이다. 실제 사용자를 기준으로 테스트가 진행됨으로 비즈니스 측면의 테스트가 진행된다. 일반적으로 고객의 통합 테스트에 대한 참여를 통해 발생한 에러에 대한 수정, 보완 등이 끝난 것을 확인한 경우 인수 테스트를 대체하곤 한다.

현장 테스트

현장 테스트는 실제 사용자의 인프라 환경과 역할에 따른 사용방법 등을 고려하여 선정된 사용자들의 사업장에서 이루어지는 실전 테스트이다. 홈페이지 등 인터넷 환경에서 불특정다수가 사용하는 시스템인 경우는 PC방도 예외가 아니다. 다양한 PC, OS, 네트워크 환경 등 여러 조합에 대한 선정을 통해 최대한 현장의 목소리를 듣고자 하는 것이다.

성능 테스트

소프트웨어의 효율성(응답속도, 처리량, 처리속도)을 테스트하는 것으로서 볼륨 테스트나 스트레스 테스트와 병행하여 수행될 수도 있다. 다량의 데이터를 조회하거나 수정하는 중요 프로그램에 대해 테스트를 수행하고 응답속도를 측정한다.

1. 주요 대상
­ 다량의 데이터를 편집하여 조회하는 중요 프로그램에 대해 테스트를 수행함

2. 수행절차
­ 테스트에 필요한 데이터를 준비함
­ 테이터를 편집/조회할 프로그램을 수행시켜 테스트를 수행함

볼륨 테스트

소프트웨어로 하여금 사용자가 요구한 만큼의 데이터 처리가 가능한 지를 테스트하는 것이다.

1. 주요 대상
­ 중요 마스터 데이터에 대해서는 테스트를 수행함
­ 다량의 데이터가 조회되거나 업데이트되는 화면으로 테스트를 수행함
­ 볼륨 테스트에는 매우 많은 비용이 필요하므로 필요 이상으로 과다한 테스트가 되지 않도록 시스템의 특성을 잘 고려하여 수행해야 함

2. 수행절차
­ 볼륨 테스트의 대상이 되는 테이타베이스에 사용자가 요구한 만큼의 데이터를 임의로 준비함
­ 해당 테이터를 입력, 또는 배치로 생성하는 애플리케이션을 수행하여 데이터의 정상처리 여부를 테스트함 　

스트레스 테스트

소프트웨어에 다양한 스트레스를 가해봄으로써 짧은 시간 동안에 많은 양의 데이터를 처리할 수 있는지를 테스트하는 것이다. 또한 분산처리 시 시스템 구성요소별로 스트레스가 적절히 분배되는지를 테스트한다.

1. 주요 대상
­ 하나의 데이터베이스에 많은 양의 데이터를 한 번에 입력/수정하거나, 여러 개의 데이터베이스에 다양한 데이터를 한 번에 입력/수정하는 프로그램에 대해 테스트를 수행함
­ 사용빈도가 높은 화면을 대상으로 테스트를 수행함

2. 수행절차
­ 테스트에 필요한 데이터베이스를 준비함
­ 프로그램이 처리 할 데이터를 준비함
­ 다수의 사용자가 동시에 데이터를 처리하는 경우 해당 테스트 환경을 준비함

보안 테스트

불법적인 소프트웨어 사용을 방지하는 테스트로서 자체의 보안체계가 완벽한 지를 테스트하는 것이다. 또한 적합한 권한을 가지지 않은 사람에게 자료나 정보가 제공되지 않는 것을 보장하기 위한 테스트이다.

1. 주요 대상
­ 전체 시스템에 대한 접근시 보안 상태와 개별적으로 보안이 정의된 프로그램에 대하여 테스트를 수행함

2. 수행절차
­ 보안이 정의된 프로그램을 파악함
­ 해당 프로그램을 다양한 방법(임의 패스워드 등)으로 테스트를 수행함

“죄 없는 자가 있다면 돌을 던져라”

국내 OO은행은 전사 DW(DataWarehouse)를 구축하기 위해 RFP(Request for Proposal)를 공지해 발주를 냈고 대형 SI와 글로벌 솔루션 업체들의 합종연횡을 통해 S사, 국내 H 솔루션사 컨소시엄과 EDW 구축 계약을 했다. 기간은 7개월, 은행 기간계의 여신, 수신, 외환, 공제, 증권 등 은행 내 모든 데이터를 추출, 정제, 로딩을 거쳐 DW를 구축하고 이의 활용을 위한 신 정보계 시스템을 구축하는 것이다.

박 대리는 여신파트 정보계 시스템 구축을 위한 웹 프로그램 담당자이다. 개발자로서 은행 여신업무에 대한 이해를 위해 현업 담당자(이하 현업)와 수차례에 걸쳐 인터뷰를 하고, 데이터 모델에 대한 분석과 설계, 애플리케이션 아키텍처에 대한 스터디와 연습을 통해 개발을 위한 준비 작업을 완료했다. 본격적인 코딩의 시간이 되었다. 2개월의 짧은 기간 동안 200여 개의 조회 화면을 개발해야 한다. 그리고 1개월의 통합 테스트를 거쳐 그랜드 오픈을 한다. 그러기 위해 PL(Project Leader)의 관리 하에 개발을 진행하는 동안에도 현업의 단위 테스트를 거쳐야 한다. 단위 테스트는 개발자의 몫이자 현업 고객이 해야 할 1차 기능 테스트이다.

하루에 화면 5개씩 SQL 쿼리를 짜고 웹 화면에 적용한다. 화면이 복잡하면 할수록 화면 변수에 맵핑해야 할 Input 변수가 많아진다. 개발된 화면에 대한 단위 테스트를 위해 박 대리는 기본적인 자가 기능 테스트를 거쳐 현업에게 단위 테스트를 의뢰한다. 정해진 테스트 프로세스에 의해 하루에 5개씩 개발이 완료된 화면을 현업에게 제공하고 현업은 테스트 후 테스트 결과를 피드백해야 한다.

그런데 고객인 이 차장은 테스트 프로세스를 무시하고 우선 자신이 요구사항에 적은 대로 개발해 놓으라고 한다. 그러면 시간을 갖고 천천히 테스트를 하겠노라고…. 고객의 요청사항인 만큼 맘 놓고 정해진 요구사항대로 휴일도 없이 열심히 개발하고 자가 단위 테스트를 했다. 드디어 2개월이 지나 화면 200여 개발을 다 완료했다. 박 대리는 뿌듯해했다. 이제 남은 건 통합 테스트다. 그리고 통합 테스트는 내일부터 시작이다. 그런데 이 차장이 박 대리가 개발한 화면을 놓고 볼멘소리를 하기 시작한다. 화면 한 개를 테스트했는데 OO은행의 자산이 10조밖에 안 되는데 박 대리가 만든 화면은 100조가 나왔다는 것이다. 박 대리는 이 차장에게 “차장님께서 말씀하신 요구사항대로 개발했다”고 말했다. 이 차장은 개발자인 박 대리의 능력을 믿었고 대충 이야기해도 제대로 알아듣고 개발한다고 생각했다고 한다.

그리고 박 대리는 PL로부터 “내일부터 통합 테스트인데 박 대리가 맡은 부분에 대한 단위 테스트를 진행해 주세요”라고 들었다. 눈앞이 캄캄했다. 남들보다 열심히 고군분투하며 앞서서 개발을 했고, 고객이 원하는 대로 진행했으며, PL에게 진행 상황에 대한 보고까지 하면서 열심히 개발에 매진했지만 박 대리는 통합 테스트에도 미치지 못하는 단위 테스트 불량 개발자였다. 박 대리는 눈물을 머금고 이 차장과 함께 단위 테스트를 다시 진행했다. 200여 화면에 대해 하나씩 기능에 대한 검증과 조건에 대한 검증 그리고 데이터에 대한 검증을 진행해 나갔다. 1개월이 흘러 다른 부분은 통합 테스트를 완료한 상태에서 오픈을 했고 박 대리가 맡은 부분은 오픈이 연기가 되어 통합 테스트를 보름간 더 진행했다. 프로젝트 팀원이 모두 철수한 후까지 박 대리는 미진한 통합 테스트를 진행했고, 결국 프로젝트 전체 납기에 영향을 줘 고객과의 약속도 지키지 못했다. 개발자인 박 대리는 과연 무엇을 잘못한 것일까? 고객의 요청사항을 무조건 들어준 것이 잘못인가? PL에게 보고도 했는데 왜 비난은 박 대리가 들어야 할까? 참으로 난감하다. 테스트는 과연 누구의 책임일까? 개발자인 박 대리는 열심히 개발한 죄밖에 없었을 텐데 말이다.

문제 예방을 위한 최선은 무엇인가

김 과장은 머리가 터질 지경이다. 이제 곧 일주일간의 통합 테스트를 시작해야 하는 데 아직 환경이 구축되질 않았다. 분명 2주일 전에 계획을 세우고 R&R(Role & Responsibility)을 정하고 체크리스트(Checklist)를 만들어 점검까지 했는데도 말이다.

현업에게 뭐라고 이야기해야 할까? 통합 테스트 환경을 구축하기로 한 담당자는 개발자들이 개발 소스에 대해 제대로 단위 테스트를 하지 않아 에러가 발생한다고 한다. 개발자들은 현업의 요구사항이 단위 테스트할 때 변경되어 적용하다가 그랬다고 한다. ‘그래, 통합 테스트의 이틀 지연이다’라고 결심한 김 과장은 고객에게 양해를 구하고, 에러가 발생한 단위 테스트를 집중적으로 해서 기능에 대한 보완을 한다.

오늘부터 개발자들에게 밤샘야근을 지시한다. 어쩔 수 없다. 이틀 후에는 통합 테스트를 실시해야 한다. 고객이 최대의 관심사를 갖고 주시하고 있기 때문이다. 통합 테스트를 제대로 이행하지 못하면 오픈 지연으로 납기에 차질이 생긴다. 현업이 담당한 통합 테스트 시나리오를 점검한다. 엉망이다. 개발팀 담당자를 불러 시나리오에 대해 협의를 했느냐고 물어보았다. 현업이 물어보았지만 시나리오는 현업의 책임이라고만 이야기했단다. 현업은 가이드 없이 대충 작성하여 제출한 것이다. 큰일이다. 새로 작성하자니 시간이 없고 이대로 진행하자니 통합 테스트가 엉망일 것 같다.

현업과 사태를 해결하기 위한 회의를 했다. 현업은 자신 있게 말한다. “통합 테스트 시나리오가 없어도 현업들은 각자 생각한 대로 테스트 케이스를 만들어 테스트할 것이다. 굳이 문서로 작성할 필요가 없을 것 같다” 맞는 말이다. 하지만 이렇게 되면 현업이 생각하는 테스트의 범위, 비즈니스 로직, 데이터 등을 컨트롤할 수가 없다. 어떻게 할지 고민이다. PM과 상의를 한다. PM이 적정한 조정안을 제시한다. 그 안은 다음과 같다.

“상세한 통합 테스트 시나리오를 가지고 통합 테스트를 실시하지 않지만 현업이 직접 테스트한 결과에 대한 시나리오 및 테스트 결과는 문서로 작성하여 제출한다. 그리고 에러 발생시 결함 보고서를 제출한다”

현업은 잠깐 고민한 후 즉각 승낙한다. 이틀 후 통합 테스트는 실시되었다. 전쟁이다. 현업 담당자는 테스트를 실시하고 에러 발생한 즉시 개발자는 뛰어다닌다. 단위 테스트 시 해결됐던 에러도 다시 발생한다. 단위 테스트 시 발생하지 않았던 에러도 발생한다. 외부 인터페이스가 성공했다 실패했다 한다.

하루를 마치고 테스트 케이스와 결함보고서를 정리한다. 테스트 범위는 10%인데 결함은 무려 100개를 상회한다. 이제 개발자들과 회의를 진행한다. 우선, 에러를 단순결함과 중결함으로 구분한다. 단순결함에 대해 수정 조치를 먼저 하여 에러의 개수를 줄여나간다. 중결함은 이틀 정도 시간을 두고 개발자에게 해결을 지시한다. 벌써 12시가 넘어가고 있다. 내일 이틀째 통합 테스트가 기다리고 있다. 3일째가 되자 통합 테스트는 속도를 올려 진행된다. 테스트 범위가 벌써 70%를 상회한다. 에러는 점점 줄어든다. 이제 안정을 찾아가는 듯하다. 개발자들에게 에러 수정을 독려한다. 중결함이 아닌 단순결함들은 당일 수정 조치를 원칙으로 하고 개발자들을 독려한다. 현업들이 차츰 안정을 찾아간다. 오픈을 해도 된다는 낙관론이 생기기 시작한다. PM에게 보고한다. 통합 테스트가 오픈 수준에 맞추어 진행되고 있고 현업이 원하는 수준의 품질(quality)을 보장할 수 있을 것 같다. PM은 무뚝뚝하게 경고한다.

“김 과장, 자네 QA 역할이 뭔 줄 아나? QA는 에러가 발생하면 그때그때 신속하게 처리하도록 지시하는 게 아니라 에러의 발생을 애초부터 막는 것일세“

김 과장은 마음이 상했다. 그래도 최선을 다해 에러 발생시 신속하게 수정지시를 해서 고객의 마음을 조금은 돌려놓았는데 말이다. 김 과장은 고민한다. QA의 역할이 에러의 발생 방지라면 어떻게 에러 방지를 할 수 있을까? 그럼 개발 단계부터 QA의 주도가 필요할 것이다. 그리고 통합 테스트 시나리오는 누가 작성하는 게 맞을까? 분명 현업이 하는 것이 맞을 텐데 어떤 고객도 하겠다고 하질 않으니 그것이 문제이다. 어떻게 그들을 설득시켜야 할까? 현실과 이상의 커다란 간극, 이것이 딜레마이다.

등잔 밑이 어둡다, 모든 환경변수에 대해 고민하라

문제는 응답 속도이다. 고객은 응답속도의 기준치를 ‘3초 이내’로 제시했다. 개발해야 하는 모든 화면에 대한 응답속도를 3초 이내로 끌어내려야 한다는 것이다. 아키텍처 프레임워크는 검증된 것을 적용했으니 문제가 없는데 비즈니스 로직이 문제이다. 원하는 기능들이 복잡할수록 네트워크를 타고 전송되는 패킷의 양이 많아져 PC에서의 로딩 시간이 길어지면 3초 이내를 지키기는 거의 불가능에 가깝다. 하지만 어찌하랴 고객이 원하니 어쩔 수가 없다. 홍 과장에게 숙원 과제가 맡겨졌다.

우선, 성능 테스트를 실시해서 현재의 상황에 대한 문제점을 도출해야 한다. 그리고 도출된 문제점을 해결하기 위해 튜닝을 실시해서 고객의 기준치를 맞추어야 한다. 홍 과장은 시스템 엔지니어인 박 책임에게 성능 테스트 환경구성을 의뢰하고, 개발팀에게 만들어진 개발소스에 대한 테스트 빌드를 구성하기 위해 성능 테스트 계획을 세웠다. 성능 테스트 환경은 운영(production) 환경과 유사하게 구성이 되어야 한다. 운영체제와 소프트웨어 버전이 같아야 하고, 하드웨어 용량은 운영환경의 것을 이용하면 최고겠지만 그렇지 못할 경우는 성능 테스트계를 임시로 구성하여 2/3 정도의 크기로 갖추어 놓는 게 좋다.

시스템 엔지니어인 박 책임은 성능 테스트 환경구성에 대해 일정에 맞추어 설치를 완료하겠다고 약속했다. 다음은 성능 테스트 시나리오의 작성이다. 다행스럽게 통합 테스트에서 사용하던 통합 테스트 시나리오가 있어 이를 재활용하기로 한다. 다음은 목표 동시사용자 수의 설정이다. 성능 테스트를 통해 목표 동시사용자 수에 맞게 환경구성과 개발소스에 대한 튜닝이 이루어지면 된다. 구 시스템에 대한 월/주/일/시간대별 사용자 수를 추출하여 최번시(최고 피크시) 동시사용자 수를 설정했다. 다음은 성능 테스트 시나리오에 맞게 툴을 이용하여 스크립트 코딩을 한다.

드디어 1차 성능 테스트의 결과가 나왔다. 암담하다. 목표 동시사용자 수에 훨씬 미치지도 못하는 수치가 나왔고 응답속도는 10초를 상회한다. 하드웨어와 소프트웨어의 환경구성에 대한 파라미터를 재설정하고 개발팀에게는 소스 내 잘못된 SQL과 로직에 대하여 수정을 요청한다. 2차 성능 테스트를 실시한다. 2차에 비해 나아지기는 했지만 여전히 어이없는 수치이다.

개발팀과의 마라톤 회의를 통해 소스 내 모든 코드에 대한 점검을 실시한다. 개발자들은 스타일에 따라 코딩을 했다. 표준화를 강력히 요청했지만 표준화된 팁을 사용하지 않는 개발자가 대다수였다. PM에게 현상에 대한 보고를 하고 개발자들에게 표준화된 형태로 코드를 수정할 것을 지시했다.

3차 성능 테스트를 했다. 고객이 설정하고 요청한 목표 동시사용자 수와 응답속도를 만족하는 수치가 나왔다. 성공이다. 역시 성능에 대한 키는 개발자들이 쥐고 있었다. 기쁜 마음으로 성능 테스트에 대한 결과보고를 하고 오픈을 해도 좋다는 고객의 동의를 얻어냈다. 드디어 오픈하는 날이다. 시스템 가동과 함께 시스템에 대한 사용도가 올라간다. 그런데 이상하게도 응답속도가 제대로 나오지 않았다. 어떤 것은 10초를 넘는 것도 있었다. 큰일이었다. 분명 몇 차례에 걸친 성능 테스트를 통해 코드에 대한 튜닝, 파리미터에 대한 튜닝을 했고 고객의 목표치를 만족했는데 말이다.

본격적인 조사에 착수했다. 네트워크 환경과 PC의 성능차이가 원인인 듯 했다. 고객은 현장 응답속도 기준으로 3초를 요청했단다. 막막했다. 현장의 인프라를 고려하지 않고 성능 테스트를 한 것이다. 현재의 인프라를 마음대로 업그레이드할 수 없지만 환경변수에 대한 고려가 포함된 성능 테스트를 실시했어야 한다는 것이다. 사용자의 불만은 날마다 수십 개씩 접수되었다. 도저히 쓸 환경이 되지 않으니 이전 시스템을 사용하게 해달라는 요청도 있었다. 밤을 세워가며 고객과 현재의 문제점에 대한 대안을 논의했다.

사용자에게 PC의 업그레이드를 요청하고 네트워크 인프라 또한 네트워크 파트의 도움으로 취약 지역에 대한 증설을 하기로 했다. 홍 과장은 노력한 만큼 결과를 얻지 못했다고 풀이 죽어 있었다. PM은 그런 변수도 고려하지 않고 실험 환경 데이터에 대한 분석결과에 만족해 했다고 질책했다. 고객은 시스템 사용자를 기준으로 목표를 제시한다. 사용자에 대한 분석 없이 성능 테스트 시나리오를 작성하고 환경변수에 대한 고려 없이 성능 테스트를 실시했다고 불만을 토로했다. 성능 테스트는 왜 이리 복잡하고 어려운 것일까? 환경변수에 대한 고려와 함께 성능 테스트를 하는 것이 가능한가? 그런 것은 툴이 지원해 줄 수 있을까?

테스트의 미덕, 중용

그랜드 오픈이 한 달 앞으로 다가왔다. 이제 한 달만 지나면 프로젝트 팀원 50명이 7개월간 고생한 결과에 대해 평가를 받게 된다. 결코 팀원들의 노력이 헛되지 않도록 철저하게 오픈을 준비할 것이다. 지난 6개월 동안 시스템 구축을 위해 요구사항을 분석하고 컴포넌트를 추출, 설계를 하고 코딩을 해왔다. 그리고 500여 화면에 대한 단위기능의 개발과 병행하여 화면 중심의 단위 테스트와 모듈 중심의 단위 테스트를 실행해 왔다.

단위 테스트를 담당한 PL들이 테스트 프로세스를 잘 준수해줬고 현재, 통합 테스트와 함께 성능 테스트를 진행하고 있다. 통합 테스트와 성능 테스트를 마치면 대망의 오픈을 할 예정이다. 그런데 과연 통합 테스트와 성능 테스트만 잘 마치면 성공적인 오픈을 할 수 있는 것일까? 사용자에게 편리하게 화면 설계가 되었고, 응답속도도 3초 이내로 사용자 기대수준을 만족하고, 시스템 사용상의 불안정성도 제거한, 사용자가 만족하는, 성공적인 시스템을 오픈할 수 있는 것일까? PM으로써 리스크를 최소화하고 성공에 대한 확신을 줄 수 있는 테스트 결과에 대한 근거를 기반으로 고객이 인정하고, 우리 스스로가 인정할 수 있는 시스템을 제공해야 한다.

강 PM은 실로 오래간만에 소프트웨어 공학론을 펼쳤다. 테스트에 대한 부분을 세밀히 훑어봤지만 강 PM이 지금 필요로 하는 테스트와 검증방법은 찾아볼 수 없었다. 그저 통합 테스트와 성능 테스트를 열심히 하면 된다는 그런 내용들이었다. PL 회의를 소집했다. 현재 진행하고 있는 통합 테스트와 성능 테스트를 체계적이고 상세하게 진행하되 그 외 다른 테스트 방법론의 존재유무를 논의했다. 테스트 전문가인 박 대리가 부정 테스트와 회귀 테스트 그리고 현장 테스트에 대한 제안을 했다.

강 PM은 그 테스트들의 정의와 진행방법 그리고 효과에 대한 진지한 고민을 했고, 박 대리의 제안을 받아들이기로 결정했다. 더불어 고객들에게 다양한 테스트들을 실행함으로 얻을 수 있는 효과에 대해 자랑스럽게 이야기했다. ‘리스트 제거’, 다양한 테스트를 진행하는 궁극적인 목표인 것이다. 강 PM은 외부 테스트 요원들을 모집하고 그들에게 현재 진행하고 있는 테스트 시스템에 대해 테스트 시나리오를 무시한, 기발하고 스토리가 없는, 사용자 입장에서 할 수 있는 가능한 모든 부정적인 테스트를 요구했다.

어떤 이는 조회 화면을 수십 번 연속해서 눌렀고, 어떤 이는 조회 중간에 3초를 기다리지 않고 화면을 닫아 버리고, 어떤 이는 숫자를 넣어야 할 곳에 문자를 넣어 조회하고, 또는 날짜 조건 입력 시 백년의 기간을 조회해 보기도 하는 등 다양한 부정 시나리오가 쏟아져 나왔다.

조회화면을 동일한 조건에서 수십 번 연속해서 누르자 동일한 데이터가 아닌, 새로운 데이터가 계속 조회되었다. 조회조건은 동일한 데 수십 번 연속해서 누른다고 조회내용이 다르게 나오는 것이었다. 해당 개발자는 황당해 했다. 그렇게 사용하는 사용자는 없다는 것이다. 그래도 이런 결과가 나온 것은 코드상 로직의 문제가 있음을 제기했고 개발자도 검토를 해본 결과 자신이 그런 코딩을 했다는 것을 믿지 않는 눈치였다. 이런 부정 테스트에 대한 결과를 고객에게 설명하자 고객은 희색이 만연하여 시스템 품질에 대한 확신을 가지는 눈치였다.

다음 회귀 테스트는 단위 테스트에서 나온 결함을 기본 베이스라인(baseline)으로 설정하고, 통합 테스트, 성능 테스트까지 지속적으로 해당 결함에 대한 회귀 테스트를 실행하여 최종 테스트에 통과가 될 때까지 실행하도록 PL들에게 지시했고, PL들 또한 결함 발생에 대한 추적관리를 통해 ‘한 번 발생한 결함은 두 번 다시 발생하지 않는다’는 원칙을 고수하게 되었다.

마지막으로 현장 테스트를 위해 고객의 적극적인 협조로 업무별 종류, PC 사양의 종류, 네트워크 용량의 종류 등 다양한 케이스의 현장을 선정하고 동일한 시나리오를 통해 기능의 완전성과 응답속도의 차이를 측정하고 기준을 설정하여 해당 시스템에 대한 현장 사용자의 만족도를 예측할 수 있었다. 정말로 다양한 케이스에 따라 기능의 완전성에도 차이가 있었고, 응답속도의 차이 또한 천차만별이었다. 고객이 제시하는 ‘3초 이내’는 어떤 기준인지 고객의 기준을 명확히 하는 근거가 될 수 있었다.

이런 추가적인 비정형적인 테스트를 통해 고객은 시스템에 대한 신뢰를 가질 수 있었고, 프로젝트팀은 7개월의 고생이 헛되지 않는 성공적인 오픈을 할 수 있었다. 테스트 종류 몇 가지를 실행한 것뿐인데 고객은 결과에 대해 대만족스러워했고 시스템은 안정적인 운행을 하게 되었다. 그저 단위 테스트, 통합 테스트, 성능 테스트 등 정형적인 테스트만 수행했을 경우는 어떠했을까? 물론, 테스트의 종류가 많다고 고객이 신뢰를 하는 것은 아니다. 단지, 현재 진행하고 있는 방법론상의 테스트와 이를 보완할 수 있는 다양한 테스트를 함께 수행함으로써 완벽성을 기할 수 있는 크로스 체크 결과가 된 건 아닐까? 결함이 나오는 테스트가 올바른 테스트일까? 아니면 결함이 하나도 없는 테스트가 올바른 테스트일까? 테스트는 그 역할로 인해 항상 중용의 길을 걸어야 할 존재인 것이다.

모든 해답은 프로젝트 현장에 있다

테스트는 아무리 강조해도 지나치지 않는 활동이라고 했다. 대부분 프로젝트들은 필수적인 테스트(단위, 통합, 성능)만 선정하고 준비하고 실행하여 이를 통해 나온 결과만을 가지고 의사결정을 한다. 그리고 오픈 후 많은 문제에 직면하게 된다.

기능의 오류, 시스템의 불안정, 요구사항의 미반영, 사용자의 미숙 등 프로젝트 막바지에 테스트에 모든 인력과 정열을 집중했음에도 불구하고 예측하지 못한 결함들이 쏟아져 나온다. 이를 어떻게 해야 하는가? 어쩔 수 없는 것일까? 테스트에 아무리 집중해도 품질목표를 달성하는 것은 프로젝트에서는 불가능한 목표일까?

문제는 바로 프로젝트 현장에 있다. 필수적인 테스트들을 선택하고 집중하여 실행했지만 여기에는 많은 헛점이 있다는 것이다. 또한 좀 더 완벽한 품질을 달성하고자 한다면 시스템 특성에 맞는 테스트를 전략적으로 적용해야 하는 것이다. 다음은 테스트 종류별 잘못된 실행사례이다.

첫째, 단위 테스트를 개발자에게만 맡겨두고 그 결과를 인정하는 경우이다. 개발자는 본인이 코딩한 프로그램에 대해 해당 기능에 대한 소극적인 테스트에 임한다. 데이터는 알고 있는 데이터 1~2개 정도이고 다양한 조건에 대한 테스트는 개발자에게 기대하기 힘들다. 왜냐하면 그들은 방대한 개발물량이 있기 때문에 진척율에 쫓긴다. 이를 예방하기 위해 반드시 해당업무 PL이 개발자들이 실행한 단위테스트에 대한 확인테스트를 실행한 후 진척율에 반영하는 것이다.

둘째, 통합 테스트 수행 시 통합 테스트 시나리오를 고객이 미리 작성하지 않고 개발팀에서 형식적으로 간략하게 작성하는 경우이다. 이런 경우 고객은 자신의 머릿속 시나리오대로 테스트를 진행하고, 개발팀은 테스트 케이스에 대한 전체범위를 모르는 상태에서 테스트를 실행하는 고객의 수준과 태도에 따라 시스템 내 품질은 업무범위에 따라 고르지 못한 상태가 된다. 이런 경우, 프로젝트팀은 품질 목표를 달성할 수 없게 되고 고객에게 맡겨진 품질은 미궁 속으로 빠져들게 된다. 이를 예방하기 위하여 고객들에게 통합테스트가 시작되기 한 달 전에는 교육을 통해 통합 테스트 시나리오 작성의 당위성, 필요성에 대해 설득하고 합의를 이끌어 내어 반드시 통합 테스트 시나리오를 작성한 후 통합 테스트를 실행하는 것이다. 통합 테스트 시나리오는 초기 고객의 요구사항 정의서와 함께 고객의 요구사항이 반영된 최종 품질기대 문서이다. 셋째, 성능 테스트 수행 시 사용자 환경(PC, 네트워크 등)에 대한 고려 없이 성능 테스트 툴을 통해 나온 응답속도와 동시사용자 수에 대한 무비판적인 수용이다. 이런 경우 오픈 후 반드시 성능, 특히 응답속도에 대한 불편신고를 가장 많이 받는다. 성능 테스트는 시스템의 성능, 동시사용자 수 그리고 화면별 응답속도에 대한 객관적인 수치를 얻고자 한다.

이를 위해 TA(Technical Architect)는 운영환경과 유사하게 성능 테스트 환경을 구성하고 해당 프로그램들을 선정, 비율을 조정하여 테스트를 실행한다. 그리고 최번시 수용 가능한 동시사용자 수와 시스템 사용현황 그리고 응답속도를 데이터로 제시한다. 그리고 성능 테스트는 끝이다. 하지만 현장사용자의 IT 인프라 환경을 고려하지 않은 상태에서 제시한 데이터는 실험실 내에서의 테스트일 뿐이다. 그래서 반드시 현장 사용자의 IT 인프라 현황을 파악, 분석하여 다양한 조건의 테스트베드를 만들고 반드시 현장의 응답 속도를 측정한 후 튜닝을 실행하여 IT 인프라와 응답속도간 상관관계를 파악하여 오픈 후 응답속도에 대한 불편을 제거해야 한다.

넷째, 인터넷 시스템을 오픈하면서 현장 테스트를 실시하지 않는 경우이다. 물론 현장 테스트를 회사 내에서 실행하는 경우도 있지만 이는 요식행위이며 해당 인터넷 시스템을 사용하는 모든 고객의 장소를 분석하여 기능의 완전성, 응답속도의 적절성 등을 테스트해야 한다. 고객의 장소는 PC방, 고객의 집 PC 등이 있고 이 또한 오래된 PC방, 신장개업 PC방 그리고 여전히 윈도우 95/98 같은 운영체제를 사용하는 고객의 집 PC 등으로 세분화할 수 있다. 고객의 IT 인프라는 사용자의 특성에 따라 동일한 환경이 거의 없다. 그리고 인터넷에는 수많은 프로그램들이 쏟아져 나와 있어 해당 인터넷 시스템과 충돌이 나는 경우도 종종 발생한다.

이상과 같이 테스트는 그 종류가 많은 만큼 실행상의 허점이 곳곳에 널려 있다. 테스트 관리자는 전략 수립과 함께 실행계획 수립 시 예외조건을 빠트리지 않도록 주의를 기울이고 테스트는 결국 개발된 프로그램 전체를 대상으로 하기 때문에 테스트 범위는 이 시스템을 사용하는 모든 고객을 대상으로 한다고 생각하고 테스트 관리자는 예외가 없는 전수 테스트에 임해야 할 것이다.

개발 중심에서 테스트 중심으로

테스트가 시대를 만났다. 천대받던 시절을 이겨내고 테스트는 품질을 확인하고 검증하고 보증하는 중추적인 역할을 맡게 되었다. 이에 따라 많은 테스트 관련 툴들도 우후죽순처럼 시장에 쏟아져 나왔다. 이제 테스트는 프로젝트 라이프 사이클(PLC) 전 기간에 걸쳐 그 역할을 확대하고 있다. 테스트의 미래는 어떻게 될까? 가까운 미래를 예측해본다.

서기 2010년 7월, K은행 기간계 구축 프로젝트. 이 부장은 고객과의 요구사항 확정에 대한 협의가 끝나자 PL들에게 통합 프로젝트 관리 툴(이하 통관툴)에 요구사항을 직접 입력하도록 지시했다. 요구사항들은 연속적으로 번호가 붙여지며 관리를 위한 베이스라인으로 확정되었다. 분석/설계자 최 과장은 이에 대한 세부 협의를 통해 설계 스펙을 통관툴에서 확정한다. 그와 동시에 개발자가 지정되었다. 개발자인 김 대리는 통보된 스펙 대로 프로그램을 코딩하고 기능 테스트 시작 버튼을 누른다. 조회조건 입력을 요청한다. 테스트 데이터를 랜덤하게 선택하여 100개를 자동 입력한다.

통관툴은 만들어진 프로그램을 하나씩 하나씩 코드 레벨로 실행하며 에러와 권고 리포트를 생성한다. 코드에 대한 100% 커버리지로 테스트를 종료한다. 에러와 권고 리포트를 읽어보며 요청한 대로 코드를 수정한다. 재 테스트를 실시한다. 이젠 100% OK가 나왔다. 김 대리는 해당 프로그램을 통합 테스트로 이동하도록 선택한다. 통합 테스트 저장소(repository)는 테스트 관리자인 박 과장 관리 하에 통합 테스트가 가능한 시점을 알려준다. 박 과장은 1주일 전 통합 테스트 시나리오에 대한 고객과의 협의를 통해 미리 시나리오를 입력해 두었다. 박 과장은 통합 테스트 시작버튼을 누른다. 우선, 단일 기능은 완벽했다. 그리고 외부 인터페이스와의 테스트도 원활했다. 통합 테스트는 입력된 테스트 케이스 대로 자동으로 수행된다. 이에 따라 에러가 발생한 경우 에러 리포트와 해결방안이 자동으로 표시된다.

통합 테스트가 완료된 프로그램은 부정 테스트와 회귀 테스트하도록 선택한다. 통관툴은 정해진 방식대로 부정테스트를 실행하고 단위 테스트에서 발생했던 에러를 기준으로 회귀 테스트를 실행한다. 완벽하다. 이제 남은 건 성능 테스트이다. 해당 소스를 빌드하여 성능 테스트계에 이관하고 성능 테스트 버튼을 누른다. 10 유저, 100 유저 계속 유저수가 올라가며 성능 테스트가 실행된다. 150 유저가 되었을 때 응답속도가 2초가 되었다. 초기 세워둔 기준대로 성능 테스트는 대만족이다.

다음 현장 테스트 버튼을 누른다. 소스가 현장 테스트베드 시스템으로 이관된다. 조건이 다양하다. PC방, 고객집, 지방 격오지까지 선택이 가능하다. 필요한 조건을 선택하고 현장 테스트 버튼을 누른다. 시스템은 테스트가 실행되면서 다양한 결과를 보여준다. 결과를 분석하고 PC방에서의 응답속도가 저조함을 선택하고 충돌이 발생하는 프로그램을 찾아본다. 특정 회사의 메신저가 해당 시스템과 충돌이 나서 응답속도가 저조해졌다는 결과이다. 개발자인 김 대리에게 충돌이 나는 부분에 대해 수정을 요청한다. 김 대리는 소스분석을 통해 충돌지점에 대한 로직을 수정하고 다시 현장 테스트를 요청한다. 재 테스트를 실시한다. 이번엔 OK이다.

정해진 오픈은 앞으로도 한 달이 남았다. 만일에 발생할 수 있는 오류를 찾기 위해 박 과장은 퇴근하면서 통합 테스트, 부정 테스트, 회귀 테스트, 성능 테스트, 현장 테스트 등 모든 테스트에 대한 버튼을 실행한다. 통관툴은 해당 명령에 대해 수준을 올려가며 테스트를 진행한다. 앞으로 남은 한 달 동안 통관툴을 통한 테스트는 계속될 것이다.

미래의 테스트는 프로젝트 시작과 함께 시작될 것이다. 요구사항에 대한 정의가 설계에 반영되어 코딩이 되면 이에 대한 다양한 테스트가 자동으로 실행되어 에러 리포트를 쏟아 낼 것이다. 물론 요구사항을 입력하고 시나리오를 입력하는 수기의 과정은 필요할 것이다. 이에 대한 자동화는 가까운 미래가 아닌, 조금 먼 미래쯤이면 가능할 지 모르겠다. 테스트의 중요성은 이처럼 나날이 증가하고 있다. 프로젝트 초기단계부터 테스트를 위한 준비를 하는 것이다. 다시 말해 개발 중심의 방법론이 아닌, 테스트 중심의 방법론으로 대체가 될 것이다. 많은 솔루션 업체와 SI 업체를 중심으로 테스트를 통한 품질확보를 위한 최적의 프로젝트 방법론과 도구들을 쏟아낼 것이라고 기대해본다

다양한 테스트에 대한 이해는 필수

테스트는 정상에 있는 품질목표를 달성하기 위한 등산과 같다. 입구에서 시작해 산등성이를 지나 절벽을 오르면 정상에 도달할 수 있다. 하나하나의 과정을 반드시 이겨내야만 정상에 도달해서 환희, 기쁨, 만족감 등을 맛볼 수 있는 것이다

품질은 기능 품질과 비기능 품질로 나눈다. 기능 품질은 기능성, 작동성, 정합성 등 시스템의 기능을 테스트한다. 단위 테스트, 회귀 테스트, 부정 테스트, 통합 테스트, 크로스 테스트, 제품품질 검사, 인수 테스트, 현장 테스트 등을 기능 테스트로 분류한다. 비기능 품질은 주로 성능, 보안 등 인프라에 대한 품질을 말한다. 성능 테스트, 스트레스 테스트, 볼륨 테스트, 보안 테스트 등을 비기능 테스트로 분류한다.

단위 테스트

단위 테스트는 개발과 동시에 진행하여 개발 기간과 함께 종료한다. 개발자는 설계자가 설계한 대로 코딩을 하고 설계자와 함께 기능의 정확성을 확인한다. 소프트웨어가 작동하는 지 확인하기 위해 신규 또는 변경 코드만 따로 테스트하는 최초의 테스트 단계이며 이를 통해 내부 프로그램과 모듈 로직에 맞추어 프로그램 스펙을 검증하고 나아가 프로그램 로직을 검증한다.

단위 테스트의 검증 단계로 단위 모듈 테스트와 단위 화면 테스트를 수행하고, 모듈 테스트는 단위 모듈의 기본 처리를 검증하는 단계이며, 각 모듈에 구현된 기능의 정확성과 완전성을 검증한다. 화면 테스트의 범위는 단위 화면 내 버튼 기능이 모두 정상임을 확인한다.

회귀 테스트

회귀 테스트는 단위 테스트에서 시작해서 인수 테스트로 끝나는 테스트 전체기간 동안 결함의 추적성을 통제하여 한 번 발생한 결함은 다시 발생하지 않도록 점진적, 반복적으로 수행하는 것이다. 이를 위해 테스트 관리자는 형상관리 툴을 이용하여 단위 테스트, 통합 테스트, 인수 테스트 등 테스트 시 발생한 모든 결함들을 등록하고 반복적 테스트를 통해 기능의 완전성과 정확성을 높여 품질을 보증한다.

부정 테스트

부정 테스트는 사용자의 예기치 못한 조작방법에 대응하기 위해 일반적인 작동 프로세스를 무시하고 테스트 시나리오 없이 기능을 테스트를 하는 것이다. 조회 버튼을 백 번 연속해서 누른다든지 날짜가 들어가는 곳에 문자를 입력하거나 2월 30일과 같이 존재하지 않는 데이터를 입력하는 등 일반적인 사용자가 하지 않는 범위에 대해 테스트를 하는 것이다.

통합 테스트

통합 테스트는 기능 테스트 중 가장 중요하고 반드시 실시해야 하는 필수 테스트다. 어떤 프로젝트팀은 테스트 종류 중 오직 통합 테스트에만 집중하여 모든 결함과 오류를 수정하고 이 데이터를 근거로 오픈에 대한 의사결정을 한다. 통합 테스트 목적은 다음과 같다.

◆ 단위 테스트를 통과한 애플리케이션과 업무 기능의 인터페이스가 정상적으로 작동하는지를 검증한다.

◆ 이를 위해 통합 모듈의 기능, 화면과 연관된 업무 기능, 모듈 간의 인터페이스 검증 테스트 등에 대해 테스트와 평가를 한다.

◆ 고객이 제시한 테스트 시나리오를 바탕으로 하여 실행방법과 예상결과 등을 포함하는 테스트 케이스를 정의하고 그 기준에 의하여 통합 테스트를 진행한다.

◆ 통합 테스트를 위해 정의된 세부적 테스트 케이스가 고객의 테스트 시나리오의 요구조건을 모두 수용해야 하며 각 테스트 케이스의 실행이 예상결과와 일치해야 해당 케이스의 실행이 성공한 것으로 간주한다.

◆ 반드시 데이터 정합성에 대해 테스트를 진행해야 한다.

통합 테스트를 통해 많은 결함이 도출된다. 결함들은 난이도에 따라 분류되어 수정일정과 함께 개발자에게 넘겨진다. 분류는 다음과 같이 할 수 있다.

◆ 치명결함 : 애플리케이션 종료, 시스템 다운, PC 재부팅 등을 하여야 하는 결함

◆ 중결함 : 데이터의 정합성 불일치 또는 해당 업무(기능)을 정상적으로 진행할 수 없는 결함

◆ 경결함 : 일부 오류를 포함하고 있으나 처리가 가능한 결함

◆ 단순결함 : 해당 기능을 수행하는데 문제가 되지 않으나 사용자들의 에러를 유발시킬 수 있거나, 혼동할 수 있는 내용(예 : 불명확한 메시지 처리, 조회필드의 입력가능, 오타, 등)

크로스 테스트

크로스 테스트는 테스트 종류라기보다는 테스트 진행방법 중의 하나이다. 기능 테스트를 실행하는 데 고객에게만 테스트를 맡기지 말고 프로젝트 팀원 전원이 테스트를 함께 참여하여 서로의 것을 테스트하며 많은 결함과 오류를 발견하고자 하는 목적에서 만들어진 것이다. 크로스 테스트의 묘미는 본인이 개발한 것보다 타인이 개발한 프로그램에서 훨씬 많은 결함을 도출해낸다는 것이다.

제품품질 검사

제품품질 검사는 공인된 테스트 전문 업체를 통해 단기간에 개발된 시스템을 전수 검사를 하는 것이다. 품질 체크리스트를 기반으로 4~5명이 참여하여 기능에 대한 테스트를 수행한다. 이 때 투입된 전문가들은 부정 테스트에 대한 개인적 경험을 이용하기도 한다. 테스트 전문가들에 의해 실행되기 때문에 숨겨진 에러까지 발견하곤 한다.

R&TTE와 함께 2000년 4월 8일자로 그 첫 발을 내딛은 GCF는 네트워크 사업자들과 단말기 제조업자들 간 협력의 산물로서, 2세대와 3세대 무선 통신 단말기가 네트워크내에서 잘 운용됨을 보증하기 위한 프로그램을 제공합니다. 

전 세계적으로 규격의 통합에 대한 요구가 높아지고 있는 가운데, GCF는 유럽 내 각국의 규정을 반영한 Global standard를 제공함으로써 이러한 요구에 가장 잘 부흥하고 있습니다. 제조자는 GCF 인증을 통해 해당 단말기가 세계적으로 인정되는 기술 요구사항에 부합하는 지를 검증 받아 그 적합성을 증명할 수 있게 되어, 결과적으로 제조자, 사업자 및 사용자 모두를 만족시킬 수 있습니다.

GCF는 제조자에게 있어 선택사항이긴 하지만, 네트워크 사업자나 사용자들의 요구가 커짐에 따라 필수적인 사항으로 인식되고 있습니다.

.관련사이트 http;//gcf.gsm.org

.GCF:Global Certification Forum

Global certification forum PRDs

.GCF-CC , Certification Criteria