by
Oct 01. 2022
E2E 테스트 자동화 워크플로우 구축 PoC 경험담
안녕하세요, 클래스팅에서 Test Automation Engineer로 커리어를 쌓고 있는 6년차 QA Engineer입니다. 그동안 과거 경험과 학습했던 지식과는 별개로 모든 것이 새롭게만 느껴지는 환경에서 새로운 경험과 학습을 해볼 수 있는 소중한 수습 미션을 부여받게 되었습니다. 그리고 최근 3개월간의 무지에서 출발한 여정이 끝났습니다.
'왜 안될까?' '왜 동작하지?'의 순간들을 포기하지 않은 덕분에 이제는 무엇을 모르는지 모르는 상태에서 무엇을 모르는지 아는 상태가 되었네요. 그간 느꼈던 감정들은 글을 써 내려가는 순간에 떠나보내고, 과정은 기록하고자, 3개월간 담당했던 E2E 테스트 자동화 워크플로우 구축 PoC 경험을 공유합니다.
입사 전 나의 백그라운드
좌절하지 마라. 최소한 성실하게 살았다면 시간과 경험을 허비한 것이 아니고 아직 기회와 시간은 많다. 지금이라도 요행과 같은 찰나의 기회를 추구하거나 다른 사람들을 따라가지 말고 자신에게 주어지는 특정한 분야에 앞으로 5~10년간 최선을 다하고 충실히 몰입하기를 바란다. 돈보다 마음이 가는 일을 선택해 그 분야에서 최고가 되려고 노력하라. 직장인이라면 정말 열심히 현재 맡은 일을 하라. 거기에서 당신만의 행운을 발견하게 될 것이고 기회의 문이 열릴 것이다. 성공의 비결은 '찰나의 순간'에 있는 것이 아니라 지나 한 '과정'속에서 자라난다.
권도균의 스타트업 경영 수업 중에서
약 10개월간 모바일 마라톤 서비스 창업을 준비해오다 지금은 때가 아니라는 판단에 우선 먹고사는 문제를 해결할 분야 및 앞으로 5년간 몰입할 분야를 새롭게 정하던 시기였습니다.
이전에 경험했던 국내의 General 한 QA Engineer의 R&R은 더 이상 마음이 끌리지 않았고, 마음이 끌리지 않는 일에는 의미 있는 성과가 나오기 힘들다는 것을, 수많은 시행착오와 좌절 끝에 배웠습니다.
SW 개발 부트캠프와 QA 분야에서의 커리어 패스 확장에 대한 선택지가 주어졌고 해외 글로벌(구글, 애플 등) 기업의 SDET 사례와 스킬 셋을 접하며 흥미롭게 다가왔습니다. 끝내 QA 분야에서의 커리어 패스 확장을 택했습니다.
입사 전 WebdriverIO라는 E2E 테스트 프레임워크를 접하게 되었습니다. 해당 프레임워크로 웹 서비스에 대한 E2E 테스트 코드를 작성하며 학습했고 해당 경험만을 가진채 클래스팅에 합류하게 되었습니다.
PoC(Proof of Concept) 목적
게임 개발사 재직 당시 실무에서 주어진 역할은 아니었지만 테스트 자동화에 대한 갈증이 심했고 개인 시간을 할애하여 관련 학습을 했습니다. BAT 테스트 커버리지 중 굉장히 반복적이고 귀찮은 테스트가 있었습니다. 해당 커버리지를 로컬 환경에서 자동화 진행한 경험이 있었습니다. 하지만 당시 경험을 떠올려보면 테스트 자동화의 관점에서 부족한 점들이 많았습니다.
과거 부족했고 아쉬웠던 경험을 떠올리며 클래스팅 E2E 테스트 자동화는 정말 잘 구축해야겠다는 생각이 들었습니다. 단순히 환경 구축 → 스크립트 작성 → 로컬에서 결과 확인 플로우로 생각하지 않았습니다. 유지보수 관점에서 사람이 해야 하는 작업을 최소화하고 전체 프로덕트에 대한 품질 매트릭의 가시성을 확보하고자 했습니다.
따라서 외부 서비스와의 연동을 통해 Test Automation Workflow를 구축하여 위 목적을 달성하기에 적합한 형태로 동작하는지를 확인하고자 했습니다.
최초 계획
목적지
테스트 프로세스에 필요한 설계, 수행, 마감 활동을 테스트 관리 툴에서 관리하고 테스트 관리 툴에서 자동화 케이스 설계 및 실행과 결과 분석 그리고 모니터링까지 가능한 환경을 구축한다.
1. 우리 서비스에 적합한 E2E 테스트 프레임워크를 비교 분석하여 구축한다.
2. E2E 테스트 프레임워크와 브라우저 스택을 연동해서 실행 주체를 로컬 인프라가 아닌, 클라우드 인프라의 리얼디바이스로 옮긴다.
3. 브라우저 스택과 qTest를 연동하여 qTest에서 테스트 케이스 생성 → 실행 → 결과 → 모니터링이 진행될 수 있도록 한다.
4. 결과적으로 유지보수 가능한 테스트 코드를 작성하여 qTest에서 모든 자동화 테스트 프로세스를 관리할 수 있는 환경을 통해, 테스트 수행 리소스를 점진적으로 절감한다.
핵심은 테스트 관리 서비스에서 테스트에 필요한 모든 것들을 관리하는 형태로 구축하고자 했습니다. 따라서 위와 같은 목적지를 설정했습니다.
E2E 프레임워크로 WebdriverIO 선택한 이유
Cypress Playwright, Puppeteer, Testcafe, WebdriverIO 프레임워크 후보군을 선정했습니다. 셋업 후 비교 분석을 통해 동일한 테스트 케이스에 대한 구현 가능성을 검토했습니다.
클래스팅 같은 경우 웹 서비스도 중요하지만 모바일 환경이 보다 중요했습니다. 클래스팅 기능 분석 결과, 인증번호를 구글 메일에 진입하여 받아오는 로직이 필요한 회원가입과, 게시글 작성에 필요한 첨부파일 구현이 가능하다면, 대부분 자동화에 적합한 시나리오는 구현 가능할 것이라 판단했습니다.
왜냐하면 E2E 테스트 레벨은 결국 사람이 수동으로 진행하는 터치(클릭), 스크롤, 스와이프, 검증이라는 행위를 테스트 로직으로 대체하는 방식이기 때문입니다. 그리고 이러한 기능들은 테스트 프레임워크에 내장되어 있습니다.
당연히 가능한 것에 대한 구현 가능성을 검증하기보단, '이건 가능할까?'의 시나리오를 선정하게 되었고, 이를 커버한다면 당연히 나머지도 커버될 거라 생각했습니다. 중점적으로 검토했던 사항들은 아래와 같습니다.
웹/모바일 지원 여부
웹과 모바일을 서로 다른 프레임워크로 구축해도 크게 문제 될 사항은 없지만, 학습 곡선 및 유지보수 관점에서 두 가지 모두 지원하는 프레임워크를 최우선으로 고려했습니다.
테스트 실행 속도
CICD 환경에서 테스트가 실행될 때의 속도가 중요했습니다. 수백 개의 테스트 시나리오가 클라우드 인프라에 띄워진 세션의 리얼디바이스에서 실행되어야 하기 때문에 불필요한 테스트 로직을 최대한 제거하여도 테스트 실행이 오래 걸릴 수밖에 없기 때문입니다. 따라서 해당 부분도 여러 사례를 조사해서 고려하게 되었습니다.
코드 작성의 용이성
스크립트 작성과 유지보수의 관점에서 어떠한 언어를 사용해야 하고, 프레임워크에서 지원하는 기능은 어떠한 것들이 있는지에 대한 고려도 필요했습니다.
커뮤니티 및 사용 중인 기업 사례
커뮤니티가 크고 사용 사례가 많다면 그만큼 자동화 실무 Deep Dive 간에 발생하는 이슈에 대해 기술적인 도움을 쉽고 빠르게 받을 수 있고, 여러 활용 사례를 참고 삼아 클래스팅 서비스에 적합한 형태로 구축해볼 수 있기에 해당 부분도 고려가 되었습니다.
다중 탭 및 Gmail 접근 지원
회원가입에 필요한 인증번호를 받아오려면 2개 이상의 탭과 상호 작용이 가능해야 했고, Gmail 서비스 접근에 제한이 없어야 했습니다.
첨부파일 업로드
게시글 작성 시나리오 구현을 위해 웹과 모바일 모두 파일(이미지, 영상 등) 업로드 기능을 지원해야 했습니다.
크로스 브라우저 테스트 지원
결과적으로 크롬뿐 아니라 사파리, 엣지, 파이어폭스와 같은 환경에서도 테스트 가능한지도 고려가 되어야 했습니다.
Headless 지원 여부
JavaScript 로드 및 렌더링 시간을 Skip 하므로 CI 파이프라인에서 유용한 GUI가 없는 웹브라우저인 Headless 모드의 지원 여부가 중요했지만, Headless 지원 여부 같은 경우 꼭 필요할지에 대해서 많은 고민이 있었습니다.
백엔드에서 실행되고 사용자 화면에는 아무것도 표시되지 않다 보니 실행 속도가 빠르다는 장점이 뚜렷하지만, 문제가 발생할 경우 디버깅이 어렵다는 점과, 마크업 및 스타일 문제를 발견하기 어려울 수 있기 때문입니다. 특히 실제 사용자는 Headless 브라우저를 사용하지 않기 때문에 Headless 환경에서 발생하는 이슈가 실제 브라우저에서 꼭 발생하지는 않으므로, 사용자 경험과 관련된 E2E 레벨에서의 테스트에 과연 적합할까라는 생각이 들었습니다.
하지만 CICD 파이프라인에서 테스트 자동화가 실행되고 추후 Parallel Test까지 고려한다면 많은 메모리와 리소스가 필요할 텐데, Headless를 통해 이러한 부담을 줄이는 것도 효과적일 것 같다는 생각이 들었습니다.
주요 이슈
브라우저 스택 테스트 실패 시, qTest Agent가 Workflow execution error: 반환 후 테스트 결과 파싱 로직을 실행하지 않아서, qTest Manager로 테스트 실패 결과가 전송되지 않는 현상
해당 워크 플로우처럼 동작해야 함에도 불구하고 테스트 실패 시 Agent가 Workflow execution error 에러 반환 후 Job을 종료시켜서 allure reporter 결과 파싱을 못하는 이슈가 발생했습니다.
qTest Agent 셋업 간에 설치된 디렉토리에 존재하는 excution-workflow.js를 살펴봤고 위 사진의 파싱 성공 시 수행하는 내부 코드를 확인한 결과,
error 발생 시 Workflow execution error 에러를 반환하는 코드를 발견했고 우선 문제를 해결하고자 finally 블록을 사용해서 예외(Workflow execution error)가 발생했는지에 관계없이 항상 파싱 로직이 실행되도록 수정하여 해당 문제는 해결되었습니다.
하지만 근본적인 해결책은 아닌 것으로 생각되고 추후 qTest를 정식으로 도입해서 활용한다면 그때 추가적인 조사가 필요한 이슈로 남게 되었습니다.
PoC 결과
3개월간 수많은 삽질 끝에 클래스팅 자동화에 필요한 웹 모바일 테스트 시나리오 구현과 E2E 프레임워크 ↔ BrowserStack ↔ qTest 파이프라인 구축이 완료되었습니다.
WebdriverIO와 Appium으로 웹 모바일 테스트 환경을 구축했고, BrowserStack과 연동하여 클라우드 인프라에서 리얼디바이스 실행 가능한 환경을 구축했습니다.
이후 qTest Agent를 로컬에 셋업 하여 qTest Manager에서 생성한 Automation Test Case와 테스트 코드 매핑을 통해 qTest에서 자동화 케이스 실행 시 BrowserStack에서 실행된 결과가 파싱 되어 qTest에 전달되도록 했습니다.
아쉬운 점
CICD가 어떤 형태로 진행되어야 할지 큰 그림이 그려지지 않았습니다.
테스트용 Repo WebdriverIO와 Git Action을 연동하여 구동했지만 실무에서 활용 가능한 수준으로 구축하지 못한 것에 대해서 많은 아쉬움이 남습니다.
또한 bitrise에서 빌드 업로드 자동화까지 구축했을 때의 전체적인 워크플로우를 확인하고 싶었지만, qTest에서 발생한 여러 이슈 해결에 많은 리소스를 사용하게 되어 마무리하지 못한 점이 아쉽게 다가왔습니다.
느낀 점
인프라 구축이 정말 쉬운 작업이 아니라는 걸 느끼게 되었습니다. 이번 경험을 토대로 SW 개발에는 다양한 분야가 있고, 한 사람이 모든 분야를 담당할 수 없겠다는 생각이 들었습니다.
한편으론 QA Engineer가 지녀야 할 스킬과 커리어 확장에 대한 가능성에 대해, QA Engineer 스스로 역량만 갖춘다면 더 많은 것들을 시도해보고 경험해볼 수 있겠다는 생각이 들었습니다.
따라서 과정은 정말 많이 힘들었지만 앞으로의 커리어 방향에 대해 조금이나마 큰 그림을 잡아볼 수 있는 소중한 시간이었습니다.
이후 계획
이번 경험을 통해 기본기가 정말 많이 부족하다고 느꼈습니다. 당분간은 SW 개발 분야에 필요한 기초 체력에 집중할 생각입니다. 최근 테크 리더 분과의 1:1을 통해서 커리어 방향에 대한 여러 조언을 받았습니다. 당분간은 타입 스크립트와 OOP에 대한 개인 학습을 진행하여 실무에서 당장 활용해야 하는 기술 스택과 개념들을 익히는 것에 집중할 계획입니다. 이후 고민은 능력이 생긴 다음에 해보면 좋지 않을까 생각됩니다.
마치며, 3개월 전과 현재의 테스트 코드
이번 블로깅을 써 내려가며 문득 3개월 전 작성한 테스트 코드를 살펴보게 되었습니다.
BDD에 대한 개념이 없었던지라 테스트 시나리오 간에 의존성이 존재했고 무엇을 테스트하는지 명확하지 않았습니다. 이로 인해 과거에 작성했던 테스트 코드는 디버깅이 어려울뿐더러, 코드 변경이 필요할 경우 전체적인 시나리오가 한눈에 파악되지 않게끔 작성되어 있어 많은 어려움이 있었습니다.
현재는 테스트 훅을 활용해서 테스트 시나리오 간에 의존성을 모두 제거했습니다. 또한 Page Object Model 패턴 활용 및 BDD 스타일로 자동화 스크립트를 구현함으로써 보다 유지보수 및 확장성 있는 구조로 E2E 테스트를 작성하고자 노력하는 중입니다.
아직 많이 부족하고 앞으로도 많이 부족할 것 같습니다. 시간과 경험이 필요한 영역이 있다는 것을 배웠습니다. 하지만 이제는 정말 무엇을 모르는지 아는 상태가 되었기에 현재 부족한 부분들은 꾸준함과 시간이 해결해줄 거라 믿습니다.
올해 연말 회고 간에 지금 이 글을 써 내려가는 제 모습과 역량이 어떻게 변했을지 기대가 되고 스스로에게 확신이 생기네요. 오늘처럼만 내일도 살아보자고 스스로를 다독이며, 3개월간 담당했던 E2E 테스트 자동화 워크플로우 구축 PoC 경험 공유를 마칩니다. :)
