<div id="readability-page-1" class="page"><div><div><h2 id="efac" data-testid="storyTitle">무신사 Web 테스트 자동화 2.0: 더 빠르고 효율적인 테스트 환경 만들기</h2><div aria-hidden="false"><a rel="noopener follow" href="/@hochul.shin_20042?source=post_page---byline--af3ad971e0af---------------------------------------"><div><p><img alt="Hochul Shin" src="https://miro.medium.com/v2/resize:fill:64:64/1*hHrU8zqcOhtMckdxvRA4gg.jpeg" width="32" height="32" loading="lazy" data-testid="authorPhoto"></p></div></a></div></div><p id="a0bc">안녕하세요, <strong>무신사 QA팀 플랫폼 파트에서 Web 테스트 자동화를 담당하고 있는 신호철입니다.</strong></p><p id="00c9">무신사 서비스가 2.0으로 개편됨에 따라 테스트 자동화도 함께 변화했습니다. 이번 글에서는 Web 테스트 자동화 2.0의 주요 변경 사항을 중심으로 소개하고자 합니다.</p><h2 id="e3dc">왜 변경해야 했나요?</h2><p id="69b3">무신사의 Web 테스트 자동화는 그동안 원활하게 운영되어 왔습니다. 그러나 무신사 2.0 개편으로 UI가 크게 달라지면서, 기존 자동화 방식을 그대로 재활용하기가 어렵게 되었습니다.</p><p id="ba6a">이로 인해 아래와 같은 문제가 발생하여, 새로운 방식으로의 전환이 필요하다고 판단했습니다.</p><h2 id="d78e">무신사 2.0 개편으로 기존 스크립트 재활용이 어려움</h2><p id="18cb">무신사 2.0에서는 UI가 대폭 변경되었습니다. 이와 함께 테스트 케이스도 전면적으로 수정해야 했는데,</p><p id="7a8d">기존 테스트 케이스를 하나하나 분석하고 보완하기보다는 새로운 구조로 처음부터 다시 작성하는 것이 더 효율적이라 판단했습니다.</p><p id="4a5f">또한, 저희 팀은 Selenium을 활용하여 Web 요소를 제어할 때 XPath를 사용하고 있습니다.</p><p id="3dc5">UI가 변경될 때마다 XPath도 변경되므로, 기존 테스트 케이스를 수정하는 것보다 새로운 XPath를 찾는 것이 더 효과적이라고 판단했습니다.</p><h2 id="dc04">수동 테스트 케이스(Manual TC)와 자동화 테스트 케이스(Auto TC) 의 차이로 인한 유지보수 비용 증가</h2><p id="2ed1">수동 테스트 케이스와 자동화 테스트 케이스는 테스트 수행 방식이 다릅니다. 자동화 테스트에서는 테스트 간 전환 과정에서 이루어지는 모든 동작을 일일이 정의해야 하기 때문입니다.</p><ul><li id="3693">“ID 입력 후 로그인 버튼 선택 시 오류 메시지를 확인”하는 테스트</li><li id="e425">“PW 입력 후 로그인 버튼 선택 시 오류 메시지를 확인”하는 테스트</li></ul><p id="b3ba">첫 번째 테스트가 끝나면, 두 번째 테스트를 수행하기 전에 이미 입력되어 있던 ID를 삭제해야 하는데, 이는 수동 테스트 케이스에는 명시되어 있지 않지만 자동화 테스트에서는 반드시 고려해야 하는 부분입니다.</p><p id="cb4f">이처럼 자동화 테스트는 특정 시나리오를 중심으로 동작 하므로, 일부 기능이 변경될 경우 수동 테스트 케이스와 자동화 테스트 케이스를 모두 수정해야 하는 문제가 발생합니다.</p><p id="06e7">결국, 이러한 반복 수정이 누적되어 자동화 테스트의 유지보수가 더욱 복잡해지는 원인이 되었습니다.</p><h2 id="9ce6">어떤것이 변경됐나요?</h2><h2 id="44f2">CI/CD 파이프라인 단순해졌어요</h2><figure><figcaption>as-is</figcaption></figure><p id="f12c">기존(1.0) 자동화 환경에서는 Spinnaker를 사용해 스케줄러와 Webhook Trigger를 구성하고, 이를 통해 Jenkins로부터 전달받은 배포 요청을 처리한 뒤 Kubernetes에 애플리케이션을 배포했습니다.</p><figure><figcaption>to-be</figcaption></figure><p id="0134">2.0으로 전환하면서는 Github Actions만으로 CI/CD 파이프라인을 구성하여 Jenkins나 Spinaker 의 별도 서버 유지보수 할 필요 없어졌습니다. 또한 Github Actions에서 모든 테스트 실행 및 배포가 가능해 졌으므로, 단일 환경에서 모든 정보를 확인 할 수 있습니다.</p><p id="5b23">실행 트리거 역시 유연해져,</p><ul><li id="c616">PR(풀 리퀘스트) 생성 시</li><li id="01b5">특정 브랜치에 병합될 때</li><li id="9b1b">일정 시간 간격으로(스케줄 실행)</li></ul><p id="02cf">와 같이 다양한 조건으로 자동 실행을 설정할 수 있습니다.</p><h2 id="eaef">단순한 테스트 데이터 수정은 DB에서 해결 가능해요</h2><p id="496e">2023년 기준으로, 한 달 동안의 테스트 스크립트 유지보수 작업 중 약 30%가 XPath 수정과 같은 단순 작업이었습니다.</p><figure></figure><p id="90ea">기존에는 테스트 데이터가 코드에 포함되어 있어, 간단한 데이터 변경에도 브랜치를 생성하고 PR을 올린 후 병합 및 배포까지 진행해야 했습니다. 이 과정에는 최소 15분 이상이 소요되었습니다.</p><figure><figcaption>xpath 관리 web page</figcaption></figure><figure><figcaption>xpath 관리 xpath 상세 페이지</figcaption></figure><p id="662c">2.0에서는 테스트 데이터를 전부 DB화하여 코드 수정 없이 Web 페이지에서 직접 수정할 수 있게 되었습니다.</p><p id="6ff1">이를 통해 중복되는 XPath를 최소화하고, 유지보수 비용을 절감할 수 있었습니다.</p><h2 id="35af">수동 테스트 케이스와 자동화 테스트 케이스가 하나로 통일됐어요</h2><figure><figcaption>수동 테스트 케이스 구조와 자동화 테스트 케이스 구조</figcaption></figure><p id="478e">자동화 테스트(Auto TC)의 수행 단위를 수동 테스트(Manual TC)와 동일하게 맞추기 위해, “step” 기반 구조를 새롭게 도입하고, pytest의 fixture 기능을 적극 활용하는 방식으로 개선했습니다.</p><p id="3769">step 단위는 개별적인 기능으로 관리합니다. 예를 들어, 로그인 테스트의 경우 다음과 같은 단위로 나누어집니다.</p><ul><li id="858f">ID 입력 step</li><li id="9141">PW 입력 step</li><li id="9c96">로그인 버튼 클릭 step</li></ul><p id="26f2">이렇게 분리된 step은 재사용이 가능하며, 하나만 수정해도 전체 테스트 케이스에 일괄 반영할 수 있어 유지보수가 훨씬 쉬워집니다.</p><p id="7dff">또한, pytest의 fixture를 활용하여 step을 재사용할 수 있어 테스트 유지보수가 더욱 쉬워졌습니다.</p><p id="f4c5">fixture는 Python의 decorator 문법 중 하나로, pytest에서는 테스트의 사전 조건을 자동으로 설정하거나 초기화하는 데 활용됩니다.</p><p id="2b9c">예를 들어, 다음과 같은 테스트 케이스가 있다고 가정해 보겠습니다.</p><blockquote><p id="02c7"><em>기대 결과: “로그인 버튼을 선택하면 마이페이지로 이동한다.”</em></p></blockquote><p id="3404">보통 이 테스트 케이스에서는 사전 조건으로 ID와 PW 입력이 필요합니다. 이때, fixture를 사용하면 자동화 테스트 케이스가 실행되기 전에 ID와 PW를 입력하도록 설정할 수 있으며, 테스트 케이스에서 로그인 버튼 선택 step만 호출하여 수행 절차를 간결하게 만들 수 있습니다.</p><p id="0610">이렇게<strong> </strong>자동화 테스트 케이스를 사전 조건과 수행 절차로 나누어 작성하면, 아래와 같은 장점 있습니다.</p><ul><li id="5a85">실제 결함인지, 환경적 요인으로 인해 실패한 것인지 쉽게 구분할 수 있습니다.</li><li id="8e5e">로그인이 필요한 테스트 시나리오를 수행하기 전에 미리 로그인 상태를 설정할 수 있습니다.</li><li id="fc83">테스트 종료 후 로그아웃을 자동으로 실행하여 계정 상태를 초기화하는 것도 가능합니다.</li></ul><figure><figcaption>testrail의 실제 테스트 케이스</figcaption></figure><figure><figcaption>코드로 구현된 자동화 테스트 케이스</figcaption></figure><p id="ef3c">실제 테스트에서는 로그인 및 주문서 이동과 같은 사전 조건을 auto_login, move_order 같은 fixture로 분리하여 처리하고 있습니다.<br>각 테스트 케이스의 기대 결과는 자동화 테스트 케이스 내부에 정의되어 있으며, 이를 통해 수동 테스트 케이스와 동일한 흐름으로 자동화 테스트를 수행할 수 있습니다.</p><h2 id="78df">중복 동작은 1번만 수행해요</h2><p id="3042">pytest의 fixture는 scope 설정을 통해, 공통 동작을 테스트 실행 중 한 번만 수행하도록 최적화할 수 있습니다.</p><p id="86c2">예를 들어,</p><p id="681c">• 결제 완료 후 주문내역 페이지에서 상품 정보를 확인</p><p id="34f5">• 결제 완료 후 주문내역 페이지에서 주문 상세 페이지로 이동 확인</p><p id="3afc">이 두 테스트 모두 로그인과 결제 완료라는 동일한 사전 조건을 포함합니다. 기존에는 각 테스트마다 로그인과 결제 과정을 반복 수행해야 했지만, 2.0에서는 해당 동작을 한 번만 실행하도록 최적화했습니다.</p><p id="d15a">과거에는 약 350개의 테스트 케이스를 수행하는 데 1시간 40분(100분)이 소요되었으나, 최적화를 통해 현재는 약 740개의 테스트 케이스(TC)를 동일한 시간 내에 완료할 수 있게 되어 기존 대비 테스트 효율이 크게 향상되었습니다.</p><p id="9f36">물론 과거와 현재의 테스트 케이스 구성이 완전히 동일하지는 않지만, TC당 평균 수행 시간 기준으로 보면 과거에는 약 <strong>17.1초/TC</strong>, 현재는 약 <strong>8.1초/TC</strong>로 <strong>절반 이하 수준으로 단축</strong>되었습니다.</p><figure><figcaption>중복 동작 예시 1</figcaption></figure><figure><figcaption>중복 동작 예시 2</figcaption></figure><h2 id="bd00">필요한 결과만 볼 수 있어요</h2><p id="038c">기존 1.0에서는 Allure 리포트를 사용하여 테스트 결과를 관리했습니다. Allure는 매우 상세한 리포트를 제공하지만, 별도의 서버를 유지·관리해야 하는 단점이 있었습니다.</p><figure><figcaption>slack에 발송된 테스트 케이스 수행 결과 예시</figcaption></figure><p id="30f5">2.0에서는 Allure 서버를 제거하고, 대신 Slack과 TestRail을 활용해 필수 결과만 간결하게 전송하는 방식으로 변경했습니다. 덕분에 별도 서버 운영에 필요한 리소스를 줄일 수 있었고, 테스트가 실패하면 스크린샷, 수행 시간, 실패 원인과 같은 중요 정보를 Slack에서 바로 확인할 수 있도록 개선되었습니다.</p><h2 id="190b">마치면서…</h2><p id="c7cf">Web 테스트 자동화 2.0은 <strong>완성된 솔루션은 아닙니다.</strong></p><p id="8068">앞으로도 더 나은 테스트 자동화로 발전해나가기 위해 플랫폼 파트에선 다양한 방법을 시각으로 검토 중이며 AI도입, MW이 아닌 PC 환경 자동화, 파트너 어드민 자동화 등이 예정되어 있습니다.</p><p id="795a"><strong>이러한 변화는 단지 기술적 시도에 그치지 않고, 그동안 축적된 경험과 노하우 위에서 이루어지고 있습니다. </strong>기존 코드를 기반으로 발전시킬 수 있었던 만큼, <strong>팀원들의 도움과 기존 담당자의 노력이 큰 힘이 되었습니다.</strong></p><p id="1c53">앞으로의 여정에도 많은 관심과 응원 부탁드립니다.</p></div><div><h2 id="7639">MUSINSA CAREER</h2><blockquote><p id="9eb2">무신사 QA팀은 품질을 문화로 만들어, 사용자에게 신뢰할 수 있는 서비스 경험을 제공하는 것을 지향합니다.</p><p id="f28a">웹, 모바일 앱, 백엔드 API 등 다양한 영역에서 지속 가능한 품질 확보를 목표로, 자동화, 테스트 전략, 모니터링을 체계적으로 운영합니다. 또한, 기획·설계 단계부터 품질을 함께 설계하며 조기 결함 예방에 힘쓰고, 개발, 기획, CS, 운영 등 전 부서와의 유기적인 협업을 통해 품질 책임을 조직 전체로 확장합니다.</p><p id="2415">테스트 결과, 결함 데이터, 고객 피드백을 수치화하여 데이터 기반으로 품질을 진단하고 개선 방향을 제시하는 것 역시 무신사 QA팀의 핵심 역할입니다.<br>우리는 테스트를 넘어, 무신사의 서비스 가치와 고객 신뢰를 함께 만들어 갑니다.</p><p id="7fd3">🚀 <a href="https://corp.musinsa.com/ko/career/" rel="noopener ugc nofollow" target="_blank">팀 무신사 채용 페이지</a> (무신사/29CM 전체 포지션 확인이 가능해요)</p><p id="6e36">🚀 <a href="https://kr.linkedin.com/company/musinsacom" rel="noopener ugc nofollow" target="_blank">팀 무신사 테크 소식을 받아보는 링크드인</a></p><p id="998d">🚀 <a href="https://medium.com/musinsa-tech" rel="noopener">무신사 테크 블로그</a></p><p id="000d">🚀 <a href="https://medium.com/29cm" rel="noopener">29CM 테크 블로그</a></p><p id="a65a">🚀 <a href="https://www.youtube.com/@MUSINSATECH" rel="noopener ugc nofollow" target="_blank">무신사 테크 유튜브 채널</a></p></blockquote><p id="40f6"><em>채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!</em></p></div></div>

MUSINSA tech - Medium

안녕하세요, 무신사 QA팀 플랫폼 파트에서 Web 테스트 자동화를 담당하고 있는 신호철입니다.
무신사 서비스가 2.0으로 개편됨에 따라 테스트 자동화도 함께 변화했습니다. 이번 글에서는 Web 테스트 자동화 2.0의 주요 변경 사항을 중심으로 소개하고자 합니다.
왜 변경해야 했나요?
무신사의 Web 테스트 자동화는 그동안 원활하게 운영되어 왔습니다. 그러나 무신사 2.0 개편으로 UI가 크게 달라지면서, 기존 자동화 방식을 그대로 재활용하기가 어렵게 되었습니다.
이로 인해 아래와 같은 문제가 발생하여, 새로운 방식으로의 전환이 필요하다고 판단했습니다.
무신사 2.0 개편으로 기존 스크립트 재활용이 어려움
무신사 2.0에서는 UI가 대폭 변경되었습니다. 이와 함께 테스트 케이스도 전면적으로 수정해야 했는데,
기존 테스트 케이스를 하나하나 분석하고 보완하기보다는 새로운 구조로 처음부터 다시 작성하는 것이 더 효율적이라 판단했습니다.
또한, 저희 팀은 Selenium을 활용하여 Web 요소를 제어할 때 XPath를 사용하고 있습니다.
UI가 변경될 때마다 XPath도 변경되므로, 기존 테스트 케이스를 수정하는 것보다 새로운 XPath를 찾는 것이 더 효과적이라고 판단했습니다.
수동 테스트 케이스(Manual TC)와 자동화 테스트 케이스(Auto TC) 의 차이로 인한 유지보수 비용 증가
수동 테스트 케이스와 자동화 테스트 케이스는 테스트 수행 방식이 다릅니다. 자동화 테스트에서는 테스트 간 전환 과정에서 이루어지는 모든 동작을 일일이 정의해야 하기 때문입니다.
“ID 입력 후 로그인 버튼 선택 시 오류 메시지를 확인”하는 테스트
“PW 입력 후 로그인 버튼 선택 시 오류 메시지를 확인”하는 테스트
첫 번째 테스트가 끝나면, 두 번째 테스트를 수행하기 전에 이미 입력되어 있던 ID를 삭제해야 하는데, 이는 수동 테스트 케이스에는 명시되어 있지 않지만 자동화 테스트에서는 반드시 고려해야 하는 부분입니다.
이처럼 자동화 테스트는 특정 시나리오를 중심으로 동작 하므로, 일부 기능이 변경될 경우 수동 테스트 케이스와 자동화 테스트 케이스를 모두 수정해야 하는 문제가 발생합니다.
결국, 이러한 반복 수정이 누적되어 자동화 테스트의 유지보수가 더욱 복잡해지는 원인이 되었습니다.
어떤것이 변경됐나요?
CI/CD 파이프라인 단순해졌어요
기존(1.0) 자동화 환경에서는 Spinnaker를 사용해 스케줄러와 Webhook Trigger를 구성하고, 이를 통해 Jenkins로부터 전달받은 배포 요청을 처리한 뒤 Kubernetes에 애플리케이션을 배포했습니다.
2.0으로 전환하면서는 Github Actions만으로 CI/CD 파이프라인을 구성하여 Jenkins나 Spinaker 의 별도 서버 유지보수 할 필요 없어졌습니다. 또한 Github Actions에서 모든 테스트 실행 및 배포가 가능해 졌으므로, 단일 환경에서 모든 정보를 확인 할 수 있습니다.
실행 트리거 역시 유연해져,
PR(풀 리퀘스트) 생성 시
특정 브랜치에 병합될 때
일정 시간 간격으로(스케줄 실행)
와 같이 다양한 조건으로 자동 실행을 설정할 수 있습니다.
단순한 테스트 데이터 수정은 DB에서 해결 가능해요
2023년 기준으로, 한 달 동안의 테스트 스크립트 유지보수 작업 중 약 30%가 XPath 수정과 같은 단순 작업이었습니다.
기존에는 테스트 데이터가 코드에 포함되어 있어, 간단한 데이터 변경에도 브랜치를 생성하고 PR을 올린 후 병합 및 배포까지 진행해야 했습니다. 이 과정에는 최소 15분 이상이 소요되었습니다.
2.0에서는 테스트 데이터를 전부 DB화하여 코드 수정 없이 Web 페이지에서 직접 수정할 수 있게 되었습니다.
이를 통해 중복되는 XPath를 최소화하고, 유지보수 비용을 절감할 수 있었습니다.
수동 테스트 케이스와 자동화 테스트 케이스가 하나로 통일됐어요
자동화 테스트(Auto TC)의 수행 단위를 수동 테스트(Manual TC)와 동일하게 맞추기 위해, “step” 기반 구조를 새롭게 도입하고, pytest의 fixture 기능을 적극 활용하는 방식으로 개선했습니다.
step 단위는 개별적인 기능으로 관리합니다. 예를 들어, 로그인 테스트의 경우 다음과 같은 단위로 나누어집니다.
ID 입력 step
PW 입력 step
로그인 버튼 클릭 step
이렇게 분리된 step은 재사용이 가능하며, 하나만 수정해도 전체 테스트 케이스에 일괄 반영할 수 있어 유지보수가 훨씬 쉬워집니다.
또한, pytest의 fixture를 활용하여 step을 재사용할 수 있어 테스트 유지보수가 더욱 쉬워졌습니다.
fixture는 Python의 decorator 문법 중 하나로, pytest에서는 테스트의 사전 조건을 자동으로 설정하거나 초기화하는 데 활용됩니다.
예를 들어, 다음과 같은 테스트 케이스가 있다고 가정해 보겠습니다.
기대 결과: “로그인 버튼을 선택하면 마이페이지로 이동한다.”
보통 이 테스트 케이스에서는 사전 조건으로 ID와 PW 입력이 필요합니다. 이때, fixture를 사용하면 자동화 테스트 케이스가 실행되기 전에 ID와 PW를 입력하도록 설정할 수 있으며, 테스트 케이스에서 로그인 버튼 선택 step만 호출하여 수행 절차를 간결하게 만들 수 있습니다.
이렇게 자동화 테스트 케이스를 사전 조건과 수행 절차로 나누어 작성하면, 아래와 같은 장점 있습니다.
실제 결함인지, 환경적 요인으로 인해 실패한 것인지 쉽게 구분할 수 있습니다.
로그인이 필요한 테스트 시나리오를 수행하기 전에 미리 로그인 상태를 설정할 수 있습니다.
테스트 종료 후 로그아웃을 자동으로 실행하여 계정 상태를 초기화하는 것도 가능합니다.
실제 테스트에서는 로그인 및 주문서 이동과 같은 사전 조건을 auto_login, move_order 같은 fixture로 분리하여 처리하고 있습니다.
각 테스트 케이스의 기대 결과는 자동화 테스트 케이스 내부에 정의되어 있으며, 이를 통해 수동 테스트 케이스와 동일한 흐름으로 자동화 테스트를 수행할 수 있습니다.
중복 동작은 1번만 수행해요
pytest의 fixture는 scope 설정을 통해, 공통 동작을 테스트 실행 중 한 번만 수행하도록 최적화할 수 있습니다.
예를 들어,
• 결제 완료 후 주문내역 페이지에서 상품 정보를 확인
• 결제 완료 후 주문내역 페이지에서 주문 상세 페이지로 이동 확인
이 두 테스트 모두 로그인과 결제 완료라는 동일한 사전 조건을 포함합니다. 기존에는 각 테스트마다 로그인과 결제 과정을 반복 수행해야 했지만, 2.0에서는 해당 동작을 한 번만 실행하도록 최적화했습니다.
과거에는 약 350개의 테스트 케이스를 수행하는 데 1시간 40분(100분)이 소요되었으나, 최적화를 통해 현재는 약 740개의 테스트 케이스(TC)를 동일한 시간 내에 완료할 수 있게 되어 기존 대비 테스트 효율이 크게 향상되었습니다.
물론 과거와 현재의 테스트 케이스 구성이 완전히 동일하지는 않지만, TC당 평균 수행 시간 기준으로 보면 과거에는 약 17.1초/TC, 현재는 약 8.1초/TC로 절반 이하 수준으로 단축되었습니다.
필요한 결과만 볼 수 있어요
기존 1.0에서는 Allure 리포트를 사용하여 테스트 결과를 관리했습니다. Allure는 매우 상세한 리포트를 제공하지만, 별도의 서버를 유지·관리해야 하는 단점이 있었습니다.
2.0에서는 Allure 서버를 제거하고, 대신 Slack과 TestRail을 활용해 필수 결과만 간결하게 전송하는 방식으로 변경했습니다. 덕분에 별도 서버 운영에 필요한 리소스를 줄일 수 있었고, 테스트가 실패하면 스크린샷, 수행 시간, 실패 원인과 같은 중요 정보를 Slack에서 바로 확인할 수 있도록 개선되었습니다.
마치면서…
Web 테스트 자동화 2.0은 완성된 솔루션은 아닙니다.
앞으로도 더 나은 테스트 자동화로 발전해나가기 위해 플랫폼 파트에선 다양한 방법을 시각으로 검토 중이며 AI도입, MW이 아닌 PC 환경 자동화, 파트너 어드민 자동화 등이 예정되어 있습니다.
이러한 변화는 단지 기술적 시도에 그치지 않고, 그동안 축적된 경험과 노하우 위에서 이루어지고 있습니다. 기존 코드를 기반으로 발전시킬 수 있었던 만큼, 팀원들의 도움과 기존 담당자의 노력이 큰 힘이 되었습니다.
앞으로의 여정에도 많은 관심과 응원 부탁드립니다.
MUSINSA CAREER
무신사 QA팀은 품질을 문화로 만들어, 사용자에게 신뢰할 수 있는 서비스 경험을 제공하는 것을 지향합니다.
웹, 모바일 앱, 백엔드 API 등 다양한 영역에서 지속 가능한 품질 확보를 목표로, 자동화, 테스트 전략, 모니터링을 체계적으로 운영합니다. 또한, 기획·설계 단계부터 품질을 함께 설계하며 조기 결함 예방에 힘쓰고, 개발, 기획, CS, 운영 등 전 부서와의 유기적인 협업을 통해 품질 책임을 조직 전체로 확장합니다.
테스트 결과, 결함 데이터, 고객 피드백을 수치화하여 데이터 기반으로 품질을 진단하고 개선 방향을 제시하는 것 역시 무신사 QA팀의 핵심 역할입니다.
우리는 테스트를 넘어, 무신사의 서비스 가치와 고객 신뢰를 함께 만들어 갑니다.
🚀 팀 무신사 채용 페이지 (무신사/29CM 전체 포지션 확인이 가능해요)
🚀 팀 무신사 테크 소식을 받아보는 링크드인
🚀 무신사 테크 블로그
🚀 29CM 테크 블로그
🚀 무신사 테크 유튜브 채널
채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!
무신사 Web 테스트 자동화 2.0: 더 빠르고 효율적인 테스트 환경 만들기 was originally published in MUSINSA tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

무신사 Web 테스트 자동화 2.0: 더 빠르고 효율적인 테스트 환경 만들기

댓글