내 경험이 버그를 잡는다고요?- 경험기반 테스트 활용

안녕하세요. 여기어때컴퍼니 QA팀 브록입니다.

여기어때 서비스를 사용하고 있는 사용자로부터 많은 사랑을 받고있는 지금, 그에 보답하기 위해 여기어때컴퍼니에서도 보다 좋은 서비스를 준비하고 있습니다. 그래서 많아지고 있는 기능들, 보다 개선된 UI를 위한 크고 작은 프로젝트가 끊임없이 저희 QA팀에 전달되고 있습니다. 계속해서 전달되는 프로젝트에서 한정되어 있는 시간과 인력을 가지고 최대한 안정적인 서비스를 유저에게 보여드려야 하는 것이 저희 QA의 역할이라고 생각하는 만큼 검증을 하는 과정에서 효율성을 어떻게 끌어 올릴 수 있는지 고민을 하고 있습니다.

[먼저 명세기반 테스트에 대해서 짚어보자]

경험기반 테스트를 설명드리기 전에, 먼저 명세기반 테스트에 대해 되짚어 봅시다.

명세기반 테스트

프로그램에 대한 명세를 기반으로 요구사항들에 대한 테스트 케이스를 작성하여 프로그램의 기능을 검증하는 방법입니다. 확실한 명세가 있는 상태에서 테스트를 하는 만큼 여러가지 기법들을 적용하여 객관적으로 테스트케이스가 설계되고 테스트결과에 대한 신뢰성을 입증 할 수 있습니다.

• 동등분할 테스트 : 수많은 값을 동등하게 나누고 각 구분 범위에서 하나의 대표값을 선택하여 설계하는 방법입니다. 구분된 범위 내에서 동일한 방식으로 처리될 것이라는 전제조건이 있어야 하며 테스트 케이스 설계와 수행에 시간 절약 효과가 있습니다.
• 경계값 분석 테스트 : 입력값 범위에서 경계값을 중심으로 테스트 케이스를 설계하는 기법입니다. 소프트웨어의 오류는 주로 입력값의 경계에서 발견될 가능성이 높아서 경계값 입력에 대한 결함을 빠르게 찾아내는데에 효과적인 기법입니다. 주로 동등분할 테스트와 많이 병행하여 테스트케이스 설계와 수행 시간 절약에 기여합니다. (예시 : 1~100까지 정수만 입력 가능한 필드에 대해 테스트 케이스를 설계할 경우, 동등분할과 경계값 분석을 같이 적용하여 아래와 같이 설계할 수 있습니다.)

동등분할 테스트 기법과 경계값 분석 테스트 기법을 같이 적용하여 활용한 예시.

• 결정 테이블 : 복잡한 규칙을 가지고있는 시스템의 조건(Condition), 동작(Action)을 분석하여 테이블을 작성하고, 조건에 입력되는 값이 동작하였을 때 어떠한 결과 값이 나오는지 규칙(Rule)을 정의하여 테스트 케이스를 설계하는 방식입니다. 복잡한 시스템을 간결하고 명확하게 표현하여 테스트 케이스를 보다 체계적으로 작성 할 수 있습니다.

회원 결제건수에 대한 등급 변경 케이스를 결정 테이블로 적용한 예시

• 상태전이 : 시스템의 특정 조건이 발생함에 따라 다른 상태로 변경되는 것을 검증하는 테스트 기법입니다. 주로 서비스 Flow와 같이 시스템 전체적인 동작을 파악하여 보다 체계적으로 테스트 케이스를 설계할 수 있습니다.

포인트를 사용한 결제 방법에 대한 상태전이 다이어그램을 이용한 예시

• 페어와이즈 : 검색의 필터 기능과 같이 수많은 변수가 존재하여 모든 변수에 대해 테스트를 하지 않고, 각 변수에 대한 조합에서 중복을 제거하고 최소 한 번씩은 테스트가 가능하게 하는 기법입니다. (페어와이즈에 대해서는 QA팀 카야가 작성해 주신 게시글에서 툴 사용 가이드와 함께 상세하게 다루고 있으므로, 아래의 링크를 참고해 주세요!)
• 페어와이즈 기법을 활용하여 전략적 테스트 설계하기 (feat. PICT)

요구사항을 분석하고 다양한 명세 기반 테스트 기법들을 적용하여 테스트 케이스를 작성하며 순차적으로 테스트를 수행하는 명세기반 테스트는 요구사항에 대한 기능 테스트에서 가장 체계적이고 수치화하기 가장 용이하다는 분명한 장점이 있습니다. 그렇지만, 새로운 요구사항이나 수정 사항이 발생하는 경우 변경 사항들을 반영하는 과정에서 대응이 늦어지는 단점도 가지고 있습니다. 매우 안 좋을 경우에는 테스트 케이스 수정에 많은 시간을 할애하여 일정 내 테스트를 완료하기 어려워지는 상황도 발생할 수 있겠죠. 그나마 테스트를 진행하기 전이나 테스트 초기라면 변경 사항들을 반영하는 것에 집중할 수 있지만, 테스트를 어느 정도 수행하는 중간에 이런 상황이 발생하면 등골이 오싹해지곤 합니다.

[그럼 어떻게 해야하나요? ¯\( ͡° ͜ʖ ͡°)/¯ ]

QA에 있어서 명세 기반의 테스트가 분명히 필요하지만, 유연하게 대처하는 부분에 있어서는 한계가 있는 만큼, 정형적이지 않은 테스트 기법도 병행하면 더욱 효과적이고 효율적으로 테스트를 할 수 있습니다.

대표적인 방식으로는 경험기반 테스트 기법을 병행하여 적용하였을 때, 명세기반 테스트 기법만을 적용했을 때 보다 상대적으로 테스트를 진행하는 시간을 확보하고 유연하게 대처할 수 있습니다. 또한 테스터의 주관하에 커버리지도 확장할 수 있는 효과도 기대해 볼 수 있습니다.

[경험기반 테스트 기법? 그게 뭔데요? ¯\(ツ)/¯]

“경험기반 테스트”라고 하면, 다소 생소하게 들릴 수도 있지만 “경험”이라는 키워드 그대로 기획문서와 같은 명세에 의존하기보다 테스터가 가지고 있는 기술, 경험, 직관을 바탕으로 테스트를 수행하는 방법입니다. 과거에 테스터가 경쟁사의 유사 서비스를 사용해 본 경험에서 오류 추정으로 케이스를 도출해 낼 수 있으며, 주로 체크리스트 기반 테스팅과 탐색적 테스팅을 많이 채용하고 있습니다.

경험기반 테스트의 종류

● 체크리스트 기반 테스팅 : 체크리스트를 만들어 주요 기능이나 영역을 확인하는 방법입니다.

검색/필터 기능 체크리스트 — 예시

● 탐색적 테스팅 : 미리 정해진 테스트 케이스 없이, 테스터가 제품을 직접 탐색하며 테스트를 수행하는 방법입니다.

탐색적 테스팅 — 테스트 노트(예시)

● 오류 추정 : 테스터의 경험을 바탕으로 오류가 발생할 가능성이 높은 부분을 추측해 테스트하는 방법입니다. 주로 테스트 설계 단계에서 과거에 발생하였던 이슈를 토대로 케이스에 추가하여 활용하거나 탐색적 테스트를 수행하며 테스터가 이슈를 추적해 나갈 수 있는 방법입니다.

[어떻게 두 테스트 기법을 같이 사용하지?]

위에서 언급한 명세기반의 테스트에서 발생하는 유연한 대처가 어렵다는 단점을 경험기반의 테스트 기법의 장점으로 해소하는 방법으로 적용할 수 있습니다.

여기어때의 검색과 필터 기능을 예시를 들어보겠습니다. 여기어때에서 제공하는 검색 기능에 대해 의도한 기획에 따라서 입력한 검색어를 형태소로 구분하여 정보가 일치하는 검색 결과를 리스트에 제공 해 줄 것이고, 검색 결과에서 다양한 필터조건을 어떻게 적용하느냐에 따라 리스트 내 결과를 보여줄 것입니다.

여기어때 검색/필터 — 사용자가 찾는 숙소를 다양한 조건으로 검색 할 수 있다

이 기능들을 테스트 케이스로 설계한다고 가정하였을 때, 검색어 입력에 대한 숙소 검색결과와 각 필터 그룹에서 필터를 적용하는 것은 명세기반으로 작성하여 대응하는것은 어렵지 않을 것 입니다.

그러나 검색어와 필터를 조합하여 검색하는 것을 테스트해야 할 텐데, 이런 조합들에 대한 테스트 케이스를 설계한다면 조합에 따라서는 수백, 수천 가지의 테스트 케이스가 발생할 수 있는 이런 상황에서 어떻게 작성할 수 있을까요?

보이는 필터의 개수로만 단순히 조합을 해봐도 무려 20만개를 넘는 테스트 케이스를 작성 할 수 있다.

이런 상황에서 경험기반 테스트 기법이 유용하게 작용합니다. 명세기반으로 작성되어 있는 각각의 검색과 필터 기능은 테스트케이스에서 확인 할 수 있지만, 조합에 대한 테스트는 탐색적테스팅 또는 체크리스트 기반 테스트를 기반으로 테스터의 주관에 따라 여러가지 조합들을 만들어가면서 검증한 내용을 기록하는 방법으로 대응하였을 때, 더욱 효율적으로 테스트를 진행할 수 있을 것입니다. 또한 만약에 테스트 중간에 기획 변경으로 인해 특정 필터의 조건이 바뀌는 상황이 발생하여도 테스트 케이스의 수정 범위가 적고, 변경 사항에 대해서도 유연하게 대응할 수 있습니다.

명세기반 테스트에서 기능상의 이슈가 없다고 판단되는 경우, 추가로 경험기반 테스트를 시작합니다.

위에서 설명해 드린 예시처럼 검색/필터 기능을 대상으로 탐색적 테스팅 기법을 적용하여 테스트를 해보겠습니다. 먼저 테스트 차터에는 프로젝트에 대한 테스트 목적과 테스트 진행 환경 정보, 테스트 진행 시간(Time Box), 테스트 시작&종료 조건 등을 기재하여 사전에 필요한 정보들을 정리하였습니다.

검색/필터 기능에 대한 테스트를 목적으로 작성한 테스트 차터(예시)

어떤 테스트를 진행하였는지에 대한 내용을 테스트 노트에 기재하면서 진행하였고, 발견된 이슈들은 정해진 시간의 테스트 수행을 완료한 후 이슈 티켓을 생성 및 기록하였습니다.

테스트 노트(예시)

이슈 리스트(예시)

이때 경험기반 테스트 기법으로 작성된 검증 케이스들은 프로젝트의 마감 활동에서 테스트 케이스에 반영하여, 추후에 테스트 커버리지를 확장하는 효과를 챙길 수도 있습니다.

[그러면 두 가지 기법을 같이 사용하면 만능인가요?]

명세 기반 테스트 기법과 경험 기반 테스트 기법을 같이 사용함으로 테스트 커버리지를 확장하고 보다 효율적으로 관리할 수 있다는 기대를 해 볼 수 있습니다. 그렇지만 이것은 두 기법의 단점을 서로 보완하기 위함이며 두 가지 방법을 모두 적용한다고 해서 정답이 될 수 없습니다.

특히 경험 기반의 테스트 기법은 어디까지나 “경험”이 초점인 만큼 테스터의 숙련도에서 발생할 수 있는 검증 수준에서의 차이라던지, 여러 명이 테스트를 진행하는 상황에서 지속적으로 경험기반 테스트 수행 내용을 모니터링하지 않을 시 케이스 누락이 발생하는 상황 등을 경계해야 하며 주관적으로 케이스를 도출해 낸다는 점에서 명세기반 테스트 기법과 비교하여 객관성이 부족하다는 단점이 있습니다.

아래에 지금까지 설명해 드린 명세기반 테스트와 경험기반 테스트에 대한 장/단점을 비교한 것을 정리해 보았습니다.

명세기반 테스트와 경험기반 테스트의 차이

각각의 테스트 기법에는 장/단점이 존재하는 만큼 QA는 실제 테스트에서 각 기법을 얼마나 비중을 두고 활용할지 고민하여 보다 효율적으로 일정 내에서 많은 커버리지를 검증할 수 있을 것입니다.

이상, 경험기반 테스팅 기법에 대한 글을 마치도록 하겠습니다.

감사합니다.