1. UI 테스트 자동화 CI/CD 파이프라인 구축 가이드

Q 트랙의 첫 번째 발표를 맡아주신 권보람 님의 발표 내용을 정리해 보겠습니다 :)
전체적으로 UI 테스트 자동화를 구성하는 과정 중 고려사항과 어떤 방식으로 구축하셨는지를 설명해 주시는 발표였습니다.

자동화 도입을 고려중이시라면 해당 발표 내용을 참고해서 자동화 도입에 검토해 보시는 것도 좋을 것 같습니다

개인 블로그이기 때문에 주관적인 의견이 담겨있을 수 있습니다. 해당 포스팅은 컨퍼런스 참고용으로만 사용해 주세요
QA 컨퍼런스에 참여하시면 더 많은 자료를 보실 수 있으니, 다음 회차에서 직접 참여하시고 많은 정보를 받아가시는 것을 추천드립니다!

2025 QA 컨퍼런스 링크 : https://www.qa-korea.com/qaconference2025
컨퍼런스 전체 리뷰 : 2025 4th QA 코리아 '오프라인' 컨퍼런스 후기

 

 

Q 트랙에 첫 발표는 권보람 님이 발표해 주셨고, UI 테스트 자동화를 직접 구축하신 내용을 기반으로 자동화를 구축할 때 어떤 부분을 고려해야 하는지, 어떤 방식으로 도입을 하셨는지, 파이프라인을 통한 관리 방법까지 전반적인 영역에서 신경 써야 할 부분들을 설명해 주셨습니다.

UI 테스트 자동화 방식을 스크립트 작성과 환경 구축으로 나눠서 설명해 주셨고, 매뉴얼 QA 역할과 비교하자면, 테스트 스크립트 작성은 매뉴얼 TC를 작성하는 것과 유사했고, 환경 구축은 테스트 플랜을 구축하고 TC를 선정하여 수행하는 방식을 자동화한다는 느낌을 받았습니다.

 

즉, TC를 작성하는 부분과 TC를 수행할 수 있게 만들어주는 환경 구축으로 분리하였고, 두 부분이 구성되면 간단한 동작으로 자동화를 수행할 수 있는 환경이 구축된다는 것을 설명해 주셨습니다.

 

SDLC(Software Development Life Cycle) 과정 중 각 단계에서 UI 자동화 담당자의 역할에 대해 설명해 주셨고, 체계적인 과정을 통해서 분석 -> 설계 -> 구현 -> 실행 -> 모니터링 방식이 진행된다는 것을 알려주셨습니다.

 

매뉴얼 QA로 전반적인 프로세스에 참여하는 방식과 유사하고, 이 프로세스가 잘 유지되려면, 화면 개발이 되었을 때 빠른 TC 작성 능력과 개발건으로 인한 사이드 이펙트 수정 등 개발적인 역량이 끌어줘야 프로세스 틀이 깨지지 않을 수 있겠구나 생각되었습니다.

 

저도 비슷한 방식으로 자동화 케이스를 추가하고 있지만, 개발된 내용을 바로 TC화 하는 것은 개발 규모에 따라 어려워질 수 있었거든요.. 🥲

 

 

그래서인지, 바로 테스트 유지보수에 대한 내용도 설명해 주셨습니다. 자동화 동작에 실패했을 때 원인을 분석하고 대응하는 프로세스를 간단하게 설명해주셨으며, 모니터링 단계가 아니더라도, 자동화 개발 중 테스트 실패가 발생했을 때 케이스 수정 프로세스를 그림을 통해 설명해주셨습니다.

 

저도 비슷한 방식으로 유지보수를 하고 있고, 파이프라인과 Slack 연동을 통해서 테스트를 수행하고, 실패하면 Slack 알림이 발생하고 원인을 자동화 영상이나 리포트를 통해 확인 후 수정하는 방식으로 진행하고 있습니다.

개인적으로 자동화 실패가 발생하면 원인을 가장 빠르게 확인할 수 있는 건 관련 로그도 좋지만 자동화 동작 영상을 보는 것이 가장 빠르게 처리했던 것 같습니다. 그래서 저는 테스트 실패가 발생하면 영상 디버깅을 통해 빠르게 처리하는 방식으로 진행했습니다.

 

 

테스트 환경 구축에 관해서는 로컬서버, 자체 서버, 클라우드 기반으로 구분하여 설명해 주셨습니다.

저는 웹 도메인만 경험해 봤기에 잘 몰랐던, 모바일 디바이스 테스트를 수행할 수 있는 디바이스 팜(AWS Device Farm 등)도 연결해서 환경을 구축하기도 하고, CI/CD나 테스트 산출물 관리에 쓰이는 도구들도 설명해 주셨습니다.

 

그리고, 테스트 서버 구축(Nginx, Test Tool 설치)과 CI/CD 설정, 테스트를 어떤 방식으로 수행할지를 작성하는 파이프라인 구성에 대해 설명해 주시고, 실행 과정에 대한 안내도 해주셨습니다.

 

모바일 부분을 제외하고, 저랑 거의 비슷한 방식으로 구성하셔서 프로세스를 보고 바로 이해할 수 있었습니다.

제가 발표를 해본다면 이런 식으로 해보지 않았을까..?라고 생각되는 자료였어요

 

다 아시는 분들에게는 익숙한 내용이라 흘려들을 수 있었겠지만, 모르시는 분들도 있다는 생각으로 최대한 쉽게 설명해 주시려고 노력하는 모습이 인상 깊었습니다.

 

파이프라인 설명을 해주신 뒤, 자동화 도입을 고려하시는 분들에게 체크리스트처럼 고려해야 할 항목을 구분하여 설명해 주셨습니다.

 

이 부분도 제가 자동화를 처음 도입할 때 생각했던 부분과 유사해서 금방 눈에 들어왔습니다

 

저도 자동화를 구축할 시간이 없어서 빠르게 완성되는 자동화 도구(Katalon)를 사용해서 구축하려 했으나, 자유도와 비용의 문제 때문에 Playwright 라이브러리를 활용해서 구축했던 것처럼 다양한 제약사항을 고려하여 사내에 맞는 자동화를 구축하는 것을 선호한다는 의견이셨어요.

 

예산과 인력, 엔지니어의 역량, 사내 환경 등 조건에 따라 맞는 환경으로 구축해야 한다는 것을 보고, 저도 이전에 정리했던 자동화 구축 포스팅의 2부로 고려사항에 대한 내용을 써봐야 할까...? 고민도 하게 되었습니다 🫢

 

 

마지막으로 전체 내용 정리를 통해 발표의 전반적인 내용을 정리해 주시고, 체계적으로 관리된 자동화 시스템은 QA 공수가 줄어드는 역할을 수행하기에 ROI(투자수익률)가 높을 수 있고, 원활한 운영을 하기 위해 소통은 필수이며 QA도 개발 지식을 알고 있다면 더 많은 영역에서 영향을 끼칠 수 있다는 것을 공유해 주셨습니다.

---

 

전반적으로 자동화를 도입하는 과정 중에 고민하셨던 내용들을 최대한 쉽게 풀어서 설명하려고 해 주시는 모습이 인상 깊었습니다.

자동화 시스템의 스크립트 개발 방법이나 구축 방법보다는 자동화 프로세스를 도입하려고 고민 중인 분들에게 도움이 될 수 있는 발표였고, 프로세스를 공부해 보려는 주니어분들에게는 자동화를 도입하려면 어떤 부분을 고민해야 하는지 틀을 잡아주는 역할로 도움이 될 것 같은 발표였습니다.

 

매뉴얼 QA 역할에서도 Shift-left 방식을 도입하는 것이 좋은 방식인 것처럼 자동화 구축에서도 사전에 참여해서 함께 개발하는 것을 권장하는 느낌도 받았습니다.

 

작성한 내용 외에도 현장에서는 더 많은 내용이 발표에 담겨있었고, 참여를 못하신 분들은 다음 컨퍼런스에 직접 참여하셔서 발표를 들어보시는 것을 권장드립니다 😁