[프로입문기] 인수테스트 회고

안녕하세요, 신입사원 Nocturne입니다.

그렇습니다! 기획인턴이었던 저 Nocturne과 개발인턴 jeje는 여러분의 응원을 등에 업고 6월부로 정직원이 되어 맡은 바를 열심히 수행 중입니다. (감사해요!)

제가 인턴 기간부터 맡은 장기간의 업무는 바로 인수테스트였습니다. 주어진 업무를 잘 해낼 수 있을지에 대한 걱정과 처음 업무 필드에 들어간다는 기대를 반씩 안고서 인수테스트를 진행해 보았는데요. 결과적으로는 많은 문제점을 낳았지만 이 문제점들의 해결 방안을 모색하여 보다 나은 방향으로 전진하고자 이번 회고 글을 작성하게 되었습니다.

본격적인 회고에 앞서 인수테스트의 정의는 다양하게 해석되므로 처음 제가 생각했던 인수테스트는 무엇이고, 인수테스트를 한 번 수행해 본 입장에서 생각하는 인수테스트는 어떤 것인지에 대해 개인적으로 정리해 보겠습니다.

인수테스트의 정의와 목적top

내 상식으로는 ‘테스트란 개발한 결과물이 잘 돌아가는지 확인하고 에러를 찾는 것’이었는데… 그럼 인수테스트는 남이 개발한 결과물을 말 그대로 인수해서 테스트만 하면 되는 건가?

이는 큰 착각이었습니다.

회사 면접일에 면접 시험으로 인수테스트 항목을 작성해 볼 기회가 있었습니다. 넉넉잡아 주어졌다고 생각한 시간 안에 손에 꼽을 만큼 작성하는 것조차 어려워 고초를 겪었습니다. 그때부터 이미 인수테스트의 의미, 정의에 대해 잘 모르고 있고 테스트 과정은 생각보다 훨씬 더 많은 수고로움을 요하리라는 것을 인식하고 있었습니다.

그래서 본 인수테스트 전에 직접 인수테스트의 의미와 목적에 대해 정확히 알아봤더라면, 인수테스트 항목 작성은 무분별하게 하는 게 아니라 체계화된 과정을 거쳐야 한다는 걸 미리 숙지했더라면 이번에는 좀 더 효율 좋은 테스트를 수행할 수 있었을 텐데! 하는 안타까움이 이제야 절절히 들 뿐이죠.

본론으로 돌아와 인수테스트를 직접 경험한 테스터의 입장에 서서 인수테스트의 정의를 새롭게 살펴보면,

인수테스트란 고객의 요구 사항에 부합하게 만들어 최종적으로 고객이 인수하게 하는 테스트

라고 생각합니다.

고객님께 최종적으로 전달되기 전 진행하는 테스트이기 때문에 무엇보다 고객님의 요구 사항을 모두 만족시킬 수 있도록 작성해야겠죠.

또한 고객님은 일반적으로 전문 지식을 가진 개발자분이 아니므로 고객님이 온전히 인수하기 위해 고객님의 눈높이에 맞추어 인수테스트 항목을 작성할 필요가 있었습니다. 예를 들어, ‘데이터베이스에서 설정한 key에 따라 제대로 출력되고 있는가’가 아니라 ‘화면에 내용이 추가한 대로 보이는가’정도로, 저뿐만 아니라 개발 지식이 전혀 없는 고객님도 인수테스트 항목을 읽고 따라서 해 보고 결과를 확인할 수 있을 만큼의 배려를 기반으로 작성해야 했던 것이죠.

이처럼 인수테스트에서 고객님이 인수한다, 라는 주요 개념은 어려운 것이었습니다.

그렇다면 이번 인수테스트에서 이 어려운 개념은 과연 어떤 과정을 통해 완성되었을까요? 다양한 인수테스트 방법이 있겠지만 저는 회사에서 사용하는 방법을 교육받게 되었습니다. 회사의 방법론은 기능의 정상 작동을 증명하는 항목과 부가적인 예외 항목을 모두 고려하는 데 중점을 두고 있습니다. 이 조건에 모두 수렴하면 고객님의 요구 사항에 부합하는 인수테스트 항목들을 달성할 수 있겠죠.

그래서 이번 인수테스트는 구체적으로,

(1) 사이트맵 작성
(2) 인수테스트 항목 작성
(3) 인수테스트 진행
(4) 요약 리포트 작성 및 리테스트
(5) 버그 처리 이후 전체 회귀 테스트

라는 과정을 거쳐 진행되었습니다. 이 과정을 단계적으로 살펴보겠습니다.

사이트맵 작성top

인수테스트 항목을 작성하기 전에 사이트맵부터 작성합니다. 여기서 사이트맵이란 만들어진 웹 혹은 앱 개발물을 구성하는 요소를 분류한 것입니다. 사이트맵을 작성하지 않고 인수테스트 항목을 작성하면 어느 페이지에 어떤 구성 요소가 있는지 한 번에 파악하기 어렵고, 고객 요구에 따라 반드시 충족시켜야 하는 인수 항목을 충족시킬 수 없을 만큼 허점이 많도록 작성할 가능성이 높아집니다. 띠라서 사이트맵은 인수테스트 항목의 기반이 되므로 구성 요소를 빠짐없이 작성하는 것이 핵심이었습니다.

그렇다면 사이트맵의 구성 요소는 어떻게 분류하여 작성하는 것일까요?

저는 사이트맵 작성을 위한 구성 요소를 다음과 같이 분류해 보았습니다.
페이지별로 나눈다(대분류) -> 큰 구성 요소별로 나눈다(중분류) -> 작은 구성 요소별로 나눈다(소분류)

인터넷 쇼핑몰의 상품 상세 페이지를 예로 들어 보겠습니다.

페이지별로 대분류를 나눠 보면, 본 페이지는 상품 상세 페이지이므로 대분류는 상품 상세가 되겠습니다.
중분류는 페이지의 큰 구성 요소로 분류하기 때문에 상단에 위치한 상단 바, 상품의 이미지를 보여 주는 상품 썸네일, 상품 상세 설명 부분으로 나눌 수 있습니다.

여기에서 상단 바에만 집중해 보면 순서대로 상품명과 리뷰 개수, 상품의 옵션, 상품의 수량, 상품의 가격, 마지막으로 장바구니 추가 버튼이 있는 것을 볼 수 있는데요. 이 작은 구성 요소 하나하나를 모두 소분류라고 볼 수 있습니다.

그래서 상품 상세 페이지(대분류)의 상단바(중분류)를 구성하는 작은 요소들(소분류)을 사이트맵으로 옮기면 다음과 같이 작성할 수 있습니다.

인수테스트 항목 작성top

사이트맵을 작성하고 나면 본격적으로 인수테스트 항목을 작성하게 됩니다. 인수테스트 항목을 작성할 때 가장 중요했던 세 가지 요소를 예시와 함께 살펴보겠습니다.

첫 번째로, 모든 경우의 수가 빠지지 않도록 작성하려면 앞서 말씀드린 사이트맵에 맞게 작성해야 합니다. 말 그대로 이미 작성한 사이트맵에 인수테스트 항목을 붙이는 형식으로 작성하면 되며, 그 결과는 상단의 인수테스트 항목을 참고해 주시면 됩니다.

두 번째로, 기능의 정상 작동을 증명하는 항목과 부가적인 예외 항목을 모두 고려하여 작성해야 합니다. 부가적인 설명 없이 인식하기 어려우므로 인수테스트 항목 작성 예시를 들면서 같이 설명해 드리겠습니다.

소분류의 가격에 작성할 인수테스트 항목을 생각해 봅시다.

기본 수량은 1이지만, 수량을 2로 바꿔 봅시다. 이때, 가격은 1개의 가격(42,500원)에서 2개의 가격(85,000원)으로 즉시 변동이 일어나야겠죠. 즉, 수량이 바뀔 경우 가격이 수량에 맞게 변동되어야 합니다. 이렇게 정상 작동을 증명하는 항목이 작성한 인수테스트 항목에 누락되어 있습니다. 현재는 부가적인 예외 항목인 수량의 셀렉트 박스 존재 여부, 기본 수량값만 작성되어 있기 때문에 인수 항목의 안정성이 보장되어 있지 않다고 볼 수 있습니다. 따라서 상단의 인수테스트 항목은 다음과 항목이 추가되어야 합니다.

마지막으로, 인수테스트 항목은 참, 거짓으로 평가가 가능하도록 명료하게 작성해야 합니다. 인수테스트 항목을 두루뭉술하게 작성하면 테스트 결과가 0일 경우 어느 부분이 문제인지 정확히 알 수 없어 인수 항목을 온전히 테스트하는 일이 어려워질 수 있기 때문입니다.

추가로 인수테스트 항목 작성을 완료하면 각각의 ID를 부여해 줍니다. 이 ID는 요약 리포트 작성 및 리테스트에서 디버깅 작업을 하는 개발자와 테스터 사이에 소통이 이뤄질 때, 혹은 특정 테스트 항목을 찾고 싶을 때 유용했습니다.

인수테스트 진행top

인수테스트 항목 작성이 완료되면 고객이 요청한 브라우저 환경별로 인수테스트 항목을 따라 테스트를 진행합니다. 이때 테스트 결과가 인수테스트 항목을 만족하는 참이면 1, 만족하지 않는 거짓이면 0으로 기록합니다.

이렇게 1과 0만 체크하면 인수테스트가 끝일까요? 아니죠. 테스트 결과가 0인, 실패한 인수테스트 항목에 대한 처리가 필요합니다. 실패한 인수테스트 항목들은 따로 정리하여 개발자가 처리할 수 있도록 하며, 이 항목들을 정리한 문서를 요약 리포트라고 합니다. 자세한 사항은 바로 다음 단계인 요약 리포트 작성 및 리테스트에서 다뤄 보도록 하겠습니다.

한편, 인수테스트 진행 시 고려해야 할 특이 상황이 있습니다. 인수해야 할 항목이 인수테스트 항목에서 누락되었다는 것을 테스트 중에 발견한 경우에는 어떻게 해야 할까요?

일반적으로 인수테스트 항목이 누락된 것을 테스트 도중에 인식하면 바로 사이트맵에 맞춰 항목을 추가합니다. 그 뒤 기존 인수테스트 항목과 동일하게 테스트를 진행하고, 테스트가 실패한 경우 실패한 인수테스트 항목을 모은 요약 리포트에 작성하게 됩니다.

요약 리포트 작성 및 리테스트top

요약 리포트란 앞서 말씀드렸다시피 인수테스트 항목이 0인, 실패한 인수테스트 항목을 작성한 리포트입니다. 인수테스트 항목은 고객의 요구 조건에 따라 인수해야 하는 항목인 만큼, 실패한 인수테스트 항목을 성공한 인수테스트 항목으로 바꿀 수 있도록 처리하는 과정이 필요하겠죠.

따라서 요약 리포트의 작성 및 리테스트 순서는 다음과 같습니다.

(1) 인수테스트 항목을 0으로 처리
인수테스트 항목을 0으로 처리하는 즉시 요약 리포트 페이지로 넘어갑니다.

(2) 요약 리포트를 형식에 맞게 작성
요약 리포트를 작성할 때는 ‘XX여야 하는 항목(정상 기능 상태)이 현재 YY로 나온다(현재 버그 상태).’의 형식으로 작성해야 합니다. 현재 상태만 기재해 두면 디버깅할 개발자가 기존의 정상적으로 나와야 할 값에 대해 인식하기 어렵기 때문입니다.
또한, 요약 리포트를 작성할 때 작성자의 이름과 담당 개발자의 이름까지 기재합니다. 요약 리포트를 작성하는 작성자와 담당 개발자가 누군지 알아야 서로 보고하고 문의하는 등의 소통을 할 수 있기 때문입니다.

(3) 요약 리포트 작성자가 담당 개발자에게 버그 발생 보고
요약 리포트를 작성하고 나면 지정한 담당 개발자에게 어떤 인수테스트 항목이 어떻게 실패하였는지 보고합니다. 요약 리포트에만 기재하고 담당 개발자에게 즉시 보고하지 않으면 디버깅 또는 기타 처리가 늦어질 수 있기 때문입니다.

(4) 담당 개발자 확인 후 디버깅, 디버깅 완료 후 담당자 확인 1로 처리
담당 개발자가 실패한 인수테스트 항목을 처리하고 나면 요약 리포트의 담당 개발자란을 1로 바꾸고, 요약 리포트 작성자에게 디버깅 완료를 보고합니다. (3)번과 마찬가지로 요약 리포트 작성자가 빨리 확인해야 인수테스트 항목이 실패에서 성공으로 바뀌었는지, 다시 실패되었는지 검증할 수 있겠죠.

(5-1) 처리한 인수테스트 항목을 리테스트하고, 결과가 참이면 작성자 확인 1로 처리
:실패한 인수테스트 항목이 성공한 것을 확인했기 때문에, 다음 인수테스트 항목으로 넘어가 테스트하면 됩니다.

(5-2) 처리한 인수테스트 항목을 리테스트하고, 결과가 실패라면 작성자 확인 0으로 처리, 처리 내용에 해당 사항 작성 후 (3)번으로 돌아감
실패한 인수테스트 항목을 리테스트했을 때 결과가 실패로 나온다면, 작성자 확인을 0으로 두고 처리 내용에 해당 버그가 다시 발생하고 있음을 작성합니다. 작성 완료 후, 담당 개발자에게 버그 발생을 보고하여 처리될 수 있도록 합니다.

소분류 수량의 인수테스트를 마저 생각해 봅시다.

블라우스 수량 1개의 가격은 42,500원입니다. 그런데 수량을 2로 변경했는데도 불구하고 2개의 가격인 85,000원이 아니라 그대로 42,500원의 가격이 표시되고 있죠. 이는 ‘수량이 바뀔 경우 가격이 수량에 맞게 변동됨’의 인수테스트 항목에 위배되는 버그이므로, 요약 리포트 작성이 필요합니다.

(1) 먼저, 테스트 중 실패한 인수테스트 항목이 발생했으므로 인수테스트 항목을 0으로 두고 요약 리포트 작성 페이지로 넘어갑니다.

(2) 수량에 맞게 가격이 표시되어야 하지만 현재 수량을 변경해도 가격이 변동되지 않고 있습니다. 따라서 요약 리포트에 수량이 바뀔 경우 가격이 수량에 맞게 변동되어야 하나, 현재 가격이 수량에 맞게 변동되지 않음.’이라고 작성합니다.

(3) 현재 요약 리포트를 작성하는 작성자의 이름을 기재하면서, 담당 개발자를 지정하여 기재합니다. 요약 리포트를 작성하는 사람이 김테스터, 담당 개발자가 김개발자일 경우 상단의 이미지처럼 작성하면 됩니다. 담당 개발자를 지정한 뒤 작성자인 김테스터가 담당 개발자인 김개발자에게 버그 상황을 보고합니다.

(4) 담당 개발자인 김개발자가 디버깅 또는 기타 처리를 합니다. 이번 예시에서는 가격이 수량에 맞게 변동되도록 수정하는 처리를 했겠죠. 처리 후 처리 내용까지 입력하고 나면 담당자 확인을 1로 만들고, 김개발자는 요약 리포트 작성자인 김테스터에게 보고합니다.

(5-1) 요약 리포트 작성자인 김테스터는 가격이 수량에 맞게 변동되도록 처리했는지 리테스트를 통해 다시 확인합니다. 이를 만족하면 작성자 확인까지 1로 표시하고 다음 인수테스트 항목으로 넘어가면 됩니다.

(5-2) 만약, 담당 개발자인 김개발자의 처리 후에도 김테스터가 리테스트를 했을 시 처리 내용이 적용되지 않았다면 작성자 확인을 0으로 놓고 처리 내용에 현재 상황을 기입해 줍니다.

김테스터는 요약 리포트의 상단 이미지처럼 리테스트 후 상황을 기입하고 (3)번의 과정으로 돌아가서 담당 개발자인 김개발자에게 보고합니다. 김개발자는 다시 수량에 맞게 가격이 변동되도록 처리 과정을 거치고 김테스터에게 확인 요청을 하겠죠. 김테스터는 처리 과정을 거친 이 항목을 리테스트하여 인수테스트 항목의 성공 또는 실패를 재확인할 것입니다.

버그 처리 이후 전체 회귀 테스트top

한편, 버그 처리 이후에 새로운 버그가 발생하거나 기존 테스트에서 누락된 항목이 추가되는 경우도 있습니다. 또한 버그를 수정한 것이 다른 항목에도 해당 처리가 영향을 끼쳤을 확률이 높습니다. 따라서

  1. 요약 리포트에서 수정 처리한 항목 + 누락된 테스트 추가 항목 + 기존 테스트 항목을 모두 합쳐
  2. 새로운 인수테스트를 작성합니다.
  3. 그 후 새로 작성된 인수테스트를 기준으로 전체 테스트를 다시 진행하는데, 이 테스트를 ‘회귀 테스트’라고 합니다.

회귀 테스트 중 아래와 같이 가격이 장바구니 추가 버튼의 범위까지 침범하는 것을 발견했다고 가정해 보죠.

이전에는 인수테스트 항목 테스트 시 ‘가격이 알맞게 표시됨’으로 정상 작동했으나 현재는 해당 항목을 만족하고 있지 않기 때문에 항목이 1로 표시되어 있던 것을 0으로 수정하고 새로운 요약 리포트를 작성하게 됩니다.

요약 리포트에 ‘확인 결과, 가격이 알맞게 표시되어야 하는데, 현재 가격이 장바구니 추가 버튼을 침범하여 표시되고 있습니다.’라는 상황을 기입합니다.

요약 리포트 작성을 완료한 김테스터는 김개발자에게 현재 버그 상황을 보고합니다. 김개발자는 확인 후 가격이 장바구니 추가 버튼을 침범하지 않고 알맞게 표시되도록 처리합니다. 처리 후 담당자 확인을 1로 바꾸고 김테스터에게 다시 보고합니다. 김테스터는 리테스트를 거쳐 해당 항목을 성공 또는 실패로 판단하겠죠.

결국 이러한 과정이 끝없이 반복되며 최종적으로 일정 수준에 이르면 버전을 픽스하게 됩니다.

  • 인수테스트 작성 → 전체 테스트 → 버그 리포트 + 추가테스트 → 새로운 인수테스트 작성(영원한 윤회?)

이렇듯 실패한 인수테스트 항목 하나를 성공시키는 데에는 까다로운 과정이 녹아 있을 뿐만 아니라, 성공했던 인수테스트일지라도 다시 실패하는 변수가 존재할 수 있기 때문에 인수 항목의 안정성을 명확히 보장하려면 회귀 테스트가 꼭 필요하다는 것을 알 수 있습니다.

보다 나은 인수테스트를 위하여top

초입에서 말씀드렸던 것처럼 업무 필드에서는 처음 작성해 본 인수테스트 항목인 만큼 많은 문제점이 발생했습니다. 다음 테스트 업무를 할당받을 때는 같은 실수를 최대한 반복하지 않도록 문제점 및 개선점을 짚고 넘어가 보도록 하겠습니다.

(1) 인수테스트 항목은 불린(boolean)으로 작성하고, 기능의 정상 작동을 증명하도록 작성해야 한다.
인수테스트 항목은 불린(boolean), 즉, 참과 거짓으로 판명할 수 있도록 명료하게 작성해야 합니다. 저는 불린에 따르지 않고 참, 거짓으로 평가하기 어렵게 작성하는 실수를 범해 판정하는 데 오랜 시간을 소요하여 테스트 수행 시간을 비효율적으로 사용하였습니다. 보다 나은 인수테스트 항목 작성을 위해서는 복잡한 경우의 수를 가지는 항목은 각각 따로 분류해서 작성해야 보다 효율적인 시간 사용이 가능하게 합니다.

또한 저는 기능의 정상 작동을 증명하는 항목에 집중하지 않고, 예외 항목에만 집중하여 작성했기 때문에 막상 인수테스트를 진행했을 때 해당 인수테스트 항목의 안정성을 보장할 수 없는 상황이 많았습니다. 기능의 정상 작동을 증명하는 항목이 어떤 것인지를 우선적으로 생각하고, 예외 항목은 부가적으로 생각하여 작성하는 것이 올바른 인수테스트 항목 작성법이라고 생각합니다.

(2) 인수테스트 항목이 추가되면 인수테스트 항목은 버전 업이 되어야 한다.
테스트를 하다 보면 인수테스트 항목에서 누락된 항목이 새로 추가되기도 하고, 개발자의 처리 이후 새로운 버그가 발생하기도 합니다. 이번 인수테스트를 수행하는 동안에는 기존 인수테스트 항목을 작성한 사이트맵 하나에 추가된 인수테스트 항목을 모두 업데이트했습니다. 이렇게 되면 회귀 테스트를 하더라도 누락된 인수테스트 항목이 존재할 수 있어 공정률이 떨어질 수 있습니다.

이를 해결할 수 있는 좋은 방법은 버전 업을 해 주는 것입니다. 여기서 버전 업이란, 인수테스트 항목이 완전히 갱신되는 것이 아닌, 인수테스트 항목의 테스트를 모두 진행하고 요약 리포트 작성 및 처리가 전부 끝났을 시점에 요약 리포트에서 수정 처리한 항목 + 인수테스트 도중 누락된 걸 인식하고 추가한 항목 + 기존 인수테스트 항목을 모두 총합하여 회귀 테스트를 할 수 있도록 전체 인수테스트 항목을 업데이트하는 것을 말합니다. 이렇게 버전 업을 하게 되면 언제, 어떤 인수테스트 항목이 추가되었는지 확인할 수도 있고 새로운 버그가 발생했는지 회귀 테스트를 수행하면 알 수 있어 테스트의 공정률을 높이고, 기능 정상 작동의 안정성이 보장될 수 있습니다.


회사 면접일 당시, 테스트 항목을 한두 개 채우는 것만으로 땀을 뻘뻘 흘리며 고초를 겪었던 것을 떠올리면 험난한 과정을 떠나 천 개가 넘는 인수테스트 항목을 작성하고 테스트해 봤다는 사실 자체에 대한 성취감이 남다른 것 같습니다. 비록 요약 리포트의 항목이 무분별하게 늘어나 테스트 기간이 길어지는 등 효율성이 떨어지는 결과를 낳기도 했지만 이번에 쌓은 테스트 요령을 바탕으로 다음 테스트는 좀 더 빠르고 수월하게 진행할 수 있기를 바라며, 앞으로도 꾸준히 성장하는 Nocturne의 모습 보여 드리겠습니다!