[번역] 리그레션 다시 생각해보기 - 파트 2: 리그레션이란 무엇인가?

리그레션 다시 생각해보기 – 파트 2: 리그레션이란 무엇인가?

 

자, 그럼 리그레션이란 무엇인가?

 

리그레션을 간단하게 정의하자면, 소프트웨어가 변경됨으로 인해 기대하지 못했던 결과를 초래하는 리스크가 발생할 수 있고, 이러한 리스크로 인해 소프트웨어의 품질이 저하될 수 있다는 것을의미하는 것이다. 이것이 리그레션에 대한 광범위한 정의이며 그 원인은 다음과 같이 분류될 수 있다.

 

새로운 버그(New Bug): 변경 사항이 앞선 빌드에서 정상적으로 동작하던 부분을 훼손함으로써 새로운 버그를 발생시킨다.

이전 버그(Old Bug): 이전에 발생했던 버그가 다시 재현되는 것을 말한다. 변경 사항이 이전의 수정을 무력화시킴으로 인해 발생한다. 개발자와 함께 버그 주도 개발(Bug driven development) 방식으로 작업을 수행한다면, 아래와 같은 일이 발생할 수 있다.

개발자: 수정 완료했어요!

테스터: 좋습니다. 케이스 A는 이제 제대로 돌아가는군요. 아 잠깐 기다려 보세요.
           케이스 B는 방금 패일이 났습니다.

개발자: 젠장, 좋아요, [코드를 수정한다], 다시 한 번 해주세요.

테스터: 훌륭하군요! B도 동작합니다. 아 그런데 A가 다시 패일이군요...

개발자: @#$% 

애플리케이션의 로직이 복잡할 경우 이런 종류의 일이 빈번하게 발생할 수 있다. 특히 사용자 관점에서 필요한 두 개의 요구사항이 현재 버전에서는 상호 배타적으로 구현되어 있을 수도 있다. 이런 경우 우리는 새로운 설계가 필요하다는 것을 깨달을 때까지 버그들 사이를 갈팡질팡 하게 된다.  

 

좀비 버그(Zombie Bug): 변경 사항으로 인해 잠복해 있던 버그가 노출되는 리스크. 주로 블랙박스 테스팅만으로는 재현되지 않는 버그들이며, 이들은 다른 버그들에 의해 영향을 받거나, 해당 버그가 데드 코드(Dead code)에 숨어있기 때문에 발생한다. 변경으로 인해 동작되지 않던 코드가 다시 사용되기도 하고, 이로인해 묻혀있던 버그가 다시 되살아 나기도 한다.

 

빌드 오류(Bad Build): 이전에 버그를 발생시켰던 코드가 다시 유입되는 것과 같이 버전 관리에 실패한 경우를 의미한다. 앞선 포스트가 바로 이런 경우와 같은 예제라고 할 수 있다.

 

자! 바로 이런 이유들 때문에 우리가 리그레션 테스팅을 수행하는 것이다! 이름에서 이미 단서들이 보이지 않는가? 리스크를 완화시킬 수 있을 것 같지 않는가?

 

급할 건 없다. 실무에서 아주 중요하면서도 미묘한 지점이 바로 여기다. 리그레션과 관련된 모든 문제를 해결할 수 있는 답이 ‘리그레션 테스트’라고 답하기 전에, 이러한 리스크들을 어떻게 완화할 수 있는 지 그 전략에 대해서 시간을 가지고 고찰해보자.

 

케이너(Kaner)와 바크(Bach)가 이러한 리스크에 대해 논의한 문서를 참조해 보라.