The life is REAL

리그레션 다시 생각해보기 – 파트 3: 리스크 완화 전략 앞의 글에서 나는 아래와 같이 리그레션과 관련된 리스크들을 소개했다. 또한 이들이 단지 하나의 독립적인 형태로 나타날 뿐만 아니라 다른 문제와 조합되어 발생할 수도 있다는 것도 언급했다. n 새로운 버그(New Bug) n 이전 버그(Old Bug) n 좀비 버그(Zombie Bug) n 빌드 오류(Bad Build) 이러한 각각의 리스크를 완화시키는 다양한 전략이 존재한다. 주로 아래와 같은 3가지로 전략을 분류할 수 있다. n 예방(Prevention): 리스크 발생을 애초에 방지한다. n 확인(Confirmation): 이전과 같이 동작한다는 것을 검증한다. 리스크가 발생하지 않음을 확인하는 것이 이 범주에 속한다(마이클 볼튼(Michael ..

리그레션 다시 생각해보기 – 파트 2: 리그레션이란 무엇인가? 자, 그럼 리그레션이란 무엇인가? 리그레션을 간단하게 정의하자면, 소프트웨어가 변경됨으로 인해 기대하지 못했던 결과를 초래하는 리스크가 발생할 수 있고, 이러한 리스크로 인해 소프트웨어의 품질이 저하될 수 있다는 것을의미하는 것이다. 이것이 리그레션에 대한 광범위한 정의이며 그 원인은 다음과 같이 분류될 수 있다. 새로운 버그(New Bug): 변경 사항이 앞선 빌드에서 정상적으로 동작하던 부분을 훼손함으로써 새로운 버그를 발생시킨다. 이전 버그(Old Bug): 이전에 발생했던 버그가 다시 재현되는 것을 말한다. 변경 사항이 이전의 수정을 무력화시킴으로 인해 발생한다. 개발자와 함께 버그 주도 개발(Bug driven development)..

이번에 번역한 글은 Iain McCowatt 의 블로그 ‘Exploring Uncertainty’에 올라온 Rethinking Regression 시리즈 입니다. 우리가 잘 알고 있는 리그레션 테스트를 다시 한 번 고찰해 보는 좋은 계기가 될 것 같습니다. 5개의 포스트로 이루어진 연작은 이미 마무리가 된 상태입니다. 각각의 포스트 양이 많지는 않으나 원 저자의 의도를 최대한 살리기 위해 번역 포스트도 5회에 나누어 올리도록 하겠습니다. 번역 및 포스트는 원 저자의 허락을 받았습니다. 원 저자의 요청에 의해 이 게시물은 CCL(Creative Commons License)을 준수합니다. 리그레션 다시 생각해보기 – 파트 1: 힘들게 얻은 교훈 내가 처음 테스트 매니지먼트 일을 시작할 무렵, 반갑지않은 사..

소프트웨어 리그레션 테스트는 소프트웨어 테스트 그룹에 있어 핵심적이면서도 도전할 만한 업무라 할 수 있다. 사전적인 정의에 따르면, 리그레션 테스팅(Regression Testing)은, 추가된 새로운 기능이나 최근의 버그 수정으로 인해 현존하고 있는 시스템의 기능들이 뜻하지 않게 파괴되지 않았다는 것을 증명하기 위한 프로세스이다. 리그레션 테스트의 주된 과제는 가능한 시간 범위 안에서 가능한 한 많은 테스트를 수행하는 것이며 아울러 리그레션 테스트 사이클 안에서 가능한 한 빨리 모든 심각한 리그레션 결함을 찾아내는 것이다. 고전적인 의미의 리그레션 테스트 사이클은: 1. 모든 새로운 기능이 완성되고 모든 주요 버그들이 수정된 소프트웨어의 최종 버전이 소프트웨어 개발팀으로부터 전달된다. 2. 기능 테스트..