![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2Ftemp%2F36370c09db6ef5f034776866334527f84fa1e3e4cd26f78f9d74944d38b580a8&w=inherit&q=80)
안녕하세요 원티드랩 김명관입니다.
며칠 전 원티드랩 홈페이지를 대상으로 하는 E2E 자동화 테스트 코드가 QA 서버에 첫 머지되었습니다. 기존에 자동화 테스트 코드가 없었던 것은 아닙니다. 기존에는 다소 산발적으로 팀원 개개인이 필요한 경우 Selenium이나 Playwright를 이용하여 자동화 테스트 코드를 작성하고 활용하고 있었습니다. 저도 마찬가지로 E

김명관님, 원티드랩 QA팀의 E2E 자동화 테스트 코드 진행 과정과 목표를 공유해주셔서 감사합니다. 팀워크와 피드백을 통해 자동화 테스트를 더욱 고도화하고, 전문성을 키워나가는 과정이 인상 깊네요! 앞으로도 많은 성과 있으시길 바랍니다. 😊🚀

원티드 회원들의 커리어 성장과 행복을 돕는 AI입니다.

원티드 에이전트

안녕하세요 원티드랩 김명관입니다.
며칠 전 원티드랩 홈페이지를 대상으로 하는 E2E 자동화 테스트 코드가 QA 서버에 첫 머지되었습니다. 기존에 자동화 테스트 코드가 없었던 것은 아닙니다. 기존에는 다소 산발적으로 팀원 개개인이 필요한 경우 Selenium이나 Playwright를 이용하여 자동화 테스트 코드를 작성하고 활용하고 있었습니다. 저도 마찬가지로 E2E 자동화 테스트 코드나 업무 자동화 코드 등을 만들어 QA 서버에 올려 활용하고 있었죠.
2024년 원티드랩 QA팀의 목표 중 하나는 조직 차원에서의 QA 프로세스 고도화 입니다. 여러가지 수단을 이용해 QA 프로세스를 고도화 하여 더 높은 수준의 품질을 향해 가려고 하는데요. 자동화 테스트도 그 수단 중에 하나였습니다. 먼저 산발적으로 진행되고 있던 API, E2E 자동화 테스트를 팀 차원에서 조금은 더 체계적으로 진행하기로 했습니다. 그 중에 저는 E2E 자동화 테스트를 주도적으로 맡게 되었죠.
인프라부터 코드 구조, 설계 등 각자 진행하던 전과 달리 많은 부분에서 높은 기준과 체계를 가지고 자동화 테스트 환경을 구축하게 되었습니다. 설계부터 Github 첫 머지까지 과정을 간단히 작성해 보겠습니다.

같이 하는 자동화

위에서 언급한대로 기존에 E2E 자동화 테스트는 필요한 사람이 각자 진행했습니다. 그러다보니 E2E 자동화 테스트를 위한 인프라, 설계, 구조, 정책 등 공통된 기준이 없이 작성되고 실행되었습니다. 이것을 팀 차원에서 고도화하여 진행하기 위해서는 팀원 중 저를 도와주실 분들과 함께 진행하는 것이 중요하다고 생각했습니다.
다행히 원티드랩 QA팀에는 저를 도와주실 수 있는 우수한 팀원 분들이 많이 계십니다. 그 중 개발자 출신 동료분께서 자동화 테스트를 위한 인프라 세팅과 코드 리뷰를 도와주시기로 했고, Selenium과 Playwright를 활용해본 경험이 있는 동료분께서 저와 함께 테스트 코드를 작성해 나가기로 했습니다.
이렇게 같이 진행하며 좋다고 느낀 점은 저 혼자 자동화 테스트를 할 때보다 많은 기준과 원칙을 세워야 했고 이에 따라 제 편의를 위해 대충 만들어가던 부분들을 견고히 할 수 있었던 것 같습니다. 게다가 혼자 하면서는 미처 볼 수 없었던 많은 실수나 잘못된 습관들도 고쳐나가고 있습니다.
그리고 함께 코드를 작성하는 동료분을 위해 코드 구조, Github, AWS 인프라 환경, Linux 등에 대해 코칭도 함께 진행하고 있습니다. 누군가에게 뭔가를 가르쳐 드릴 때는 저부터 명확하게 이해하고 있어야 하기 때문에 개인적인 공부도 많이 하게 되었습니다.
이번 기회에 EC2에 Linux서버를 세워 Github, Jenkins와 연동을 해보게 되었습니다. Github에 코드가 머지되면 Github Action을 통해 Linux 서버에 배포되고 Jenkins를 통해 실행하는 구조를 실습해 보았고 이 경험을 동료분께도 가이드 해 드리는 것이 목표입니다.

코드 구조 설계

자동화 코드의 설계는 POM(Page Object Model)을 기반으로 정했습니다. 그 외에도 여러가지 디자인 패턴이 있겠지만 함께 협업하며 진행하는 자동화 테스트는 처음이라는 점, 기존 E2E 자동화 코드의 가장 큰 문제가 유지보수 였다는 점에서 그렇게 정했습니다.
POM 구조를 갖춰 테스트 코드를 작성하였고 첫 PR을 올리게 되었습니다. 이후 오랜 시간동안 코드 리뷰를 주고받으며 코드 자체의 효율 개선, 재사용성 향상, 중복 코드 등 불필요한 코드의 제거, 불필요한 파일의 제거와 같은 개선 작업이 이루어졌습니다. 코드 리뷰를 받고 직접적인 피드백을 들으며 가장 좋았던 점은 '내가 그동안 정말 편한대로 코드를 작성해왔구나...' 라는 것을 느낀데 있습니다. 편하다는 이유로 중요한 정보를 하드코딩하는 습관이나 불필요한 코드와 파일을 제대로 정리하지 않던 잘못된 습관을 많이 고칠 수 있는 계기가 되었습니다. 앞으로도 개발자 출신 동료분과 오랫동안 함께 일하면서 제 나쁜 습관들을 많이 고치고 실력을 많이 향상 시킬 수 있었으면 좋겠습니다.
최종적으로 아래와 같은 구조를 가지게 되었습니다.
pages 디렉토리 하위에는 각 페이지의 디렉토리가 있습니다. 해당 디렉토리 하위에 실제 해당 페이지들의 정보를 담는 파일들이 존재합니다. 파일 안에서 해당 페이지의 요소들을 식별하고 테스트에 필요한 동작을 함수로 정의했습니다.
utils 디렉토리 하위에는 유저 액션을 정의한 util 파일이 존재합니다. 마우스, 키보드 입력과 요소 탐색, 대기 등의 Selenium의 Webdriver 객체의 동작이 있죠. 해당 파일에서 유저 액션을 미리 정의해두어 pages에 존재하는 파일들에서 필요한 유저 액션을 참조합니다.
tests 디렉토리 하위에는 실제로 테스트를 수행하는 코드와 assertion등을 담고 있습니다. 그 외에 pytest 초기 세팅을 위한 pytest.ini와 confest.py, 주요 정보를 담고 있는 .env파일, python의 모듈과 버전을 관리하기 위한 requirements.txt 파일을 세팅했습니다.

앞으로 할 일

기본적인 구조를 갖춘 코드가 첫 머지되었고 이제 목표로 하고있던 많은 작업들을 위해 나아갈 예정입니다. 제가 전에 만들어 둔 '웹 페이지의 현재 상태를 스크린샷으로 점검' 하는 히든캐치 스크립트를 붙여 UI에 대한 점검도 보완하려고 합니다. 서버와 주고받는 세션을 체크하여 기능 상 문제가 없더라도 서버나 네트워크 상에서 문제가 발생하지는 않았는지 또한 점검하면 좋을 것 같다는 생각을 하고 있습니다.
그 외에도 테스트 시작과 종료 시 알림을 보내거나 리포트를 생성하는 모듈도 붙여야 할 것 입니다. 이렇게 만들어둔 자동화 테스트 코드를 제품 배포시 적극적으로 활용하고 개선해 나가며 안정화를 꾀하려고 합니다. 코드 자체도, E2E 자동화를 진행하는 저희도, 프로세스도 안정된다면 Github Action을 활용해 제품 배포 시 자동으로 테스트를 수행하여 그 결과에 따라 배포를 결정하는 프로세스까지 생각하고 있습니다. 배포 시간을 너무 늘이지 않기 위해 pytest의 marker 기능을 이용하여 새니티, 리그레션, 스모크 테스트 등의 카테고리 또한 나눠야 할 것 같네요!
얼마나 걸릴지 알 수 없지만 목표한 바를 이루기 위해 계속 시도해보려고 합니다.

행복 그자체

첫 회사에서 자동화 테스트 업무를 부여 받았을 때는 팀에 자동화 프로세스가 거의 처음 도입되던 시기였습니다. 과연 우리 제품에도 자동화가 가능한가? 얼만큼의 효용성을 보일 것인가? 자동화 테스트를 계속 활용할 수 있을 것인가? 등의 가능성을 보려는 목적도 있었죠.
이런 상황에서 제 스스로에게 안타까웠던 점은 모든 것을 혼자 해나가야 했다는 점입니다. 자동화 테스트를 위한 언어, 인프라, 스킬, 구조 등 모든 것을 경험이 없는 제가 혼자 독학해야 했습니다. 이런 상황에서 저에게 좋지 못한 습관들이 많이 생겼던 것을 알고 있었습니다. 하지만 여태까지는 제가 만든 코드에 대해 직접적으로 피드백을 받고, 잘못된 부분을 지적 받았던 적이 별로 없어 제 스스로 발전할 수 있는 기회가 많이 없었습니다. 가끔 개발자분들께 제 코드를 보여드리며 어떤 부분들을 고쳐야 할지 물어보는 정도였죠. 하지만 그 또한 그분들의 본 업무가 있기에 눈치를 보며 가끔 부탁드리는 수준이었습니다.
그러나 이번 기회를 통해 제 잘못된 습관과 부족한 점들에 대해서 많이 알게 된 것 같습니다. 주옥같은 피드백들 하나하나를 Obsidian에 기록하고 지침으로 삼으려 합니다. 자동화 코드를 작성하기 시작하면서부터 바래왔던 제 코드에 대한 개선을 이번에 할 수 있어서 굉장히 행복했습니다. 👍
감사합니다.

현재 원티드랩에서 QA팀을 이끌어 주실 팀장님을 모시고 있습니다. 많은 관심 부탁 드립니다.
http://wntd.co/923b3fdf

![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2Ftemp%2F36370c09db6ef5f034776866334527f84fa1e3e4cd26f78f9d74944d38b580a8&w=inherit&q=80)
안녕하세요 원티드랩 김명관입니다.
며칠 전 원티드랩 홈페이지를 대상으로 하는 E2E 자동화 테스트 코드가 QA 서버에 첫 머지되었습니다. 기존에 자동화 테스트 코드가 없었던 것은 아닙니다. 기존에는 다소 산발적으로 팀원 개개인이 필요한 경우 Selenium이나 Playwright를 이용하여 자동화 테스트 코드를 작성하고 활용하고 있었습니다. 저도 마찬가지로 E2E 자동화 테스트 코드나 업무 자동화 코드 등을 만들어 QA 서버에 올려 활용하고 있었죠.
2024년 원티드랩 QA팀의 목표 중 하나는 조직 차원에서의 QA 프로세스 고도화 입니다. 여러가지 수단을 이용해 QA 프로세스를 고도화 하여 더 높은 수준의 품질을 향해 가려고 하는데요. 자동화 테스트도 그 수단 중에 하나였습니다. 먼저 산발적으로 진행되고 있던 API, E2E 자동화 테스트를 팀 차원에서 조금은 더 체계적으로 진행하기로 했습니다. 그 중에 저는 E2E 자동화 테스트를 주도적으로 맡게 되었죠.
인프라부터 코드 구조, 설계 등 각자 진행하던 전과 달리 많은 부분에서 높은 기준과 체계를 가지고 자동화 테스트 환경을 구축하게 되었습니다. 설계부터 Github 첫 머지까지 과정을 간단히 작성해 보겠습니다.
## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fimage.wanted.co.kr%2Foptimize%3Fsrc%3Dhttps%253A%252F%252Fstatic.wanted.co.kr%252Fcommunity%252Ftemp%252F253ae6f5a3a1914744f4e8ada0d96fde974f8f56d4be38a6447a3d087abab2d5%26w%3Dinherit%26q%3D80&w=inherit&q=80)**같이 하는 자동화**

위에서 언급한대로 기존에 E2E 자동화 테스트는 필요한 사람이 각자 진행했습니다. 그러다보니 E2E 자동화 테스트를 위한 인프라, 설계, 구조, 정책 등 공통된 기준이 없이 작성되고 실행되었습니다. 이것을 팀 차원에서 고도화하여 진행하기 위해서는 팀원 중 저를 도와주실 분들과 함께 진행하는 것이 중요하다고 생각했습니다.
다행히 원티드랩 QA팀에는 저를 도와주실 수 있는 우수한 팀원 분들이 많이 계십니다. 그 중 개발자 출신 동료분께서 자동화 테스트를 위한 인프라 세팅과 코드 리뷰를 도와주시기로 했고, Selenium과 Playwright를 활용해본 경험이 있는 동료분께서 저와 함께 테스트 코드를 작성해 나가기로 했습니다.
이렇게 같이 진행하며 좋다고 느낀 점은 저 혼자 자동화 테스트를 할 때보다 많은 기준과 원칙을 세워야 했고 이에 따라 제 편의를 위해 대충 만들어가던 부분들을 견고히 할 수 있었던 것 같습니다. 게다가 혼자 하면서는 미처 볼 수 없었던 많은 실수나 잘못된 습관들도 고쳐나가고 있습니다.
그리고 함께 코드를 작성하는 동료분을 위해 코드 구조, Github, AWS 인프라 환경, Linux 등에 대해 코칭도 함께 진행하고 있습니다. 누군가에게 뭔가를 가르쳐 드릴 때는 저부터 명확하게 이해하고 있어야 하기 때문에 개인적인 공부도 많이 하게 되었습니다.
이번 기회에 EC2에 Linux서버를 세워 Github, Jenkins와 연동을 해보게 되었습니다. Github에 코드가 머지되면 Github Action을 통해 Linux 서버에 배포되고 Jenkins를 통해 실행하는 구조를 실습해 보았고 이 경험을 동료분께도 가이드 해 드리는 것이 목표입니다.
## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fimage.wanted.co.kr%2Foptimize%3Fsrc%3Dhttps%253A%252F%252Fstatic.wanted.co.kr%252Fcommunity%252Ftemp%252F4982c4c90912e701369077f9a1aa141d60e693407382599c86812f716da047e7%26w%3Dinherit%26q%3D80&w=inherit&q=80)**코드 구조 설계**

자동화 코드의 설계는 POM(Page Object Model)을 기반으로 정했습니다. 그 외에도 여러가지 디자인 패턴이 있겠지만 함께 협업하며 진행하는 자동화 테스트는 처음이라는 점, 기존 E2E 자동화 코드의 가장 큰 문제가 유지보수 였다는 점에서 그렇게 정했습니다.
POM 구조를 갖춰 테스트 코드를 작성하였고 첫 PR을 올리게 되었습니다. 이후 오랜 시간동안 코드 리뷰를 주고받으며 코드 자체의 효율 개선, 재사용성 향상, 중복 코드 등 불필요한 코드의 제거, 불필요한 파일의 제거와 같은 개선 작업이 이루어졌습니다. 코드 리뷰를 받고 직접적인 피드백을 들으며 가장 좋았던 점은 '내가 그동안 정말 편한대로 코드를 작성해왔구나...' 라는 것을 느낀데 있습니다. 편하다는 이유로 중요한 정보를 하드코딩하는 습관이나 불필요한 코드와 파일을 제대로 정리하지 않던 잘못된 습관을 많이 고칠 수 있는 계기가 되었습니다. 앞으로도 개발자 출신 동료분과 오랫동안 함께 일하면서 제 나쁜 습관들을 많이 고치고 실력을 많이 향상 시킬 수 있었으면 좋겠습니다.
최종적으로 아래와 같은 구조를 가지게 되었습니다.
![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fimage.wanted.co.kr%2Foptimize%3Fsrc%3Dhttps%253A%252F%252Fstatic.wanted.co.kr%252Fcommunity%252Ftemp%252Fb1dd4352011eccd83d176eec79872dba22da57b30bed0a3a8525f941c84dc55f%26w%3Dinherit%26q%3D80&w=inherit&q=80)pages 디렉토리 하위에는 각 페이지의 디렉토리가 있습니다. 해당 디렉토리 하위에 실제 해당 페이지들의 정보를 담는 파일들이 존재합니다. 파일 안에서 해당 페이지의 요소들을 식별하고 테스트에 필요한 동작을 함수로 정의했습니다.
utils 디렉토리 하위에는 유저 액션을 정의한 util 파일이 존재합니다. 마우스, 키보드 입력과 요소 탐색, 대기 등의 Selenium의 Webdriver 객체의 동작이 있죠. 해당 파일에서 유저 액션을 미리 정의해두어 pages에 존재하는 파일들에서 필요한 유저 액션을 참조합니다.
tests 디렉토리 하위에는 실제로 테스트를 수행하는 코드와 assertion등을 담고 있습니다. 그 외에 pytest 초기 세팅을 위한 pytest.ini와 confest.py, 주요 정보를 담고 있는 .env파일, python의 모듈과 버전을 관리하기 위한 requirements.txt 파일을 세팅했습니다.
## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fimage.wanted.co.kr%2Foptimize%3Fsrc%3Dhttps%253A%252F%252Fstatic.wanted.co.kr%252Fcommunity%252Ftemp%252F2e2568d74ef64ea05bfb237458c437d96feabaced009b8dbd7c98db1bc5b9222%26w%3Dinherit%26q%3D80&w=inherit&q=80)**앞으로 할 일**

기본적인 구조를 갖춘 코드가 첫 머지되었고 이제 목표로 하고있던 많은 작업들을 위해 나아갈 예정입니다. 제가 전에 만들어 둔 '웹 페이지의 현재 상태를 스크린샷으로 점검' 하는 히든캐치 스크립트를 붙여 UI에 대한 점검도 보완하려고 합니다. 서버와 주고받는 세션을 체크하여 기능 상 문제가 없더라도 서버나 네트워크 상에서 문제가 발생하지는 않았는지 또한 점검하면 좋을 것 같다는 생각을 하고 있습니다.
그 외에도 테스트 시작과 종료 시 알림을 보내거나 리포트를 생성하는 모듈도 붙여야 할 것 입니다. 이렇게 만들어둔 자동화 테스트 코드를 제품 배포시 적극적으로 활용하고 개선해 나가며 안정화를 꾀하려고 합니다. 코드 자체도, E2E 자동화를 진행하는 저희도, 프로세스도 안정된다면 Github Action을 활용해 제품 배포 시 자동으로 테스트를 수행하여 그 결과에 따라 배포를 결정하는 프로세스까지 생각하고 있습니다. 배포 시간을 너무 늘이지 않기 위해 pytest의 marker 기능을 이용하여 새니티, 리그레션, 스모크 테스트 등의 카테고리 또한 나눠야 할 것 같네요!
얼마나 걸릴지 알 수 없지만 목표한 바를 이루기 위해 계속 시도해보려고 합니다.
## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fimage.wanted.co.kr%2Foptimize%3Fsrc%3Dhttps%253A%252F%252Fstatic.wanted.co.kr%252Fcommunity%252Ftemp%252F721ef9986e494f460f1ec1e290451003b5e25a06497054d8b389b6dd3fb55e3a%26w%3Dinherit%26q%3D80&w=inherit&q=80)**행복 그자체**

첫 회사에서 자동화 테스트 업무를 부여 받았을 때는 팀에 자동화 프로세스가 거의 처음 도입되던 시기였습니다. 과연 우리 제품에도 자동화가 가능한가? 얼만큼의 효용성을 보일 것인가? 자동화 테스트를 계속 활용할 수 있을 것인가? 등의 가능성을 보려는 목적도 있었죠.
이런 상황에서 제 스스로에게 안타까웠던 점은 모든 것을 혼자 해나가야 했다는 점입니다. 자동화 테스트를 위한 언어, 인프라, 스킬, 구조 등 모든 것을 경험이 없는 제가 혼자 독학해야 했습니다. 이런 상황에서 저에게 좋지 못한 습관들이 많이 생겼던 것을 알고 있었습니다. 하지만 여태까지는 제가 만든 코드에 대해 직접적으로 피드백을 받고, 잘못된 부분을 지적 받았던 적이 별로 없어 제 스스로 발전할 수 있는 기회가 많이 없었습니다. 가끔 개발자분들께 제 코드를 보여드리며 어떤 부분들을 고쳐야 할지 물어보는 정도였죠. 하지만 그 또한 그분들의 본 업무가 있기에 눈치를 보며 가끔 부탁드리는 수준이었습니다.
그러나 이번 기회를 통해 제 잘못된 습관과 부족한 점들에 대해서 많이 알게 된 것 같습니다. 주옥같은 피드백들 하나하나를 Obsidian에 기록하고 지침으로 삼으려 합니다. 자동화 코드를 작성하기 시작하면서부터 바래왔던 제 코드에 대한 개선을 이번에 할 수 있어서 굉장히 행복했습니다. 👍
감사합니다.

현재 원티드랩에서 QA팀을 이끌어 주실 팀장님을 모시고 있습니다. 많은 관심 부탁 드립니다.
[http://wntd.co/923b3fdf](http://wntd.co/923b3fdf)

Selenium을 이용한 원티드 자동화 테스트 구축하기

원티드 기술 블로그

원티드 기술 블로그