X
STEN 회원이 되시면 테스팅에 관한 많은 정보와 자료를 공유할 수 있도록 저희가 돕겠습니다.
아이디
패스워드
자동로그인 사용
 
아직 회원이 아니십니까?    
아이디/패스워드를 잊으셨습니까?    

     
   
확인 테스팅의 범위는 어디까지일까요?
글쓴이 : 똘칠 날짜 : 19-05-28 22:20 조회 : 3534


동료들에게 자주 듣는 질문 중 하나는 리그레션 테스팅과 확인 테스팅의 차이점입니다. 그것이 업무에 적용할 때 과연 얼마나 미묘하게 다르냐?!?!에 대한 것이죠. 뭐 그런 것을 질문하지? 질문꺼리가 되나?’ 라고 생각하실 수도 있습니다. ISTQB 시험 공부할 때를 돌이켜 보면 이 둘의 구분이 어렵지 않으니까요

그렇다면, ISTQB Foundation Level Syllabus (v2018)에서 언급한 정의를 먼저 살펴보겠습니다.

확인 테스팅(Confirmation testing)은 결함이 수정된 후 이 결함으로 인해 불합격했던 모든 테스트 케이스를 새로운 Software 버전에서 재실행하는 활동을 말합니다. 결함을 제대로 수정했는지 확인하는 것이 바로 확인 테스팅의 목적인 것이죠.

리그레션 테스팅(Regression testing)은 의도하지 않은 부작용을 발견하기 위한 테스트를 수행하는 것을 의미합니다. 코드에 어떠한 수정을 가한 경우, 그 수정이 의도치 않게 코드의 다른 부분에 영향을 줄 수 있기 때문입니다. 문제가 없던 부분에 문제가 발생한 것이 아닌가를 살펴보는 것이 바로 리그레션 테스팅의 목적인 것이고요.

정의를 놓고 보자면 크게 문제될 일이 없을 것 같습니다. 고친 것이 잘 고쳐졌는가, 고치지 않은 것들이 그대로 있느냐의 차이이니까요. 하지만 현업에서 돌아가는 업무를 살펴보면 대체로 확인 테스팅을 수행할 때 정확히 콕 집어 그 결함 딱 하나만을 확인하고 테스트를 끝내지는 않는 편입니다

검증이 후반부로 향할수록 더더욱 그렇고요. 문제가 되는 주인공 결함과 그 주변에 영향을 줄 수 있는 조연들도 함께 확인을 하는 편입니다. 그 확인 범위는 어느 정도이냐? 라고 물으신다면 해당 결함과 관련한 리스크의 크기만큼이라는 아주 몹시 교과서 적인 모범생 정답을 말씀드릴 수가 있겠네요

주연과 조연을 모아 확인 테스팅을 수행하다 보니, 엄청나게 큰 크기의 완전체 리그레션 테스팅은 아니지만, 해당 결함과 관련한 작은 크기의 리그레션 테스팅을 수행하게 됩니다. 이러한 활동을 조직에 따라 확인 테스팅이라고 부르기도, 리그레션 테스팅이라고 부르기도 하는 소통하기 애매한 현상이 발생하는 것이죠.

아무래도 제품이 출시되기 바로 직전에 수행하는 테스팅 활동에서는 확인 테스팅이라 쓰고 리그레션 테스팅이라 읽을 확률이 높을 것입니다. 때문에 프로젝트 내에서의 원활할 소통을 위해서는 테스트 계획서를 작성하는 시점에 확인 테스팅과 리그레션 테스팅의 범위를 명시해야 할 것입니다.

확인 테스팅에 대한 이슈는 범위 뿐만이 아닙니다. 반복에 대한 문제가 남아있죠. 때에 따라 어떠한 결함은 100번, 500번 반복 또는 10시간 반복과 같은 종료 조건이 따라붙는 경우가 있습니다.

이러한 조건이 굳이 붙어있지 않는 결함도 일반적으로 Closed 하기 전에 몇 번 정도는 반복해서 확인을 하고 있습니다. 종종 동료들에게 물어보면 대략 3~4번은 확인을 하시더군요. 그 이상 확인하는 경우도 많고요.

하지만 “조직에서 확인 테스팅 시에 최소 몇 회 반복하다는 정의를 해 놓으셨는지(조직 차원의 전략에 명시를 하셨는지)?” 질문했을 때 “네. 했습니다”라는 답변을 들어본 적은 없습니다. 대부분 “그 때, 그 때 달라요”, “사람마다 달라요”, “내 마음 나도 몰라요” 라고 말씀하시죠. 아마도 본능적으로 리스크에 따라 다르게 반복 회수를 설정한다는 의미일 것으로 해석하고 있습니다.

한데, 같은 테스트를 반복하게 되면 그것은 기능을 확인하기 보다는 비기능, 즉 제품 품질 특성을 확인하는 개념으로 확장이 됩니다. 품질 특성을 확인할 때 반복이 중요한 특성은 크게 두 가지로 볼 수 있습니다.

하나는 기능 정확성입니다. 반복을 아무리 해도 그 값에 오차가 없는지를 확인하는 것이지요. 다른 하나는 신뢰성 중 성숙성이라는 부특성입니다. 이 특성은 제품이 표준 환경에서 고장을 회피하며 신뢰도를 충족시키는 정도를 의미합니다. 때때로 성숙성이 중요하게 부각되어 확인 테스팅 시의 종료 조건이 ‘많은 반복’이 되는 경우가 있습니다. 그러한 것을 제외한 경우에는, 도메인의 특성에 맞게 적당한 회수를 확인한 뒤 종료하는 것이 바람직하다고 생각합니다.

반복 회수를 과다하게 높게 책정한다면, 그것은 기능에 대한 완성도 확인이라는 본래의 목적과는 다르게 품질 특성 쪽으로 치우쳐 확인 테스팅을 수행하게 될 수 있기 때문입니다. 만약 성숙성이 중요하다면 확인 테스팅에 숟가락을 얹는 것 보다는 별도의 제품 품질 특성 테스팅을 짱짱하게 준비하는 것이 바람직합니다.

확인 테스팅의 체계를 잡으신다면, 테스팅 계획서 작성 시에 위에서 언급한 것처럼 다양한 관점에서 고민을 해보시기를 바랍니다. 결국 모로가도 테스팅은 계획서에서 만나네요.

담배를끊어야돼 19-05-30 10:14
좋은 글 잘 봤습니다.
실제 업무에서 용어에 대한 인식 차가 있어서 소통이 자연스럽지 않은 경험이 있는데요.
그래서 저는 여러가지 테스트 구분(?)이 섞인 경우 기존 표준 용어 보다는 새로운 이름을 붙여줍니다.
수정 확인과 퇴행 확인을 모두 하는 테스트 단계에 "확인퇴행 테스트" 또는 릴리즈 직전이라면 "사전 테스트" 등 으로 부르기도 했는데요. 사실, 조직에서 테스트 단계 정의만 잘 되어 있다면 기존 개념 용어를 사용해도 내부에서 사용하는 언어이기에 별 문제는 없을 겁니다. 실제 업무에서 한가지 테스트 구분만 가지고 테스트 단계를 만드는 경우는 드물기 때문이죠.
반복 회수도 짚어 주셨는데, 제 개인적인 경험으로는 "재현율 X 리스크(0~5)" 정도의 명시가 적당한 것 같습니다. 더욱 테스트를 정밀하게 제어하고 싶다면 상황적인 요소나 시간 배분, 예외 사항 등을 추가해야 겠군요. 다른 분들은 어떻게 정의하고 있는지 궁금합니다.
덕분에 더 생각해 보고 갑니다. 감사합니다.
     
똘칠 19-06-02 09:31
말씀 감사합니다. 현업에서 많은 생각을 하신 것이 댓글에서 느껴집니다.
저희도 종종 어떠한 테스팅에 새로운 이름을 짓는 경우가 있는데요, 시간이 흐르면서 상당수의 동료들이 테스팅 공식 용어라 생각하고 외부와 소통시에도 사용을 많이 하시더라고요. 항
상 자료에 용어에 대한 설명을 싣는 것도 간단하지는 않아 어떤 결정을 내려야할지 참 고민스럽습니다.