[번역] 리그레션 다시 생각해보기 - 파트 1: 힘들게 얻은 교훈

 

이번에 번역한 글은 Iain McCowatt 의 블로그 ‘Exploring Uncertainty’에 올라온

Rethinking Regression 시리즈 입니다.

우리가 잘 알고 있는 리그레션 테스트를 다시 한 번 고찰해 보는 좋은 계기가 될 것 같습니다.

 

5개의 포스트로 이루어진 연작은 이미 마무리가 된 상태입니다.

각각의 포스트 양이 많지는 않으나 원 저자의 의도를 최대한 살리기 위해 번역 포스트도 5회에 나누어
올리도록 하겠습니다.

 

번역 및 포스트는 원 저자의 허락을 받았습니다.

원 저자의 요청에 의해 이 게시물은 CCL(Creative Commons License)을 준수합니다. 

리그레션 다시 생각해보기 – 파트 1: 힘들게 얻은 교훈

 

내가 처음 테스트 매니지먼트 일을 시작할 무렵, 반갑지않은 사건이 하나 있었다.

 

문제가 된 테스팅 사이클은 대량의 버그 수정 사항을 리테스트 하고, 이와 함께 수정으로 인해 영향을 받은 모듈들에 대해 리그레션 테스팅을 수행하는 것이었다. 테스트 대상이 아닌 다른 모듈들은 변경 사항에 대해 어떤 영향도 받지 않았다.   

 

일부 사소한 버그 외에는 큰 문제가 없었으므로, 테스트는 좋은 결과로 패스되었다.
그리고 우리는 맘편하게 그 빌드를 UAT(User Acceptance Test)로 넘겼다.

 

30분 정도 지났을 무렵, 격분한 프로젝트 매니저가 내 책상으로 달려왔다.
사용성 테스터들이 애플리케이션의 다른 부분에서 심각한 문제들을 여러 개 찾아내었다는 것이다.
귀에 익숙해질만한 내용의 문제였다.

 

몇 시간 정도 테스트를 더 수행하고 나서, 우리는 뜻밖의 결론에 도달했다.
잘못된 버전 관리(Version control)로 인해 지난 몇 달간 수행된 수정 작업들이 깨끗하게 날아간 것이었다.

 

이 사실을 알고 난 PM의 반응은 이랬다.

“왜 그걸 미리 테스트하지 못했지? 리그레션 테스팅을 수행한다고 그랬잖아!”

 

그 날 나는 중요한 교훈을 배울 수 있었다.

바로  ‘항상 풀 리그레션 테스팅을 수행해야 한다’ 는 것이다.

 

하지만 결과적으로는 불행하게도, 그것은  전적으로 잘못된 교훈 이었다.

 

리그레션 테스팅, 리그레션 테스트에 대한 사고방식, 그리고 일반적인 리그레션 테스트 사례들이 테스터들과 그들이 일하고 있는 프로젝트에 심각한 이슈를 일으키게 만드는 장본인이다.

이번 시리즈는 이 주제에 대해 좀 더 깊게 알아보고자 한다.