소프트웨어 리그레션 테스트는 소프트웨어 테스트 그룹에 있어 핵심적이면서도 도전할 만한 업무라 할 수 있다. 사전적인 정의에 따르면, 리그레션 테스팅(Regression Testing)은, 추가된 새로운 기능이나 최근의 버그 수정으로 인해 현존하고 있는 시스템의 기능들이 뜻하지 않게 파괴되지 않았다는 것을 증명하기 위한 프로세스이다. 리그레션 테스트의 주된 과제는 가능한 시간 범위 안에서 가능한 한 많은 테스트를 수행하는 것이며 아울러 리그레션 테스트 사이클 안에서 가능한 한 빨리 모든 심각한 리그레션 결함을 찾아내는 것이다.
고전적인 의미의 리그레션 테스트 사이클은:
1.모든 새로운 기능이 완성되고 모든 주요 버그들이 수정된 소프트웨어의 최종 버전이 소프트웨어 개발팀으로부터 전달된다.
2.기능 테스트(Function Test)와 리그레션 테스트(현존하는 기능에 대해)가 수행된다.
3.퍼포먼스(Performance), 통합(Integration), 상호운용성(Interoperability), 그리고 스트레스 테스트가 수행된다.
4.만약 어떤 심각한 결함이 발견되었거나, 중대한 기능 변화가 필요하다면, 1번부터 3번까지의 과정이 반복된다.
5.필요한 모든 기능들이 정상적으로 작동하고, 주요한 결점이 남아있지 않다면, 소프트웨어는 테스트 작업을 끝내고 고객이 사용할 준비가 된 것이다.
리그레션 테스팅의 본질적인 문제(Problems Inherent in Regression Testing)
이러한 시퀀스를 따라가기 쉬움에도 불구하고, 리그레션 테스팅에 대한 고전적인 접근법에는 다양한 문제가 있다.
리그레션 테스팅의 목적은 이미 정상적으로 작동하고 있는 소프트웨어의 기능에서 문제를 찾아내는 것이다. 비록 프로젝트 관리 차원에서 수정을 연기하거나, 혹은 어떤 경우, 전혀 문제를 수정하지 않을 지라도, 릴리즈 이전에는 반드시 수정되어야 하는 몇몇 결함들이 리그레션 테스팅을 수행하는 동안 발견된다. 그 이후에 수정된 사항에 대한 리그레션 테스트 사이클이 반복되는데, 아마도 스케줄이 허락하는 것보다 더 많은 사이클이 반복될 것이다.
어떤 코드 수정도 모든 것, 그리고 어떤 것도 파괴할 수 있다
(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)
대부분의 테스트 그룹들이 수 천 개에 달하는 자동화된 테스트를 작성하고 유지보수 하거나, 혹은 다수의 테스터들이 직접 리그레션 테스팅을 수행하는 데 며칠씩을 할애하는 것과 같이, 그들이 가지고 있는 리소스의 대부분을 리그레션 테스팅에 소비하고 있다. 항상 문제는 소프트웨어에서 발생하기 마련이므로, 테스트 팀은 끊임없는 리그레션 테스트 사이클의 반복이라는 함정에 빠지기 쉬우며, 새로운 기능을 테스트하거나 더 나은 테스트를 만들기 위한 작업에 시간을 할애하는 것은 거의 불가능하다.
이러한 문제들을 다루기 위한 시도들(Attempts to Deal with These Problems)
대부분의 테스트 그룹에서 고전적인 리그레션 테스팅의 문제들을 해결하기 위해 아래의 네 가지 방법 중 하나를 시도하곤 했다:
완벽한 리그레션 테스트(The complete regression test)
몇몇 테스트 그룹은 리그레션 테스트의 문제를 회피하기 위해, 한 소프트웨어 버전에 대한 리그레션 테스트를 시작한 다음, 비록 리그레션 테스트 사이클 도중에 더 새로운 소프트웨어 버전이 릴리즈 된다고 하더라도 같은 버전에 대한 리그레션 테스팅이 완료될 때까지 며칠 혹은 몇 주간 테스트를 지속한다. 현재의 리그레션 테스트 사이클이 완료될 때까지 새로 나온 버전은 테스트가 되지 않은 상태로 남아있고, 현재의 테스트가 완료된 다음에야 최신 버전에 대한 리그레션 테스팅이 시작된다.
지속적인 리그레션 테스트(The continuous regression test)
다른 테스트 그룹들은 문제를 회피하기 위해, 리그레션 테스트 사이클 동안 매일 혹은 매주 간격으로 새로운 소프트웨어 버전을 받아들인다. 새로운 버전이 릴리즈 되면 해당 빌드에 대해 테스트 시스템을 가동하고 재시작 없이 테스트가 지속된다. 테스트의 마지막 무렵에, 다양한 소프트웨어 버전에 대해 광범위한 리그레션 테스트가 수행된다. 어떤 버전도 완벽하게 테스트되지 못하며, 리그레션 테스트는 단 한 번 수행된다.
리그레션 스모크 테스트(The regression smoke test)
또 다른 테스트 그룹들은 리그레션 테스팅의 범위를 좁혀 심도가 얕고, 일반적으로 자동화되어 있는 “스모크 테스트(smoke test)”를 각각의 새로운 소프트웨어 버전에 대해 몇 시간 내에 수행한다. 풀 리그레션 테스트는 “마지막(final)” 버전에 한해 한 번만 실시한다.
재시작이 가능한 리그레션 테스트(The restartable regression test)
일부 그룹들은 새로운 버전의 소프트웨어가 릴리즈 될 때마다 리그레션 테스팅을 재시작하며, 특히 릴리즈 스케줄의 종반부에 이르러 이번이 테스트가 필요한 마지막(혹은 거의 근접한) 버전일 것이라는 기대가 있을 경우에 더욱 이런 경우가 많다. 물론, 발견된 어떤 심각한 문제라도 리그레션 테스팅을 재시작할 것을 요구할 수 있다. 그리고 드물게는 스케줄을 조정하여 풀 리그레션 테스트 수행에 필요한 시간을 줄 수도 있다. 때때로 첫 부분의 테스트 케이스는 각각의 소프트웨어 버전에 대해 늘 수행되고, 테스트 플랜의 마지막 부분에 위치해 있는 테스트 케이스는 단 한 번만 수행될 경우도 있다.[각주:2]
아직도 문제는 남아있다(Still, the Problems Remain)
각각의 리그레션 테스팅 방법들은 가장 최신의 소프트웨어 버전에 대해 수행되었다는 면에서 어느 정도의 의미 있는 테스팅이라 부를 수 있다. 이런 면에서 의미가 부족한 테스팅은 리그레션 테스팅의 목적, 즉 적절한 시기에 모든 중요한 기능들이 아직도 정상적으로 작동한다는 것에 대한 확고한 자신감을 주어야 한다는 목적 자체를 실패로 이끌 수 있다.
매우 적은 규모의 리그레션 테스팅을 수행하는 위험을 완화하는 일반적인 방법은 “마지막” 버전에 대해 한층 더 복잡해진 테스트를 수행하는 것이다. 이러한 방법의 문제는, 리그레션 테스팅을 시작하기 전까지도 그 “마지막” 테스팅이 어떤 주요한 문제점을 찾아낼 수 있는지 여부를 알 수 없다는 것과, 빌드되고 포괄적으로 테스트 되어야 하는 마지막 버전에 이어지는 또 다른 마지막 버전이 요구될 수 있다는 것이다.[각주:3]
One-Hour 리그레션 테스트 전략 (The One-Hour Regression Test Strategy)
이러한 문제점들은 “One-Hour 리그레션 테스트 전략”을 수용함으로써 최소화될 수 있다. 이 전략은:
l리그레션 테스트 사이클의 더 나중 부분에 더 작은 이슈를 찾아내는 비용으로 가능한 한 빠른 시간 안에 심각한 주요 버그들을 찾아내려 시도하라
l리그레션 테스팅의 다양한 스타일을 받아들여라: 완전한 리그레션 테스트, 지속적인 리그레션 테스트, 리그레션 스모크 테스트, 그리고 재시작 가능한 리그레션 테스트
l추가적인 인력, 테스트 장비, 그리고 주말 특근을 요구하지 마라
스스로에게 물어보라, “한 시간만 주어진다면 무엇을 해야 하는가?”
(Ask Yourself, “What if I only had an Hour?”)
만약 어떤 고객이 당신에게 새로 나온 최신의 소프트웨어가 사용하기에 적합한지를 한 시간 안에 증명해 줄 것을 요청할 경우 무엇을 할 것인가? 어떤 테스트를 수행할 것인가? 자, 이제 잘 생각해 보자 – 당신이 지금 수행하고 있는 것과 똑 같은 테스트를 한 시간 안에 수행해야 하는 리그레션 테스팅에서 수행할 것인가?
처음 한 시간의 중요성(The importance of the first hour)
“잠깐만”, 여기서 당신은 의문을 제기할 수 있다. “나는 리그레션 테스트 계획을 실행할 수 있는6주의 시간을 가지고 있다. 그런데도 처음의 한 시간이 그렇게 중요한가?”
간단하게 말하면, 그렇다. 리그레션 테스트 사이클에서 가능한 한 빨리 중요한 문제점들을 찾아내는 것은 개발팀에게 단순한 퀵 픽스(Quick fix)가 아닌 포괄적인 수정을 할 최대한의 시간을 제공할 수 있다. 소프트웨어 품질에 관한 즉각적인 피드백은 전체 프로젝트 팀원들이 프로젝트의 목적에 더 집중할 수 있도록 해주고, 그럼으로써 가능한 한 빠른 시간 안에 높은 품질의 소프트웨어를 만들어낼 수 있다. 여기에 더해, 즉각적인 피드백은 다른 프로젝트가 당신의 개발 리소스를 가로채는(혹은 훔쳐가는) 것을 방지해 주기도 한다.
“어떻게든 반복될 수 밖에 없는 별 가치 없는 테스트를 수행하는 데 며칠씩 소비하는 대신, 당신이 가지고 있는 시간의 일정 부분을 흥미롭고 높은 가치를 가지는 리그레션 테스트를 수행하고, 자동화하고, 개선하는데 할애하라”
즉각적인 피드백은 프로젝트 관리부서에 문제에 대처할 수 있는 최대한의 시간을 제공해 줄 수 있다. 때때로 고객의 요구사항을 리셋 하거나 그 수준을 낮추어야 할 때도 있다. 이러한 문제점을 가능한 한 신속히 알게 됨으로써, 이후의 어려운 작업들을 더 쉽게 풀어나갈 수 있다.
즉각적인 피드백은 또한 테스트 팀에게도 현재 테스트하고 있는 소프트웨어 버전에서 어느 부분에 문제가 있는지를 더욱 확고하게 알려줄 수 있다. 이러한 가이드는 테스터로 하여금 기능이 수정될 때까지, 혹은 그 기능이 수정되고 나서 추가적인 테스팅을 하지 않아도 되도록 해준다.
가장 최신의 버전이 “더 이상의 수정이 아무 의미 없는 버전(Dead on arrival)[각주:4]”이라고 단정하는 것은 테스트 팀에게 압박으로 다가올 수 있다. 어떻게든 반복될 수 밖에 없는 별 가치 없는 테스트를 수행하는 데 며칠씩 소비하는 대신, 당신이 가지고 있는 시간의 일정 부분을 흥미롭고 높은 가치를 가지는 리그레션 테스트를 수행하고, 자동화하고, 개선하는데 할애할 수 있다.
어떻게 첫 한 시간에 적합한 테스트를 선택할 것인가
(How to pick the right tests for the first hour)
One-hour 리그레션 테스팅의 철학은 고전적인 리그레션 테스팅의 철학과 무척 다르다. 방법론적으로 각각 그리고 모든 기능들이 제품명세의 요구사항에 부합하는지를 검증하는 대신에, First-hour 테스트 방법은 테스트하는 버전에서 가능한 한 빨리 주요한 문제들을 찾아내는데 초점을 맞춘다. 첫 한 시간 내에 수행하는 데 적합한 리그레션 테스트가 어떤 것인가를 결정하는 데에는 제품의 형태, 즉 소프트웨어의 성숙도(Maturity)와 안정성(Stability), 그리고 활용 가능한 테스트 리소스가 큰 영향을 끼친다. 다음과 같은 질문들이 당신이 당신의 제품에 적합한 First-hour 테스트를 선택할 수 있도록 도와 줄 것이다.
고객지향적인 테스트(Customer-focused tests)
우선, 처음부터 끝까지 전형적인 제품의 사용을 고려하고 그러한 사용방법이 테스트 되도록 하라. 글로벌하고 거시적인 제품의 테스트를 생각하라. 당신의 고객에게 있어 어떤 테스트가 가장 의미 있을 것인가? 어떻게 제품을 고객의 모든 상황과 요구에 맞출 것인가? 당신이 만들어낸 제품의 이름은 무엇인가? 가장 처음 해야 할 테스트는 당신의 제품이 이름에 걸맞은 기능을 수행하고 있는지를 검증하는 것이다. 과연 어떤 기능이 제 역할을 수행하지 못할 때 고객에게 가장 큰 영향을 끼칠 것인가? 저장된 데이터가 손실될 수 있는가? 보안에 위협이 되는가? 서비스가 중지되는가? 이러한 중요한 기능들이 가장 먼저 테스트되어야 할 것이다.
복잡하고 어려운 테스트(Complex and difficult tests)
어떤 사용 시나리오(Usage scenario)가 당신에게 최대한의 중요한 기능이 정상적으로 작동하고 있다는 것을 말해줄 것인가? 테스트에 사용되는 시나리오들이 현실적이고, 고객의 환경을 근간으로 작성되어야 함을 잊지 말아야 한다. 만약 이에 적합한 하나의 시나리오가 없다면, 가장 많은 “동작 부분(Moving parts)”을 포함하고 있는 최상위 3개의 사용 시나리오를 테스트 해보라. 최고 수준의 테스트 중 어떤 것이 수많은 잠재먹인 유닛 혹은 기능 테스트 안에서 문제를 드러낼 수 있을지 고려하라. 어떤 기능들이 같이 테스트되어야 하는가? 개별 기능에 대한 리그레션 테스팅 대신, 실제 환경에서 동시에 사용될 수 있는 기능의 조합을 한 번에 같이 검증하도록 하라. 마지막으로, 어떤 기능이 가장 복잡한가? 어떤 기능들이 가장 동적으로 활용되며 가장 도전적인가? 어떤 테스트가 그냥 지나치기에 가장 힘든 것인가? 어떤 테스트가 그냥 지나쳐서는 안 되는 것인가?
전체 시스템 관점의 테스트(Big picture tests)
이제 다시 뒤돌아 보고 전체적으로 관찰해보자. 대규모 사용 환경 하에서의 전체 시스템 퍼포먼스가 테스트 되었는지 확인해보라. 최고 수준의 퍼포먼스 메트릭스에서 무엇이 가장 중요한가? 주요한 기능의 벤치마크로서 어떤 퍼포먼스 테스트가 사용될 수 있는가? 어떤 테스트가 신속하게 메모리, CPU, 혹은 다른 자원의 소모 이슈를 보여줄 수 있을 것인가? 어떤 테스트가 사용중인 전체 시스템의 상태를 보여줄 수 있을 것인가?
예상된 실패 테스트(Expected failure tests)
어떤 기능들이 당신 제품에서 지속적으로 문제가 되었는가? 이전에 어떤 결함들이 발견되었고 또 수정되었는가? 이러한 영역들이 사이클의 초기에 리그레션 테스트 되어야 하는 부분들이다. 어떤 리그레션 테스트가 이미 완료된 변화에 기반해 실패할 가능성이 가장 높은가? 가장 실패할 가능성이 높은 리그레션 테스트를 선택하는데 당신의 테스팅 경험과 직관을 사용하라. 리그레션 테스트 사이클에 있어서 가장 최근에 추가된 기능은 무엇인가? 가장 최근 기능에 대한 테스팅을 너무 빨리 수행할 경우 종종 문제가 발생할 수 있다.
궁극적인 목적은 테스트 대상인 소프트웨어 버전에 대해 가능한 한 신속하고 깊이 있게 테스트하는 것이다. 이러한 테스트들을 수행하는데 한 시간 이상이 걸릴 수도 있지만, 테스트의 우선순위를 정하고 선별함으로써 단 몇 시간 안에 테스트 대상인 소프트웨어 버전의 품질에 대한 가장 중요한 정보를 제공할 수 있을 것이다.
이 모든 것을 합치라(Putting It All Together)
리그레션 테스팅을 시작하기 전에, 버그 수정, 새로운 기능, 혹은 가장 최신 버전에서 제공하는 기능들에 대한 일련의 수정사항들에 대해 테스트 해보는 것이 무척이나 중요하다. 이러한 변화들이 버전을 새롭게 빌드하는 바로 그 이유이며, 만약 이런 변화가 적합하게 이루어지지 않았다면, 당신도 아다시피 새로운 다른 빌드를 만들어야 한다.
One-hour 리그레션 테스트를 새로운 기능 테스트가 완료된 이후면서 풀 리그레션 테스트를 진행하기 전에 수행하고, 다음과 같이 수행하라:
빌드를 만든 이유를 테스트하라.
l버그 수정사항과 그 수정으로 인해 발생할 가능성이 있는 모든 문제들을 테스트하라.
l“One-hour 신기능 테스트 플랜”을 사용해 모든 새로운 기능을 테스트하라.
One-hour 리그레션 테스트를 수행하라.
l퍼포먼스, 부하(Load) 그리고 용량(Capacity) 테스트를 선택하라.
l상호운용성(Interoperability)과 호환성(Compatibility) 테스트를 선택하라.
l데이터베이스 백업과 리스토어 테스트를 선택하라.
l리던던시(Redundancy: 이중화) 테스트, 보안 테스트, 그리고 데이터 통합(Data integrity) 테스트를 선택하라.
l스트레스, 결함 삽입(Fault insertion), 내구성(Endurance), 그리고 수명(Longevity) 테스트를 수행하라.
l매번의 고전적인 리그레션 테스팅에 대해 각각의 기능을 대상으로 하는 정교한 테스트를 수행하라.
버그가 발견되고, 새로운 기능이 추가되고, 그리고 테스팅 툴이 개선될 때마다 끊임없이 당신의 One-hour 리그레션 테스팅을 그에 걸맞게 최적화하라.
“처음 한 시간에 집중한 다음, 처음 네 시간, 처음 여덟 시간, 그리고 첫 주에 이루고자 했던 바가 무엇이었는지 스스로에게 물어보라.”
현재의 리그레션 테스트 전략을 평가해보라(Evaluate your current regression test strategy)
자, 이제 당신은 First-hour 테스트에 적합한 테스트 후보 목록을 살펴보았으니, 이들과 당신이 현재 진행하고 있는 리그레션 테스팅 중에서 처음 한 시간 동안 진행하는 테스트를 서로 비교해보라. 현재 당신의 리그레션 테스트 계획인 테스트 중심으로 작성되었는가 아니면 고객 중심의 시퀀스를 중심으로 작성되었는가? 당신의 첫 번째 테스트는 반드시 복잡하고, 대규모이며, 고객 사용 시나리오에 초점을 맞추고 있어야만 한다.
현존하는 당신의 리그레션 테스트 계획이 오래되었거나 혹은 최신의 것인가? 리그레션 테스트 플랜에 지속적으로 새로운 기능 테스트가 통합되어 업데이트 되었는가? 그렇지 않다면 새로운 기능 테스트가 테스트 계획의 마지막 부분에서 현재 수행되고 있는 모든 테스트가 완료된 뒤 단순하게 추가되는가? 처음 한 시간에 집중한 다음, 처음 네 시간, 처음 여덟 시간, 그리고 첫 주에 이루고자 했던 바가 무엇이었는지 스스로에게 물어보라. 당신이 모든 중요한 테스트가 수행 완료된 상황에서, 거의 모든 리그레션 테스트 케이스를 완료할 수 있는 바로 며칠 전에 테스트하는 버전을 릴리즈 할 것을 요청 받을 때를 대비해, 당신의 테스트 케이스를 우선 순위화 하고 이에 따라 재분류하라.
스모크와 새너티 테스트(Smoke and sanity tests)
One-hour 리그레션 테스트는 두 가지 다른 유형의 리그레션 테스팅, 즉 스모크 테스팅과 새너티 테스팅과 유사한 면을 가지고 있지만 이들은 각기 다른 테스트이다.
스모크 테스팅은 아래와 같이 일반적으로 소프트웨어에 대한 피상적인 테스트로 언급된다:
l소프트웨어가 설치되고 실행되는가?
l모든 스크린과 메뉴에 액세스가 가능한가(Accessible)?
l모든 오브젝트에 액세스가 가능한가?
One-hour 리그레션 테스트 방법은 좀 더 집중적이므로, 광범위한 영역에 걸쳐서 수행되는 스모크 테스트를 대치하기엔 힘들다. 만약 가능하다면, 스모크 테스트가 One-hour 리그레션 테스트와 병렬적으로 실행되어야 한다. 이것이 불가능하다면, 스모크 테스트를 바로 수행하고 이어서 One-hour 리그레션 테스트를 수행하라.
새너티 테스팅은 일반적으로 아래와 같이 소프트웨어의 기본적인 기능성을 검증하기 위한 소규모의 간단한 테스트라고 언급되어 왔다:
l간단한 연산이 올바른 결과값을 제공한다.
l기본적인 기능이 정상적으로 작동한다.
l개별적이고 독립적인 기능들이 정상적으로 작동한다.
전형적으로 어떤 용량, 스케일, 혹은 퍼포먼스 테스팅도 새너티 테스팅에는 포함되지 않는다. 새너티 테스팅은 각각의 기능에 대해 심도 있는 테스트의 시작점을 제공한다. 새너티 테스팅은 One-hour 리그레션 테스트가 완료된 이후에만 수행되어야 한다. 이상적으로는, 새너티 테스트는 리그레션 테스팅에 더 유용한 것들을 제공하기 위해 One-hour 리그레션 테스트가 수행될 때마다 재검토되어야 한다.
One-hour 리그레션 테스트는 다른 중요한 면에서도 스모크와 새너티 테스팅과 구별된다. One-hour 리그레션 테스팅의 목적은 복잡한 기능을 심도 있게 테스트함으로써 가능한 한 빨리 주요한 문제점들을 찾아내는 것이다.
새로운 기능들(New features)
리그레션 테스트 사이클 동안 어떤 새로운 기능이 도입된다면, 그 기능들을 첫 한 시간 동안 격렬하게 다뤄보고 주요한 디자인 문제를 도출해보라. 새로운 기능이 이 테스트에서 살아남은 후, 방법론적으로 새로운 기능에 대한 테스트 플랜을 완벽하게 적용하여 새로운 기능을 자세하게 테스트 해보라.
요약(Summary)
One-hour 리그레션 테스팅 방법은 가장 중요하고 가장 복잡한 테스트를 각각의 새로운 소프트웨어 버전을 받은 시점으로부터 첫 한 시간 이내에, 리그레션 테스트 사이클 내에서 중요한 문제점들을 조기에 발견하고자 하는 목적을 가지고 수행하는 것이다.
당신의 테스트 그룹이 전통적이거나, 애자일 하거나, 정황 주도적(Context-driven)이거나, 혹은 탐험적인 테스트 전략을 사용하는지 여부와는 상관없이, 소프트웨어 테스팅의 다양한 방법들이 One-hour 리그레션 테스팅 으로부터 이득을 얻을 수 있다.
One-hour 리그레션 테스팅 방법은 첫 한 시간에 대한 약간의 변화만을 요구할 뿐이지만, 이렇게 함으로써 며칠 동안의 반복적인 리그레션 테스팅을 절약하고, 반면에 당신이 생산하는 제품의 전반적인 소프트웨어 품질을 향상시킬 수 있다. <end>
역자 주: 어떤 목적을 달성하기 위해 끊임없이 반복적인 행위를 거듭해야 할 경우를 나타내는 구문이다. [본문으로]
역자 주: 간단하게 생각해서, 우리가 “수학의 정석Ⅰ”을 볼 때를 생각해보자. 늘 새롭게 시작할 때마다 맨 앞 부분의 “집합”만 까매지지 않는가? [본문으로]
역자 주: 즉 테스트하는 버전이 정말 최종 버전인지 확인할 수 없다는 것과 마지막 테스트라 하더라도 이 테스트에서 주요한 결함들이 노출될 지 여부를 확신할 수 없다는 것이다. [본문으로]
역자 주: ‘Dead on arrival’은 사전적으로 ‘병원에 도착 당시 이미 사망한 환자’를 의미한다. [본문으로]
역자 주: 스모크 테스트(Smoke Test)는 테스트 팀에 의해 수행되며 새너티 테스트(Sanity Test)는 개발팀 혹은 개발자에 의해 수행된다. 새너티 테스트는 스모크 테스트와 달리 테스트 케이스 없이 주요한 유닛 및 시스템 모듈에 대한 높은 수준의 테스트를 수행한다.
참조: http://blog.naver.com/tiare34?Redirect=Log&logNo=60002422701 [본문으로]
