2006년 07월 07일
프로그램 완벽하게 시험하기

소프트웨어에서 가장 쉬운 것을 고르라고 하면 단연 '코딩' 일겁니다.
소프트웨어에서 가장 어려운 것을 고르라고 하면, 첫번째는 '설계' 이고 두번째는 '테스팅' 이라고 말하고 싶습니다.
사실 이것이 한달전까지의 생각이었는데, 요즘 테스팅에 관한 책을 읽으면서 '테스팅'이 바로 소프트웨어에서 가장 어려운 기술이 아닌가하는 생각이 듭니다.
테스팅의 책을 읽게 된 이유는 사실 이 물음에 답을 얻기 위해서였죠.
'내가, 혹은 우리가 작성한 소프트웨어가 어떻게 하면 완벽하다고 증명할 수 있을까?'
그것이 비록 10줄의 코드라도 말입니다…
15년 테스터로 일해온 분의 말씀입니다.
구성 (Configuration) 테스트
모든 하드웨어 구성에 대해 종합적인 테스트를 실시하기로 결정하였다면, 모든 가능한 제조사의 모델과 조합들을 확인해야 한다. 엄청난 일이 눈앞에 나타나게 된다.
대충 336종의 그래픽 카드와 210종의 사운드 카드, 1500종의 모뎀, 1200종의 프린터가 있다면, 테스트할 조합은 336 X 210 X 1500 X 1200해서 수백만개가 넘는다. 고려하기엔 너무 많다.
테스트를 이들로 제한하고, 각각의 구성에 대해 30분씩만 테스트를 한다고 해도, 족히 1년은 걸릴것이다. 알아둘 것은, 이것이 단지 한 바퀴를 돈것에 불과하다는 것이다. 제품이 축시될 때까지 구성 테스트를 두, 세번은 해야 버그가 잡히는 것은 흔한 일이다.
그외에도 많습니다.
...................................................................................................
호환성 (Compatibility) 테스트
하위 버전 Test : 이전의 버전과 호환성을 유지하는가?
Word의 경우 23가지 Format을 읽어 들이는 것에 대한 시험을 해야한다.
외국어 테스트
간단해 보이는 외국어 테스트 또한 고려할 사항이 많습니다.
번역시 Text가 길어지는 경우, Button크기가 변경 되어야 합니다
왼쪽에서 오른쪽으로 읽는 경우입니다.
그림에 포함된 Text의 경우
Locale문제, 예) 통화, 시각, 날자, 길이
106개 국어 및 66가지 키보드를 지원 Windows XP
문서 테스트
EULA (End-User License Agreement)
마케팅 자료
패키지 Text 및 Graphic
UI 메시지, 경고창 및 에러
Help 및 도움말
매뉴얼
보안테스트
Buffer Under-run 테스트
소프트웨어 테스팅 2판
Ron Patton / 김도균 역
...................................................................................................
결국 책을 읽으면서, 이미 본능적으로 알고 있던 결론을 확인한 셈이 되었죠.
프로그램을 완벽하게 테스트하는 것은 불가능하다.
주어진 시간과 자원 내에 최선을 다하는 것이 '테스팅'인 셈입니다.
이 결론은 두가지 생각으로 이어졌는데,
하나는 어차피 완벽함을 보장할 수 없다면, 주어진 시간과 자원을 가장 효율적으로 사용하는 기술이 '테스팅'에서의 경쟁력이라는 것. 어렵습니다. 이 이야기는 꼬리에 꼬리를 물고 계속 이어지죠. 자동화 같은 이야기들이죠.
다른 하나는, '테스팅'은 최종 그물에 불과하다는 사실입니다. 그물이 얼마나 촘촘한가 여부의 차이지, 그물의 구멍을 없앨 수는 없다는 사실이죠. 그렇다면 우습게도 처음의 질문이었던 소프트웨어의 완벽을 추구하기 위해서는 '테스팅'이 아닌 나머지 부분에 투자를 해야 된다는 결론에 다다르게 되는군요. 테스트가 가장 어려운 기술이지만, 품질에 가장 중요한 기술은 아닐수도 있다는…
과연, 어떻게 하면 완벽한 소프트웨어를 만들 수 있을까요?
혹은 완벽에 가까운… 이라도
PS. 조엘이 웃겠죠? 소프트웨어는 완벽을 추구하는 것이 아니라 경제적인 품질을 유지하는 것이라고…
# by | 2006/07/07 02:00 | 메인스토리 | 트랙백 | 덧글(1)





☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]