안녕하세요. 여기어때컴퍼니 QA1팀 루시안입니다. 앞서 같은 팀 요셉이 QA팀에 도입하게 된 Robot Framework를 통한 테스트 자동화에 대해 소개했었습니다.(Robot Framework와 QA팀 동행기: 시작과 도전(1))이번엔 Robot Framework를 통해 여기닷컴(http://www.yeogi.com)에 적용한 웹 테스트 자동화에 대해 소개하겠습니다.웹 테스트 자동화의 장점 파악웹 테스트 자동화를 시작하면서 먼저 진행한 것은 장점 파악이었습니다. 웹 테스트 자동화에 대한 장점을 먼저 파악 후, 이 부분들을 최대한 살리면서 자동화를 진행 해보려고 했습니다. 저희는 아래의 장점들로 여기닷컴에 먼저 웹 테스트 자동화를 적용했습니다.첫째, 다양한 플랫폼에서 테스트가 가능합니다.웹은 크로스 플랫폼을 지원하기에 윈도우, 맥, 리눅스 등 다양한 운영체제에서 동일한 브라우저 기반 테스트가 가능합니다. 그로인해 웹에서는 동일한 테스트 스크립트를 여러 플랫폼에서 쉽게 실행할 수 있습니다. 또한, PC, 태블릿, 스마트폰에서 동일한 인터페이스로 접근할 수 있어, 다양한 기기와 해상도를 고려한 테스트 자동화를 실행할 수 있습니다.이번에 웹 테스트 자동화를 진행하는 인원들이 윈도우, 맥과 같은 다른 운영체제에서 각각 스크립트를 작성하였지만 모두 동일한 브라우저 기반 테스트가 가능한 점도 이 부분 때문이었습니다. 그리고 현재 여기닷컴은 반응형 웹으로써 태블릿과 스마트폰 해상도를 지원하고 있습니다. 해상도 변경을 통해 다양한 해상도에서 자동화 테스트가 가능합니다.둘째, 브라우저 호환성 테스트에 활용할 수 있습니다.웹 테스트 자동화는 하나의 스크립트로 여러 브라우저(크롬, 파이어폭스, 사파리 등)에서 호환성 테스트를 쉽게 수행할 수 있습니다. 브라우저 호환성 테스트가 쉽다는 건 동일 시간내 이전보다 테스트를 더 많이 수행 할 수 있고, 더 많은 브라우저, 더 많은 버전에 대한 테스트가 가능해져 원하는 만큼의 브라우저별/버전별 호환성 확인이 가능하다는 걸 의미합니다.현재 구축 해놓은 웹 테스트 자동화 스크립트는 위의 장점을 활용해 하나의 스크립트로 크롬, 파이어폭스, 사파리 브라우저 환경만 변경 해서 테스트 할 수 있도록 구성해 두었습니다.셋째, 브라우저의 개발자 도구를 활용할 수 있습니다.웹 테스트 자동화는 브라우저 개발자 도구를 통해 네트워크 요청, 콘솔 로그, 성능 측정 등의 추가적인 디버깅 정보를 쉽게 얻을 수 있고 스크립트 작성을 위한 Locator의 정보도 얻어낼 수 있습니다. 그리하여 테스트 스크립트를 작성하면서 각 Element에 대한 Locator 값을 얻어낼 수 있었습니다. 이 Locator값을 유니크한 값으로 축약시킨 후, 브라우저 개발자 도구에서 DOM 검색을 통해 축약한 Locator값이 맞는지 확인 또한 가능했습니다. 축약한 Locator값을 적용함으로써 테스트 코드에 대한 가독성을 증가시킬 수 있었고 유지보수가 쉬워졌습니다. 그리고 팀 협업 시 표준화 효과 또한 얻을 수 있었습니다.넷째, 리소스 소비를 줄인 경량화 테스트가

LINE Plus의 MPR(Mobile Productive & Research) 팀은 LINE 클라이언트 앱의 빌드 개선과 CI 파이프라인 관리, 자동화 지원 등의 업무를 담당하고 있습니다. 이번 글에서는 저희 팀에서 운영하는 CI/CD에 발생했던 흔하지 않은 이슈와 그 해결 방법을 공유하려고 합니다. 이번 글에서 다룰 이슈는 문제가 발생한 시점부터 다시 정상적으로 CI/CD가 운영되기까지 약 10일 정도의 시간이 소요됐는데요. 추후 유사한 문제가 발생했을 때 어떤 식으로 문제의 원인을 찾고, 분석해서, 해결해 나가야 하는지 그 과정을 참고하고자 작성했습니다. 저희의 문제 해결 과정이 이 글을 읽고 계신 분들께도 도움이 되기를 바라며 시작하겠습니다.현재 MPR 팀에서 운영하고 있는 CI의 전체 구성을 간략하게 소개하겠습니다. 먼저 소스 리포지터리로 Git을 사용하고 있으며, Jenkins와 여러 플러그인을 이용해 CI를 운영하고 있습니다. 빌드 개선 및 오류 검토를 목적으로 Gradle을 활용한 빌드 정보를 Develocity에 수집하고 있으며, Jenkins 빌드 로그를 Logstash를 통해 Elasticsearch로 모아서 집계한 뒤 Kibana 및 Grafana를 사용해 빌드 정보를 시각화하고 있습니다.평소와는 다른 빌드 실패 증상의 발현언제부터인가 빌드 실패 알림이 증가했습니다. CI/CD를 운영하다 보면 예기치 못한 여러 문제가 발생할 수 있으며, 그중 빌드 오류가 발생하는 경우는 다음과 같습니다.• 테스트 관련 오류• 플레이키(flaky) 테스트: 코드는 동일한데 테스트 결과는 다른 경우• 느린 테스트: 테스트 실행하는 데 지나치게 오래 걸리는 경우• 인프라 및 성능 관련 오류• 서버 과부하: 동시에 여러 테스트를 처리하느라 서버나 네트워크에 과부하가 걸리는 경우• 확장성 문제: 개발 팀과 프로젝트의 규모가 커지면서 파이프라인이 증가된 부하를 처리하지 못하지만 구조상 확장하기 어려운 경우• 성능 이상: 서버의 응답이 지연되거나 메모리 누수가 발생하거나 부하 분산이 적절히 처리되지 않은 경우• 통합 및 배포 관련 오류• 도구 간 통합 문제: 내부적으로 인터페이스를 구축해 서로 다른 도구를 통합해서 사용하다가 예상치 못한 도구 간 설정 호환 문제가 발생하는 경우일반적인 경우 빌드 실패의 주요 원인은 유닛 테스트 증가에 따른 빌드 및 테스트 수행 시간의 증가입니다. Jenkins에 빌드 타임아웃 시간을 설정해 놓으면 빌드 및 테스트하는 데 이보다 시간이 오래 걸릴 경우 강제로 중단되는데요. 유닛 테스트가 늘어나 테스트 수행 시간이 증가하거나 일시적으로 자원이 부족해 테스트 수행에 실패하면서 설정해 놓은 빌드 타임아웃 시간을 초과하면 빌드에 실패합니다. 보통 이런 경우는 빌드에 사용할 리소스가 일시적으로 부족하거나 네트워크에 간헐적으로 문제가 생겨 발생하기 때문에 빌드를 다시 실행하면 대부분 재현되지 않습니다.저희는 이번 경우 역시 처음에는 이처럼 시간이 지나면 자연스럽게 해결될 일시적인 증상으로 간주하고 원인을 파악하기 시작했습니

안녕하세요! 테스트자동화개발팀에서 자동화 프로그램을 개발하고 있는 6년 차 QA 엔지니어 김정낙입니다.나날이 다양해지는 사용자 요구와 최근 웹 서비스와 애플리케이션의 릴리즈 주기가 점점 더 짧아지고 있는 것을 느끼시나요? 이는 사용자 요구가 날로 다양해지고, 기술이 급속도로 발전함에 따라 더욱 빠르게 변화하는 트렌드와 맞물려, 기업들이 경쟁에서 앞서기 위해 신속한 릴리즈와 새로운 기능의 추가 및 개선을 계속해서 추진하고 있기 때문입니다. AI와 같은 첨단 기술의 도입이 가속화되면서 이러한 현상은 더욱 두드러지게 나타나고 있으며, 이에 따라 개발자와 QA 팀에게는 더욱 빠르고 정확한 테스트가 요구되고 있습니다. 자연스럽게 테스트 자동화의 중요성이 그 어느 때보다 두드러지고 있으며, 지속적 통합(CI) 및 지속적 배포(CD) 같은 DevOps 관행이 확산하면서 테스트 자동화는 이제 필수적인 요소가 되었습니다.이러한 흐름에 맞춰, 우리 회사에서는 기존에 품질보증실에서 각 구성원이 다소 소극적으로 수행하던 자동화 테스트를 더 체계적이고 조직적으로 관리하기 위해 ‘테스트자동화개발팀’을 신설했습니다. 저희 팀은 테스트 자동화의 효과적인 구축 및 운영을 통해 서비스 품질을 높이고, 여러 측면에서 회사에 기여하기 위해 다양한 목표를 세우고 열심히 노력하고 있습니다.테스트 자동화의 개념과 장점에 대해서는 이전에 저희 팀 서연 님이 작성해 주신 “테스트 자동화 개발팀을 소개합니다” 글에서 이미 충분히 설명해 드렸으므로,이 글에서는 효율적인 테스트 자동화 구축을 위해, 처음으로 어떤 자동화 테스트를 구현해 보고 이를 어떻게 활용하고 운영했는지에 대한 경험을 공유하고자 합니다. 이 글이 테스트 자동화에 관심 있는 분들께 도움이 되기를 바랍니다!저희 팀이 처음 설립된 이후, 자동화 테스트 기반이 되는 솔루션 구축을 중점적으로 진행하면서, 동시에 서비스에 직접적으로 기여할 수 있는 테스트 개발을 병행해야 했습니다. 이러한 상황에서, 낮은 비용으로 높은 효과를 거둘 수 있는 자동화 테스트의 첫 단추를 어떻게 끼워야 할지 고민이 많았습니다.이때 저희는 세 가지 이유로 API 테스트를 선택했습니다.많은 수의 효과적인 자동화 테스트가 유지 보수가 어려워 폐기되는 경우가 많습니다.UI 테스트의 경우 디자인 변경, 사용자 흐름의 변화에 따라 테스트 스크립트 수정이 자주 필요했지만, API는 기능적 요구사항이 확정된 이후 상대적으로 유지 보수 비용이 적고 안정적으로 운영 가능합니다.구현 난이도와 안정성API는 상대적으로 정형화되고 일관된 요청과 응답 구조를 가지고 있습니다.이러한 특징 덕분에, 다양한 사용자 인터페이스 요소와 호환성을 고려해야 하거나, 하나의 동작에 대해 여러 항목을 확인해야 하는 다른 테스트들에 비해 구현이 비교적 수월하며, 안정적으로 운영하기에도 적합합니다.기존 품질팀에서는 주로 UI에서 발생할 수 있는 문제에 초점을 맞춰 검증을 수행해 왔습니다.상대적으로 덜 다루어졌던 API 검증을 지원함으로써, 서비스의 테스트 커버리지를 확장하여, 서비스 품질 향상에

테스트를 거치지 않은 소프트웨어는 없습니다. 하지만 많은 기능을 가져 복잡해진 현대의 소프트웨어를 온전히 테스트하는 것은 굉장히 어려운 일입니다.이러한 테스트를 자동화하지 않은 채 소프트웨어를 지속적으로 배포하는 것은 불가능에 가깝다고 할 수 있습니다. 이번 글에서는 카카오스타일에서 진행하는 UI 테스트 자동화 시스템에 대해 설명해보겠습니다.• 주요 기능 검증: 회귀 테스트(regression testing), 스모크 테스트(smoke testing)를 포함한 단순하고 반복적인 테스트를 대체해, 수동 테스트를 진행하는 QA 인원은 좀 더 복잡하고 찾기 어려운 문제에 집중할 수 있게 합니다• 주요 지면 상시 모니터링: 모니터링 도구(예, 데이터독)의 지표로는 드러나지 않지만, 사용자가 체감할 수 있는 문제를 신속히 발견 및 전파하는 도구로 사용합니다• 코드 관리 및 작성: IntelliJ와 같은 IDE를 활용하여 코드를 작성하고, GitHub를 통해 코드를 관리합니다.• Jenkins: Jenkins는 CI/CD 파이프라인의 핵심으로, 스케줄링을 통해 테스트를 주기적으로 수행합니다.• 장치 연동 및 운영: 다양한 실제 장치(Android, iOS, 웹 브라우저 등)와의 연동을 통해 원격으로 테스트를 모니터링하고 실행합니다.• Appium을 통한 테스트 실행: 연결된 실제 장치에서 Appium을 통해 자동화 테스트를 수행합니다.• 결과 분석 및 보고: Jenkins 및 Appium Dashboard를 통해 상세 로그를 확인하고, Extent Reports로 테스트 결과를 시각화하여 개발팀에 제공하며, Slack Notification으로 실시간 알림을 전송합니다.지그재그 애플리케이션은 네이티브와 웹을 혼합한 하이브리드 구조를 채택하고 있습니다. Appium을 사용하여 주요 기능 및 네이티브와 웹 간의 상호작용을 테스트하여 전체 사용자 경험을 검증하고, 조화롭게 작동하는지 확인합니다.실제 사용자가 애플리케이션을 사용할 때의 시나리오를 기반으로 테스트를 진행합니다. 사용자의 경로를 따라 애플리케이션의 주요 기능이 의도대로 작동하는지 확인합니다. 예를 들어, 로그인, 데이터 입력, 결과 확인 등의 사용자 흐름을 포함합니다.네이티브와 웹 간의 상호작용을 테스트애플리케이션의 하이브리드 구조에서 네이티브와 웹 간의 상호작용이 올바르게 이루어지는지 검증합니다. 이 과정에서는 웹 콘텐츠와 네이티브 컴포넌트 간의 데이터 전달과 이벤트 처리가 정확한지 확인합니다.Jenkins를 사용해 코드를 자동으로 빌드하고 테스트를 수행합니다. Pipeline 스크립트를 통해 이 과정을 정의합니다.Git 저장소에서 최신 코드를 자동으로 체크아웃합니다. 소스 코드 파일이 로컬 작업 디렉토리로 다운로드됩니다.코드를 체크아웃한 후, Maven을 사용하여 프로젝트를 빌드합니다. 이후 테스트를 실행하여 결과를 검증합니다.Extent 리포트를 생성하여 테스트 결과를 시각적으로 확인할 수 있습니다. 이 리포트는 웹 페이지 형식으로 제공되며, 테스트의 상태를 한눈에 확인할 수 있도록 도