DEVOCEAN

시작하며

Sanity Test는 기획자가 개발이 완료된 기능이 기획 의도대로 동작하는지 빠르게 확인하는 테스트입니다.

개발 이후 QA 단계로 넘어가기 전에, 핵심 기능이 정상적으로 구현되었는지를 사전 검증하는 과정이라고 볼 수 있습니다.

Sanity Test는 QA 프로세스에서 매우 중요한 초기 단계입니다.

단순히 결함을 찾는 과정을 넘어, 핵심 기능이 정상적으로 동작하는지를 빠르게 확인하여 전체적인 QA 프로세스의 효율성을 높이고, 서비스 품질을 보장하는 역할을 합니다.

이 테스트를 통해 개발된 기능이 예상대로 동작하는지, 주요 버그가 없는지를 검증함으로써, 기획자와 QA 담당자는 서비스가 실제로 사용될 준비가 되었는지 신속하게 판단할 수 있습니다.

Sanity Test 목적

SanityTest가 무엇인지 위에서 설명하면서, 주요 목적에 대한 설명은 되었으리라 생각되는데요. 그 외 여러가지 목적은 아래와 같습니다.

• 신규 개발된 기능과 서비스 흐름이 정상적으로 작동하는지 빠르게 확인 합니다.

• 기획자는 본인의 기획한 Feature가 의도한 바에 맞게 적절하게 구현되었는지 Sanity Test를 통해 확인하고 개발에 Feedback을 전달할 수 있습니다.

• 기획 의도와 다르게 개발된 부분을 조기에 발견함으로써 불필요한 리소스가 낭비되는 것을 방지합니다.

• 기획 변경사항 또한 잘 반영되었는지 사전 검토함으로써, 개발과 QA 단계의 혼선을 감소 시킬 수 있습니다.

• 이를 통해 특정 빌드가 배포 가능한 수준인지 판단도 가능합니다.

QA 시작 전 Sanity Test를 통해 미리 점검함으로써, 주요 이슈를 조기 발현하여 수정 시간을 단축할 수 있으며 서비스 안정성을 확보하게 되므로 결과적으로 테스트 품질과 정확도를 높일 수 있습니다.

Sanity TestCase 작성 방법

TC를 작성 하다 보면 자칫 세부적인 기능과 복잡도 높은 케이스까지 고려하여 작성하게 되는데요.

의도한 바가 제대로 적용되었는지 확인하는 것이 주요 목적이기 때문에, 핵심 기능 위주로 간결하게 작성되어야 합니다.

Sanity TestCase를 작성하기 위해서는 아래 기준들을 고려 합니다.

• 핵심 기능이 정상적으로 동작하는지 신속하게 검증할 수 있는 TC 선정

• 테스트 범위를 너무 넓히지 않고 주요 기능과 경로를 중심으로 검토

• 테스트 Data, 테스트 메뉴, 테스트 툴이 준비 되었는지 확인 필요하다면 포함

세부적으로 아래와 같이 여러 기준에 따라 작성할 수 있습니다.

에이닷에서의 Sanity Test 평가

에이닷 서비스에서는 기존 개발 프로세스를 개선하는 과정에서,

후반 품질 검증 단계에서 발생하는 리소스 부담과 일정 지연을 줄이기 위해 좀더 앞단에서 품질을 확보하고자, Sanity Test를 새롭게 도입하게 되었습니다.

이를 통해 주요 기능에 대한 사전 품질을 확보하고, 초기 단계에서 결함을 조기에 발견하여 전반적인 테스트 효율성을 높이고자 했습니다.

또한, 후반부 품질 검증에 집중되던 리소스를 분산 시켜 개발 생산성을 향상 시키고, 보다 안정적인 서비스 제공이 가능하도록 프로세스를 최적화 하였습니다.

에이닷에서는 Sanity Test를 아래와 같은 프로세스로 진행하고 있습니다.

1. 테스트 수행 및 결과 공유

• 개발이 완료된 후, 기획 실무자가 DEV 환경에서 Sanity Test를 수행합니다.

• 테스트 결과는 QA 시작 D-2(working day) 전까지 공유하여, QA 단계에 진입하기 전에 주요 이슈가 없는지 미리 판단할 수 있도록 합니다.

• 만약 STG 환경에서 테스트를 진행하는 서비스의 경우, D-1 전까지 결과를 공유합니다.

2. 테스트 결과 및 후속 프로세스

• Sanity Test 결과에 따라 다음과 같은 후속 프로세스를 진행합니다.

• PASS

  • 테스트 성공률이 80% 이상일 경우

  • STG 배포 하고, QA 준비에 들어감

• FAIL

  • 테스트 성공률이 80% 미만일 경우

  • 후속 프로세스 진행 (일정 재협의)

• SKIP

  • QA 판단 하에 테스트를 진행하지 않은 경우

• FastTrack

  • 긴급한 기획/개발/마케팅 일정으로 인해 Sanity Test를 수행하지 못한 경우

  • Sanity Test Fail로 간주하고 후속 프로세스 진행

3. FastTrack

에이닷에서는 Sanity Test가 Fail되거나 부득이하게 진행하지 못한 경우에도, 무조건적으로 개발 단계로 되돌리는 것이 아니라,

각 팀 간 협의를 거쳐 QA를 진행하고 출시까지 가능하도록 FastTrack프로세스를 신설하여 운영하고 있습니다.

이를 통해 긴급한 일정에서도 유연하게 대응할 수 있도록 하였습니다.

FastTrack은 해당 과제 유관 부서 팀장님들의 결재를 포함하여 진행하고, 승인이 완료되면 QA에 착수 하게 됩니다.

4. Sanity Test 관리

그럼 Sanity Test들을 어떻게 관리하는게 좋을까요?

에이닷에서는 JIRA를 활용하여 각 과제의 Sanity Test를 체계적으로 관리하고 있습니다.

JIRA 티켓을 통해 테스트 케이스(TC) 전달, 진행 상태 추적, 결과 확인까지 일원화된 프로세스로 운영하며, 이를 통해 테스트 과정의 투명성을 높이고 커뮤니케이션을 간소화하였습니다.

특히, 업무 진행 단계에 따라 기획 및 QA 담당자가 JIRA의 상태를 직접 변경할 수 있도록 커스텀하여 활용하고 있으며,

이를 통해 별도의 추가적인 보고 없이도 진행 상황을 한눈에 파악할 수 있도록 했습니다.

이 방식은 테스트 효율성을 높이는 것은 물론, 개발과 QA 간의 협업을 원활하게 만들어 전체적인 품질 검증 프로세스를 개선하는 데 기여하고 있습니다.

• <Sanity Ticket Flow>

  
  

• <Sanity Test 수행 목록 관리 예제>

  
  

마무리

소프트웨어 개발 과정에서는 새로운 기능 추가, 코드 수정, 버그 패치 등이 빈번하게 이루어지는데, 이 과정에서 기존 기능에 예상치 못한 문제가 발생할 가능성이 있습니다.

Sanity Test는 이러한 변경 사항이 시스템의 핵심적인 부분에 부정적인 영향을 미치지 않았는지를 빠르게 확인하는 역할을 할 수 있습니다.

만약 Sanity Test에서 주요 기능이 정상적으로 동작하지 않는다면, 즉시 기획자는 개발팀에 이를 알려 조치 될 수 있도록 하며 불필요한 테스트를 방지하게 됩니다.

문제가 있는 빌드를 초기에 걸러냄으로써 QA 리소스를 보다 효율적으로 활용할 수 있도록 도와주는 필터링 과정이라고 할 수 있습니다.

이를 통해 기획자와 QA 담당자는 서비스가 실제로 사용될 준비가 되었는지 신속하게 판단할 수 있으며, 더 나아가 불필요한 테스트 비용을 절감하고 출시 일정을 지키는 데에도 큰 기여를 하게 될 것입니다.