2008 . 12 . 5 . 18 : 09 ㆍ QA 
 고전 적 인 의미 의 리그 레 션 테스트 사이클 은 : 
 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 ) 
 대부분 의 테스트 그룹 들 이 수 천 개 에 달하 는 자동 화 된 테스트 를 작성 하 고 유지 보수 하 거나 , 혹은 다수 의 테스터 들 이 직접 리그 레 션 테 스팅 을 수행 하 는 데 며칠 씩 을 할애 하 는 것 과 같이 , 그 들 이 가지 고 있 는 리소스 의 대부분 을 리그 레 션 테 스팅 에 소비 하 고 있 다 . 항상 문제 는 소프트웨어 에서 발생 하 기 마련 이 므로 , 테스트 팀 은 끊임없 는 리그 레 션 테스트 사이클 의 반복 이 라는 함정 에 빠지 기 쉬우며 , 새로운 기능 을 테스트 하 거나 더 나 은 테스트 를 만들 기 위한 작업 에 시간 을 할애 하 는 것 은 거의 불 가능 하 다 . 
 이러 한 문제 들 을 다루 기 위한 시도 들 ( 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 특색 ( Feature ) 과 기능 ( Function ) 테스트 를 선택 하 라 . 
 리그 레 션 테 스팅 을 지속 하 라 . 
 l 모든 스모크 혹은 새 너티 ( Sanity ) 테스트 [ 각주 : 5 ] 를 수행 하 라 . 
 l 부하 , 용량 , 상호 운용 성 , 그리고 퍼포먼스 테 스팅 을 수행 하 라 . 
 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 ) 
 리그 레 션 테스트 사이클 동안 어떤 새로운 기능 이 도입 된다면 , 그 기능 들 을 첫 한 시간 동안 격렬 하 게 다뤄 보 고 주요 한 디자인 문제 를 도출 해 보 라 . 새로운 기능 이 이 테스트 에서 살아남 은 후 , 방법 론 적 으로 새로운 기능 에 대한 테스트 플랜 을 완벽 하 게 적용 하 여 새로운 기능 을 자세 하 게 테스트 해 보 라 . 
 One - hour 리그 레 션 테스 팅 방법 은 가장 중요 하 고 가장 복잡 한 테스트 를 각각 의 새로운 소프트웨어 버전 을 받 은 시점 으로부터 첫 한 시간 이내 에 , 리그 레 션 테스트 사이클 내 에서 중요 한 문제점 들 을 조기 에 발견 하 고자 하 는 목적 을 가지 고 수행 하 는 것 이 다 . 
 당신 의 테스트 그룹 이 전통 적 이 거나 , 애자일 하 거나 , 정황 주도 적 ( Context - driven ) 이 거나 , 혹은 탐험 적 인 테스트 전략 을 사용 하 는지 여부 와 는 상관없이 , 소프트웨어 테 스팅 의 다양 한 방법 들 이 One - hour 리그 레 션 테 스팅 으로부터 이득 을 얻 을 수 있 다 . 
 One - hour 리그 레 션 테스 팅 방법 은 첫 한 시간 에 대한 약간 의 변화 만 을 요구 할 뿐 이 지만 , 이렇게 함 으로써 며칠 동안 의 반복 적 인 리그 레 션 테 스팅 을 절약 하 고 , 반면 에 당신 이 생산 하 는 제품 의 전반 적 인 소프트웨어 품질 을 향상 시킬 수 있 다 . < end > 
 역자 주 : 어떤 목적 을 달성 하 기 위해 끊임없이 반복 적 인 행위 를 거듭 해야 할 경우 를 나타내 는 구문 이 다 . [ 본문 으로 ] 
 역자 주 : 간단 하 게 생각 해서 , 우리 가 “ 수학 의 정석 Ⅰ ” 을 볼 때 를 생각 해 보 자 . 늘 새롭 게 시작 할 때 마다 맨 앞 부분 의 “ 집합 ” 만 까매지 지 않 는가 ? [ 본문 으로 ] 
 역자 주 : 즉 테스트 하 는 버전 이 정말 최종 버전 인지 확인 할 수 없 다는 것 과 마지막 테스트 라 하 더라도 이 테스트 에서 주요 한 결함 들 이 노출 될 지 여부 를 확신 할 수 없 다는 것 이 다 . [ 본문 으로 ] 
 역자 주 : ‘ Dead on arrival ’ 은 사전 적 으로 ‘ 병원 에 도착 당시 이미 사망 한 환자 ’ 를 의미 한다 . [ 본문 으로 ] 
 좋 은 사람 을 구하 는 법 ( 0 ) 
 IEEE 829 - 1998 중 테스트 요약 보고서 부분 번역 ( 0 ) 
 모든 것 을 다 외주 줘도 남겨야 할 품질 관리 팀 의 업무 는 무엇 인가 ? ( 0 ) 
 이상 적 인 테스트 팀 을 선택 하 고 관리 하 기 ( Choosing and managing the ideal test team ) ( 2 ) 
 TestLink 1 . 7 한글 매뉴얼 ( 6 ) 
 The One - hour Regression Test ( 0 ) 
 Bug , Regression , Regression Testing , Test , testing , 리그 레 션 테스트 , 버그 
 IEEE 829 - 1998 중 테스트 요약 보고서 부분 번역 2009 . 05 . 15 
 모든 것 을 다 외주 줘도 남겨야 할 품질 관리 팀 의 업무 는 무엇 인가 ? 2009 . 03 . 09 
 이상 적 인 테스트 팀 을 선택 하 고 관리 하 기 ( Choosing and managing the ideal test team ) 2009 . 02 . 13 
 TestLink 1 . 7 한글 매뉴얼 2009 . 02 . 12 
 1 · · · 113 114 115 116 117