[번역] 리그레션 다시 생각해보기 - 파트 3: 리스크 완화 전략

리그레션 다시 생각해보기 – 파트 3: 리스크 완화 전략

 

앞의 글에서 나는 아래와 같이 리그레션과 관련된 리스크들을 소개했다. 또한 이들이 단지 하나의 독립적인 형태로 나타날 뿐만 아니라 다른 문제와 조합되어 발생할 수도 있다는 것도 언급했다. 

 

n  새로운 버그(New Bug)

n  이전 버그(Old Bug)

n  좀비 버그(Zombie Bug)

n  빌드 오류(Bad Build)

 

이러한 각각의 리스크를 완화시키는 다양한 전략이 존재한다. 주로 아래와 같은 3가지로 전략을 분류할 수 있다.

 

n  예방(Prevention): 리스크 발생을 애초에 방지한다.

n  확인(Confirmation): 이전과 같이 동작한다는 것을 검증한다. 리스크가 발생하지 않음을 확인하는 것이 이 범주에 속한다(마이클 볼튼(Michael Bolton)은 이것을 체킹(checking)이라고 부른다).

n  반증(Disconfirmation): 정상적으로 동작한다는 것을 반증하기 위해 노력하는 것. 예를 들어 버그가 발생했음을 입증하는 것은 이 범주에 속한다.

 

이 전략들을 각각의 리스크에 순서대로 적용시켜 보고 프로젝트에 어떤 전략을 사용할 수 있을지 고민해 보자.

 

새로운 버그

n  예방: 새롭게 구현되는 부분에서 새로운 버그가 발생하지 않도록 하기 위해 변경사항에 대한 명세를 리뷰한다.

n  확인: 새로운 빌드가 바로 이전 빌드와 동일하게 동작한다는 것을 증명하기 위해 이전 버전의 테스트를 수행한다.

n  반증: 장애(failure)를 찾아봄으로써 능동적으로 새로운 버그를 발견할 수 있다.   

 

이전 버그

n  예방: 리팩토링을 통해 코드가 점점 복잡해지고 혼란스러워 지는 것을 방지할 수 있다. 코드가 복잡해지고 혼란해질수록, 필연적으로 변경이 꼬리를 물고 발생하게 된다.

n  확인: 오래된 버그들이 다시 발생하지 않았음을 증명해야 하며, 오래된 버그들을 리테스트하기 위해 특별히 고안된 테스트를 다시 수행해야 한다.

n  반증: 오래된 버그들을 드러낼 수 있는 새로운 방법을 고안해야 한다. 

 

좀비 버그

n  예방: 한 번도 실행되지 않은 데드 코드가 없다는 것을 확인하기 위해 리뷰와 정적분석을 활용한다.

n  확인: 새로운 버그와 유사하게, 이전 버전과 소프트웨어의 동작이 동일하게 수행된다는 것을 증명하기 위해 이전 버전의 테스트를 수행한다.

n  반증: 새로운 버그와 유사하게, 장애를 찾아봄으로써 능동적으로 버그를 발견할 수 있다.

 

빌드 오류

n  예방: 이전 버전의 버그투성이 빌드가 다시 배포되는 것을 막기 위해 소프트웨어 형상관리(Configuration management)를 수행할 필요가 있다.

n  확인: 빌드가 정상적이라는 것을 확인하기 위한 스모크 테스트를 수행하거나, 이전 버그의 재현 여부를 확인하기 위해 이전 버그의 리테스트를 수행한다.

 

간략하게 정리하면 다음과 같다.

 

리스크	예방 (Prevention)	확인 (Confirmation)	반증 (Disconfirmation)
새로운 버그	리뷰	유닛레벨 리그레션 테스트 블랙박스 리그레션 테스트	버그 발견을 위한 테스트
이전 버그	리팩토링	이전 버그에 대한 리테스트 수행	버그 발견을 위한 테스트
좀비 버그	정적 분석	유닛레벨 리그레션 테스트 블랙박스 리그레션 테스트	버그 발견을 위한 테스트
빌드 오류	형상관리	스모크 테스트 이전 버그에 대한 리테스트 수행	-

 

앞서 소개한 이런 방법들을 활용한다고 하더라도 궁극적인 테스트가 가능한 것은 아니지만 이런 기법들이 가지는 상대적인 장점들에 대해 불만을 제기받은 적도 없다. 명백한 사실이기도 하지만, 리그레션 문제에 대한 단 하나의 탁월한 해결책은 바로 리그레션 테스트라는 것을 명심해야 한다.

 

그렇다면 리그레션 테스트에 있어서 잘못된 점은 무엇인가? 다음은 이 주제에 대해 알아보도록 하자.