테스트 자동화 빠르게 적용하기 (feat. Datadog)

Hardin Park·2024년 3월 18일
0
post-thumbnail

지금 이순간에도 여러가지 이유로 변경되는 서비스

스프린트 기간 중 진행된 프로젝트부터 리팩토링, 라이브러리 업데이트 등 기술적인 개선, 또 저희가 통제할 수 없는 네트워크 오류 상황까지 여러가지 요인이 있습니다. 이런 상황에서 우리는 정상적으로 동작하던 기능에서 갑작스런 문제가 발생하지 않는지 반복해서 테스트를 진행해야 합니다.

반복에는 역시 자동화 만한 게 없겠죠? 이 시점부터 저는 테스트 자동화 를 고민하기 시작했습니다.

첫번째 고민

위에 보이는 그림은 카카오 페이 QA 엔지니어가 작성해주신 발표 자료입니다. 자동화 QA 파트가 따로 구성되어 있어 타당성 조사부터 테스트 코드 구현, 테스트 실행, 모니터링 까지 자동화 테스트의 고도화가 가능한 형태입니다.

하지만 우리는 테스트 자동화에 리소스를 100% 할애할 수 없기 때문에 더 쉽고 빠르게 테스트 자동화를 구축할 수 있는 방법 을 고민해야 했습니다.

두번째 고민

두번째 고민은 code 를 써서 얼마나 빠르게 자동화 테스트를 만들 수 있을까 였습니다.
제가 저를 돌아봤을 때 시간이 많-이 필요해 보였거든요..
아마 개발자분들은 이런 고민을 하지 않으시겠죠?

세번째 고민

마지막으로 자동화를 생성하고 실행하는 것 외에 해야할 일은 뭘까요?
테스트가 버그를 잡아야죠! 그런데 그보다 중요한 것은 지속 가능성 이었습니다.

  • Maintenance : 잦은 서비스 변경에 빠르게 테스트를 업데이트 해야 하고,
  • Monitoring : 스크린샷/에러 로그 등 테스트 데이터를 보기 좋게 시각화 해야 합니다.
  • Process : 또 누구나 참여 가능하도록 프로세스를 수립해야 합니다.

도구를 써보자!

그래서 자동화 테스트 도구를 써보기로 했습니다. 왼쪽에 보이는 이미지에서 Codeless, Low Code, Coded 를 보실 수 있습니다. 제가 초점을 맞춘 부분은 Codeless, Low Code 입니다. 오른쪽에 보이는 것처럼 Codeless 는 쉽지만 Use Case 를 모두 만들기에는 한계가 있습니다. 그리고 Low Code 는 많은 Use Case 를 커버할 수 있지만 어느 정도의 코딩 스킬이 필요합니다.

여기서 저는 어떤 것을 선택했을까요?
선택에 앞서 저는 3가지를 생각해보았습니다.

  • 스프린트 업무와 병행할 수 있는지?
  • 지속 가능한 형태의 테스팅인지?
  • 단기간에 긍정적인 ROI 를 달성할 수 있을지?

이런 점에서 저의 선택은 Codeless 였습니다.

테스트 자동화 준비하기


PoC 를 통해 Codeless 테스트 자동화 도구를 둘러보았습니다.

  • Datadog Synthetic Tests
  • Katalon Studio
  • Katalon Recorder
  • Test Project
  • Selenium IDE

모두 장단점이 확실한 도구이지만 멀티 로케이터 설정으로 UI 변경에 따라 자동적으로 테스트가 업데이트 되고, 로컬 환경이 아닌 실제 사용자 트래픽을 모방하고, 기존부터 개발팀에서 모니터링 용도로 사용하는 도구로서 축적된 인사이트를 활용할 수 있고, 단계별 스크린샷과 에러 로그 확인이 가능한 점을 미루어 보았을 때 Datadog Synthetic Tests 를 선택했습니다.


도구를 선택했으니 본격적으로 준비 단계에 들어갑니다. Datadog 의 Real User Monitoring 기능을 활용하여 최근 세션이 가장 많은 페이지를 리스트업 했습니다.

다음으로 주요 시나리오를 기반으로 테스트맵을 작성했습니다. 일부 시나리오는 Manual 로 돌려야 했습니다. 슬프게도 모든 Use Case 를 커버하지 못하는 것은 Codeless 도구의 한계인 부분입니다.

테스트 자동화 생성하기


이제 테스트맵을 갖고 가능한 작은 단위의 테스트를 생성합니다. 이 부분은 Codeless 의 장점이죠? 아주 간단합니다. 가운데 Record 버튼을 눌러 순차적으로 테스트를 작성해 나갑니다.


DRY 원칙이 여기서도 적용됩니다. 반복되는 테스트는 여러개 만들 필요 없이 하나만 만들어 수정하면 되겠죠? 이렇게 하나의 테스트 안에 별도의 하위 테스트를 구성할 수 있습니다.

최근에 통합 로그인 디자인 개선 작업이 배포되었습니다. 이 작업으로 로그인, 회원가입, 탈퇴 테스트가 영향을 받게 되었습니다. 총 18개의 테스트 였고, 3개의 하위 테스트만 수정함으로써 모든 테스트를 쉽게 업데이트 할 수 있었습니다. 어떻게 보면 약 5배 정도 작업 시간을 단축했다고 볼 수 있을 것 같습니다.


같은 테스트를 반복해서 실행하려면 테스트 데이터를 초기화해주는 작업도 필요합니다. 예를 들면 테스트 스텝에 DELETE Request 를 구성하여 테스트를 실행하면서 생성되었던 테스트 데이터를 삭제합니다. 여러번의 Request 를 통해 Response 에서 원하는 데이터를 추출하고 이를 변수로 저장하여 다음 Request 에서 활용하는 방식입니다.


물론 API 만으로 구성된 테스트를 작성할 수도 있습니다.

테스트 자동화 실행하기


테스트 환경에서 자동화 테스트를 구성한다면 배포 전에 버그를 잡을 수 있겠죠? 하지만 Datadog 은 실제 사용자 트래픽을 모방하기 때문에 테스트 환경에 접근할 수 없는 이슈가 발생 했는데요. devOps 분들께 Datadog 에서 솔루션으로 제공하는 Docker Container 를 공유드렸고 빠르게 해결해주셨습니다. 이 부분도 자동화 테스트 도구를 사용하면 좋은 점이라고 생각합니다.


테스트가 완료되면 단계별 스크린샷과 브라우저 개발자도구에서 확인할 수 있는 console, network 에러 로그가 포함된 화면을 볼 수 있습니다. 그리고 시간대별 테스트 실행 시간과 Fail 이력 등을 차트로 확인할 수 있습니다.

스케줄링된 테스트에서 Fail 이 발생하면 특정 슬랙 채널에 메시지가 쌓이게 됩니다. Fail 발생 시 바로 채널에 공유하거나 지라로 리포팅하여 크고 작은 이슈를 follow up 하고 있습니다.

리뷰와 성과


작업기간은 자동화 테스트가 잘 돌아가는 지 확인하는 모니터링 기간을 포함하여 1.5개월 가량 소요되었습니다.

테스트는 생성 시점부터 147만 회 실행되었구요. 현재 실행 중인 테스트는 운영 환경에 17개, 테스트 환경에 20개가 있습니다.

테스트 성공률은 99.11%, 실패율은 0.89% 입니다.

테스트 커버리지는 위와 같은 구성으로 실제 유저 세션 가중치를 고려했을 때 26% 입니다. 참고로 저희 1개 스쿼드에서만 생성되고 사용되고 있는 수치입니다.

중요한 것은 비용이죠!
2023년 9월 기준으로 Datadog API, Browser Test 비용은 61달러로 실행 횟수만큼 책정되고 있습니다. 한편 Coded 헬스체크 자동화를 위해 EC2로 구성한 QA 서버 비용은 시간당 0.09달러로 30일 기준 67달러가 나왔습니다. 어떻게 보면 비슷한 금액이지만, QA 서버에서 E2E 테스트를 추가로 돌리려면 사양 업그레이드가 필요하여 추가 비용이 예상됩니다.

도구를 이용하면 이미 잘 구축되어 있는 자동화 테스트에 대한 아이디어를 얻을 수 있습니다. 그리고 테스트로 미처 구현하지 못한 부분은 Low Code, Coded 테스트 구성을 목표로 두어도 되겠다는 생각을 했습니다.

(이런 와중에도 Datadog 에서 꾸준히 새로운 기능을 만들고 있어서 Codeless 로 활용해볼 수 있는 부분이 계속 늘어나고 있습니다)

액션 아이템


첫번째 CI/CD 파이프라인에 통합하는 것 입니다.

  • CI : 개발 완료 후 Integrate 단계에서 테스트를 실행하여 조기에 버그를 예방할 수 있습니다.
  • CD : 배포 완료 후 중요한 테스트가 실패하는 경우 자동으로 롤백을 트리거 할 수 있습니다.


두번째 병렬로 테스트를 진행하는 것입니다. 여러개의 테스트를 동시에 시작하도록 설정한다면
CI/CD 파이프라인에 통합하는 부분에서도 테스트 실행에 대한 부담을 줄여볼 수 있을 것 같습니다. 이를 위해서는 테스트 경량화나 불필요한 테스트 정리 작업도 동반되어야 할 것 같습니다.

profile
안녕하세요, QA 엔지니어 Hardin 입니다.

0개의 댓글