요즘 QA 직무에서 자동화 테스트에 관한 관심이 뜨겁습니다. 그래서 그런지 많이 듣는 질문 중 하나가 "올리브영은 자동화 테스트를 어떻게 하고 있나요?" 였습니다. 그래서 드디어 가져왔습니다!! 올리브영에서 진행되고 있는 자동화 테스트 그중의 일부를 소개하고자 합니다.
자동화 테스트를 도입하게 된 배경이 무엇인가요?
테스트하다 보면 반복적인 테스트를 진행하는 경우가 많다고 느끼실 수 있습니다.
이걸 내가 매번 확인해야 해? 지겹네? 리소스 낭비 아니야?? 라는 생각이 든다면!! 자동화 테스트를 도입해야 해야 할 때라고 생각합니다.
이러한 반복적인 테스트를 자동화하여 효율적으로 테스트를 진행하고자 하였습니다.
또한 항시 서비스 모니터링을 진행하고 있을 수 없으므로 서비스에 문제가 발생했을 경우 인지 자체를 못 하는 경우가 있습니다. 이러한 문제를 해결하기 위해 자동화 테스트를 도입하게 되었습니다.
올리브영은 자동화 테스트를 어떻게 활용하고 있나요?
올리브영에서 자동화 테스트를 활용하는 용도는 아래와 같습니다.
- STG 통합테스트, 정기 배포, 긴급 배포, 분리 배포 후 테스트
- 상시 운영 모니터링
크게 2가지 영역으로 활용되고 있고 다양한 자동화 테스트가 존재합니다.
대표적으로 3가지만 말씀드리면 아래와 같습니다.
- CSP 자동화 테스트
- CSP를 기반으로 사용자 플로우 위주로 자동화 테스트를 진행
- API 자동화 테스트
- API를 기반으로 자동화 플로우 테스트를 진행
- UI 자동화 테스트
- 각 영역별 상세한 UI에 대한 자동화 테스트를 진행 오늘은 STG 통합테스트, 정기 배포, 긴급 배포, 분리 배포 후 테스트에 CSP(Critical Serving Path)를 기반으로 자동화 테스트를 도입한 것에 관한 이야기 하려고 합니다.
CSP 자동화 테스트는 무엇이며 어떤 영역을 자동화 테스트하고 있나요?
올리브영은 인시던트를 어떻게 관리하고 있는가? 블로그 글을 읽어보신 분들은 아시겠지만, 올리브영은 CSP를 정의하고 있습니다.
정의된 CSP에 대해서 사용자 플로우 위주로 자동화 테스트를 진행하도록 **사용자 플로우 위주로 TC(Test Case)**을 구성하였습니다.
CSP 플로우를 흘러가는 동안 꼭 확인해야 할 항목들만 확인하고 있습니다.
그렇다면 여기서 왜 CSP 플로우에 포함된 페이지의 모든 기능, 항목들에 대해서 전부 확인을 하지 않나요? 라는 의문이 들 수 있습니다.
모든 항목을 자동화하면 좋지만, 자동화 테스트를 구축하는 것도 어쨌든 인력이 소모되게 됩니다. 그렇기 때문에 UI 변경이 잦은 영역까지 모두 자동화하기에는 오히려 유지보수 측면에서 비효율적이라고 판단하였습니다.
수동 테스트를 하는 것보다 UI 변경이 잦음으로 인해서 인력이 더 소모되게 된다면 그것은 성공적인 자동화 테스트 도입이라고 보기 어렵습니다.
그렇기 때문에 자동화 테스트를 성공적으로 도입하기 위해서는 어떤 영역을 자동화 테스트할 것인지, 어떤 항목들을 자동화 테스트할 것인지에 대한 선별이 중요하다고 생각합니다.
어떤 환경에서 자동화 테스트를 진행하고 있나요?
자동화 테스트에는 여러 방법이 있지만 가장 정확하게 테스트하고, 결제 테스트까지 진행하기 위해 실기기를 이용하기로 했습니다.
CI/CD 툴로는 Teamcity을 사용하고 있으며 테스트 자동화 도구로는 selenium과 appium을 이용하여 자동화 테스트를 구축하였습니다.
CSP 자동화는 언제 수행되나요?
CSP 자동화는 현재 아래의 경우 수행되고 있으며 서로 다른 목적을 지닙니다.
1. STG 통합테스트
정기 배포 이전, 모든 코드를 STG 브랜치에 병합한 후 통합 테스트를 진행합니다. 이 과정에서 CSP 자동화 테스트를 활용하여 다음과 같은 문제를 사전에 방지합니다:
- 코드 병합으로 인한 사이드이펙트 발생
- 컨플릭트 수정 후 기존 기능의 비정상 동작
- STG 통합 테스트는 매주 1회 실행되며, CSP 자동화를 통해 테스트 리소스를 효율적으로 절감하고 있습니다.
2. 정기 배포
매주 1회 이루어지는 정기 배포에서도 CSP 자동화 테스트를 동일하게 수행합니다. 이는 STG 환경과 동일한 모니터링 테스트를 통해 품질을 보증하며, 리소스 절감 효과를 제공합니다.
3. 긴급 배포, 분리 배포
과거에는 리소스 문제로 긴급 배포와 분리 배포 시 모니터링을 진행하지 않아 품질 검증이 어려웠습니다. CSP 자동화 테스트 도입 후 주요 기능에 대한 품질 보증이 가능해졌으며, 배포 시 발생할 수 있는 리스크를 최소화할 수 있었습니다.
4. 매일 오전 1회
코드 배포가 없는 상황에서도 CSP 자동화 테스트는 매일 오전 1회 실행됩니다. 이는 운영상의 다양한 문제를 사전에 탐지하기 위함입니다.
- 탐지 대상: 인프라 문제, 백오피스 설정 오류 등
- 도입 배경: 올리브영은 이커머스 서비스로, 매일 상품, 프로모션, 쿠폰, 콘텐츠 등 다양한 데이터가 변경됩니다. 이 과정에서 설정 오류가 발생할 경우 기대한 결과와 실제 결과 간 차이가 생길 수 있습니다. CSP 자동화 테스트는 이러한 문제를 조기에 발견하여 해결하는 데 기여하고 있습니다.
CSP 자동화 테스트 수행 방식은 어떻게 되나요?
시점별로 수행 방식도 약간씩 상이합니다.
STG 통합테스트
- 수행 방식: TeamCity에서 수동으로 버튼을 눌러 실행
- 특이 사항: 배포 시간과 순서가 일정하지 않아 자동화 실행은 제한적
정기 배포, 긴급 배포, 분리 배포
- 수행 방식: 운영 배포 시 Blue-Green Deployment를 활용
- 특이 사항:
- 배포 완료 후 유저 트래픽을 Blue or Green Zone으로 전환
- Datadog에서 Hit Rate를 모니터링하며, 특정 기준치를 초과하면 자동으로 TeamCity를 실행하여 CSP 테스트를 수행
매일 오전 1회 테스트
- 수행 방식: TeamCity의 스케줄링 기능을 활용하여 자동 수행
CSP 자동화 로직에 대해서 자세히 알고 싶어요.
예를 들어, 고객이 임의의 상품을 구매한다고 가정해보겠습니다.
이 간단한 플로우에서도 조합에 따라 다양한 케이스들을 확인해야 합니다.
그러면 일단 상품 유형에 대해서 생각해 보겠습니다.
직매입, 위수탁 두 가지 케이스로 나눠서 확인해야 한다고 해보겠습니다.
그렇다면 여기서 직매입, 위수탁 상품을 어떻게 선정할 것인가요? 랜덤으로 선정할 것인가요? 아니면 미리 정해진 상품을 선정할 것인가요?
처음에는 미리 정해진 상품을 선정해 놓고 테스트할지 생각했습니다. 하지만 수시로 변경되는 상품 상태, 상품 프로모션 등 대한 부분은 어떻게 체크할 것인가? 라는 생각이 들었습니다.
많은 분이 자동화 테스트를 도입하실 때 UI 위주로 버튼이 눌리는지, 상품 가격이 뜨는지 등은 확인하시지만 그 상품 가격이 맞는지, 그 상품이 품절 상태가 맞는지는 고려하지 않는 경우가 많습니다.
정확한 테스트가 되기 위해서는 데이터의 정합성도 체크가 되어야 한다고 생각합니다.
그래서 존재하는 API를 이용하여 상품을 선정하고 상품 정보를 받아오는 방식을 선택하였습니다.
백오피스 API를 통해 직매입 상품 코드를 확인하고 그 상품 코드를 통해서 재고 API, 상품 상태, 적용된 상품 프로모션 등을 확인하여 상품 상태, 가격, 할인 금액, 옵션별 금액 등의 정보를 저장합니다.
만약 재고가 존재하는 케이스를 테스트를 위한 상품을 선정 중이라면 백오피스에서 찾은 상품이 재고가 없다면 다음 상품을 가지고 다시 테스트 케이스에 적합한 상품인지를 확인하고 있습니다.
이 저장된 정보를 가지고 상품에 진입하여 상품 가격의 원가, 프로모션가 등이 맞는지 확인하고 결제로 넘어갔을 때 배송비 정책 등이 맞는지 확인 후 결제 완료 시에도 결제 금액이 맞는지 확인하도록 구성했습니다.
올리브영은 아직 rest api로 되어있지 않은 부분들이 있어 이런 부분들에 대한 정보를 가져오도록 하는 부분이 어려웠고 정보를 가져오는 부분에서 넘기는 파라미터마다 어떤 의미를 가지고 있는지에 대한 부분의 문서가 없는 상태여서 추측하여 진행하는 부분이 있었습니다.
그래서 하나하나 테스트를 진행하면서 정보를 확인하여 구축을 진행하였는데 rest api로 되어있는 시스템이라면 한결 구축하는데 수월할 것으로 생각됩니다.
그리고 아직 api로 정보를 가져오지 않고 db에서 정보를 조회하여 보여주는 부분들이 있어 그 부분들에 대한 처리를 어떻게 할 것인지에 대한 고민이 있습니다.
이렇게 구성한 이유에 대해서 쉬운 예시를 드려보겠습니다.
품절 테스트를 하기 위해서 재고가 없는 상품을 선정했다고 가정해 보겠습니다.
해당 상품에 접근했는데 주문이 된다면? 이는 과주문을 발생시킬 수 있는 문제이기 때문에 이러한 케이스를 찾아내는 것이 중요합니다.
만약 상품의 재고를 확인하지 않고 UI만 확인했다면 이 상품이 품절 상태로 떠야 하는지, 구매 가능한 상태여야하는지 판단하기 어려웠을 것입니다.
자동화 테스트에 관심이 많으신 분들이 UI 쪽 기능에만 포커스를 맞추기보다는 API를 통한 정보들과 연동을 통해서 더 정확한 테스트를 할 수 있는 방식을 고민하시면 좀 더 정확한 테스트를 진행하실 수 있다고 생각합니다.
그렇다면 여기서 왜 직접 설정하여 상품을 등록하거나, 프로모션 등록 등을 하여 로직을 구성하지 않았는지에 대해 의문이 드는 분들이 계실 것입니다. 이 부분은 회사마다 다른데 올리브영의 경우는 정책상 STG나 운영에는 테스트 상품이나 테스트 프로모션 등 등록하는 것을 지양하고 있습니다. 그렇기 때문에 API를 통해 정보를 가져와서 테스트를 진행하고 있습니다.
만약 등록이 가능한 서비스라고 한다면 백오피스에 입력한 정보들과 고객이 접근해서 보는 정보가 일치하는지를 확인하면 좋을 것 같습니다.
결과 리포트는 어떻게 하고있나요?
모든 케이스는 testrail에 등록되어 있고 결과를 testrail에 기입하게 되어있습니다.
그리고 테스트 결과에 대한 리포트는 slack으로 전송되게 되어있습니다.
테스트 결과에 대한 리포트는 아래와 같이 전송되게 됩니다.
결과에 대한 수치는 testrail에서 제공하는 API를 활용하고 있습니다.
testrail에 결과를 기입하다 보면 FAIL로 발생하는데 왜 FAIL였지? 하는 의문이 들곤 했습니다.
테스트 당시에 일시적으로 문제가 발생하는 경우도 있고 element를 못 찾는 경우도 있는데 element가 없어서 못 찾은 건지, 진짜 없었는지에 대한 판단이 어려웠습니다.
그래서 테스트하는 동안 핸드폰 녹화 기능을 이용하여 당시 상황을 녹화하여 PC에 저장해주는 방식을 동시에 활용하고 있습니다.
빠른 결과리포트 확인이 중요한 이유
결과 리포트 확인이 중요한 이유는 문제가 되는 기능들은 주요 기능으로 문제가 있을 시 빠른 대응을 위해서입니다.
올리브영은 자동화 테스트가 완료되면 결과 리포트를 즉각적으로 확인하여 문제가 있을 경우 모든 사람이 참여되어있는 채널에 공유하고 있습니다.
그러면 해당 영역의 담당자분들이 내용을 확인하여 범위를 확인 후 인시던트를 선언할지 단순 이슈 사항인지 확인을 진행하고 있습니다.
인시던트일때는 빠른 대응이 중요하기 때문에 이렇게 빠른 결과 리포트 확인을 통해 빠른 대응을 할 수 있습니다.
CSP 자동화 테스트를 통해 검출된 이슈의 예시에는 무엇이 있나요?
- 주문서 UI 깨짐 현상
- 부분 취소 오류
- A쿠폰을 받았는데 B 쿠폰이 받아짐
이런 영역들은 고객 주문에 가장 밀접한 부분이지만 기존에는 이러한 이슈가 발행하여도 voc가 들어오거나 배포 후 한참 지난 후에 알게되는 경우가 있었는데 그런 부분을 많이 줄 일 수 있었습니다.
또한 csp 영역 모니터링을 자동화로 대체하여 기존에 모니터링 하던 리소스를 제외하여 평균 2MD의 리소스 감소를 가져올 수 있었습니다.
마치며
저도 자동화를 도입하면서 여러가지 시행착오를 거치게 되었고 계속해서 어떻게 해야 더 오류 검출을 잘하고, 유지보수는 덜하고 쉽게 할 수 있을까? 라는 고민을 하고 있습니다.
자동화 테스트를 도입하는 것에는 정답이 없는 것 같습니다. 서비스마다의 특징이 있고, 중요한 부분이 다르기 때문입니다.
기술에 대한 부분을 많이들 걱정하시는데 기술이 좋은 것도 중요하지만 그 기술을 어떻게 활용하느냐가 더 중요한 것 같습니다.
그렇기 때문에 자동화 테스트를 도입할 때는 어떤 효과를 얻고 싶은지, 어떤 부분을 자동화 테스트 도입했을 때 효율적인지, 어느 부분에서 문제가 많이 발생하는지 등에 대해서 먼저 고민을 해보는 것이 좋을 것 같습니다.
효과에 대한 고민을 하여 커리어 성장에도 도움이 되고 팀에도 도움이 되는 자동화 테스트를 도입할 수 있길 바래봅니다.
올리브영 UI 테스트 자동화 코드 구조가 궁금하시면 UI 테스트 자동화 구조
올리브영 QA Engineer가 되어 자동화 프로세스를 직접 구축 및 개선해보고 싶다면 지원하러 가기
