The One-hour Regression Test

2008.12.05 18:09QA


소프트웨어 리그레션 테스트는 소프트웨어 테스트 그룹에 있어 핵심적이면서도 도전할 만한 업무라 할 수 있다
. 사전적인 정의에 따르면, 리그레션 테스팅(Regression Testing), 추가된 새로운 기능이나 최근의 버그 수정으로 인해 현존하고 있는 시스템의 기능들이 뜻하지 않게 파괴되지 않았다는 것을 증명하기 위한 프로세스이다. 리그레션 테스트의 주된 과제는 가능한 시간 범위 안에서 가능한 한 많은 테스트를 수행하는 것이며 아울러 리그레션 테스트 사이클 안에서 가능한 한 빨리 모든 심각한 리그레션 결함을 찾아내는 것이다.


 
고전적인 의미의 리그레션 테스트 사이클은:

1.     모든 새로운 기능이 완성되고 모든 주요 버그들이 수정된 소프트웨어의 최종 버전이 소프트웨어 개발팀으로부터 전달된다.

2.     기능 테스트(Function Test)와 리그레션 테스트(현존하는 기능에 대해)가 수행된다.

3.     퍼포먼스(Performance), 통합(Integration), 상호운용성(Interoperability), 그리고 스트레스 테스트가 수행된다.

4.     만약 어떤 심각한 결함이 발견되었거나, 중대한 기능 변화가 필요하다면, 1번부터 3번까지의 과정이 반복된다.

5.     필요한 모든 기능들이 정상적으로 작동하고, 주요한 결점이 남아있지 않다면, 소프트웨어는 테스트 작업을 끝내고 고객이 사용할 준비가 된 것이다.

 

리그레션 테스팅의 본질적인 문제(Problems Inherent in Regression Testing)

이러한 시퀀스를 따라가기 쉬움에도 불구하고, 리그레션 테스팅에 대한 고전적인 접근법에는 다양한 문제가 있다.

  

비누 거품칠하고, 헹구고, 반복하기(Lather-rinse-repeat)[각주:1]

리그레션 테스팅의 목적은 이미 정상적으로 작동하고 있는 소프트웨어의 기능에서 문제를 찾아내는 것이다. 비록 프로젝트 관리 차원에서 수정을 연기하거나, 혹은 어떤 경우, 전혀 문제를 수정하지 않을 지라도, 릴리즈 이전에는 반드시 수정되어야 하는 몇몇 결함들이 리그레션 테스팅을 수행하는 동안 발견된다. 그 이후에 수정된 사항에 대한 리그레션 테스트 사이클이 반복되는데, 아마도 스케줄이 허락하는 것보다 더 많은 사이클이 반복될 것이다.

 

어떤 코드 수정도 모든 것, 그리고 어떤 것도 파괴할 수 있다

(Any code change can break anything and everything)

프로젝트 매니저들은 종종 코드 수정이 코드의 특정 부분에서만 격리되어 발생하므로 어떤 결함도 유입되지 않으며, 그러므로 특정 기능이 발생하는 부분에 초점을 맞춘 단축된 리그레션 테스트만으로도 충분하다고 믿기 일쑤다. 실제로 당신은 어떤 코드 수정이라도 비록 아무리 격리되어 실행된다고 하더라도 표면상으로는 전혀 관계가 없어 보이는 부분의 코드에 간접적이고, 또한 의도하지 않게, 그리고 비극적이기까지 한 영향을 끼칠 수 있다는 것을 알고 있다. 때때로 버그는 결과적으로 버그를 노출하는 다른 변화가 발생하기까지 몇 년 동안 코드 내부에 잠재해 있을 수도 있다.

 

최고의 테스트는 바로 제일 마지막에 수행하는 것이다(The best tests are often saved for last)

대부분의 리그레션 테스트 계획은 논리적인 순서(logical order)에 따라 수립되는데, 이는 몇몇 간단한 테스트, 이를테면 “Ping the server”와 같은 간단한 테스트로 시작해서 제품의 복잡한 기능성을 따라 진행되고, 최종적으로는 백 만개의 루트를 가지는 테이블의 루팅 컨버전스 타이밍을 측정하는 것과 같은 복잡한 퍼포먼스 테스트로 종결된다. 비록 이러한 논리가 테스터들의 관점에서 초래된 것이라고는 해도, 이는 가장 심각한 결함을 먼저 찾아낸다는 리그레션 테스트의 목적과는 완전히 상반된 것처럼 보인다. 가장 복잡하고, 가장 많은 노력을 요구하며, 제품과 고객의 성공을 위해 가장 중요한 테스트가 제일 먼저 수행되어야 한다.

 

의미 있는 결과를 획득하는 것은 시간이 걸린다(Getting meaningful results is slow)

리그레션 테스팅에 대한 자동 및 수동 접근법은 양쪽 모두 우리가 가장 최신의 소프트웨어 버전이 수용 가능한지, 혹은 심각한 문제를 가지고 있는지 알 수 있을 때까지 하루 혹은 그 이상의 시간이 소요되는 경향이 있다. 더 복잡한 퍼포먼스, 상호운용성(Interoperability), 그리고 스트레스 테스트는 수행하는 데 일 주일이 걸릴 수도 있다. 그러나 관리자들은 한 시간 이내에 가장 최신 버전이 고객을 대상으로 새로운 기능을 소개하는데 적합한지, 혹은 고객 사이트에서 발생한 중요한 이슈가 새로운 문제를 발생시키지 않고 정상적으로 수정되었는지 등을 확인할 필요가 있다.

 

리그레션 테스팅은 반복적이고, 지루하고, 따분하다(Regression testing is repetitious, dull, and tedious)

리그레션 테스팅은 그 반복적인 본질 때문에 소프트웨어 테스터들이 가장 덜 선호하는 행위로 치부되는 경향이 있다. 몇 번의 반복 과정이 수행되고 나면, 수동으로 진행되는 동일한 과정의 테스트는 사람들을 지루하게 만들기 마련인데, 특히 리그레션 버그가 몇 개 발견되지 않을 때는 더욱 그러하다. 리그레션 테스팅의 스피드를 향상시키고, 테스터들의 부담을 줄여주기 위해 일반적으로 자동화 테스트 스크립트가 개발되어 사용된다. 그러나, 아무리 간단하게 자동화된 테스트라도, 대부분의 제품에서 제공하는 수 천 개의 기능에 대해 모두 수행이 된다면 결과적으로는 늘 유지보수 해야 할 필요가 있는 수 천 줄의 라인에 달하는 리그레션 테스트 스크립트가 된다 이것은 또 다른 지루한 업무가 될 것이다.

 

리그레션 테스팅은 가장 주요한 리소스의 낭비처이다(Regression testing is a major resource drain)

대부분의 테스트 그룹들이 수 천 개에 달하는 자동화된 테스트를 작성하고 유지보수 하거나, 혹은 다수의 테스터들이 직접 리그레션 테스팅을 수행하는 데 며칠씩을 할애하는 것과 같이, 그들이 가지고 있는 리소스의 대부분을 리그레션 테스팅에 소비하고 있다. 항상 문제는 소프트웨어에서 발생하기 마련이므로, 테스트 팀은 끊임없는 리그레션 테스트 사이클의 반복이라는 함정에 빠지기 쉬우며, 새로운 기능을 테스트하거나 더 나은 테스트를 만들기 위한 작업에 시간을 할애하는 것은 거의 불가능하다.




 

  1. 역자 주: 어떤 목적을 달성하기 위해 끊임없이 반복적인 행위를 거듭해야 할 경우를 나타내는 구문이다. [본문으로]
  2. 역자 주: 간단하게 생각해서, 우리가 “수학의 정석Ⅰ”을 볼 때를 생각해보자. 늘 새롭게 시작할 때마다 맨 앞 부분의 “집합”만 까매지지 않는가? [본문으로]
  3. 역자 주: 즉 테스트하는 버전이 정말 최종 버전인지 확인할 수 없다는 것과 마지막 테스트라 하더라도 이 테스트에서 주요한 결함들이 노출될 지 여부를 확신할 수 없다는 것이다. [본문으로]
  4. 역자 주: ‘Dead on arrival’은 사전적으로 ‘병원에 도착 당시 이미 사망한 환자’를 의미한다. [본문으로]
  5. 역자 주: 스모크 테스트(Smoke Test)는 테스트 팀에 의해 수행되며 새너티 테스트(Sanity Test)는 개발팀 혹은 개발자에 의해 수행된다. 새너티 테스트는 스모크 테스트와 달리 테스트 케이스 없이 주요한 유닛 및 시스템 모듈에 대한 높은 수준의 테스트를 수행한다. 참조: http://blog.naver.com/tiare34?Redirect=Log&logNo=60002422701 [본문으로]