PM, 디자이너와 함께하는 종단 테스트 실무 가이드

앞서 제 멘티 개발자 유남주 님과 Playwright를 활용하는 종단 테스트( 종단 테스트가 처음인 개발자를 위한 Playwright 가이드 )에 대해 알아보았습니다.

흥미롭게도 유남주 님은 종단 테스트를 개발자뿐만 아니라 다른 직군과 협업하는 데 활용할 방법을 궁금해했습니다. 이런 모습이 흥미로운 건, 저 역시 종단 테스트를 다른 직군과 함께할 방법을 고민하며 모색해 오고 있었기 때문입니다.

한날: 종단 테스트와 협업, 좋은 질문이자 흥미로운 질문이에요. 이번엔 PM과 디자이너 직군이 종단 테스트에 참여하는 실무 사례와 이를 어떻게 확장, 응용할 수 있을지 좀 더 구체적으로 알아보죠. 실은 저도 본격적으로 도입한 건 아니고 실험적으로 몇 차례 시도하고서 좀 더 나은 방법을 고민하던 차였어요.

Leapwork >

Leapwork 에서는 “E2E 테스트 자동화가 애자일 팀이 빠르게 가치를 전달하는 데 도움을 주며, 개발자와 테스터 간 협력을 강화한다”라고 설명합니다. 팀 단위로 테스트 케이스 설계, 환경 설정, 결과 분석 등을 함께 수행해야 하므로 자연스럽게 커뮤니케이션의 양과 질이 증가한다는 뜻이지요. 저 역시 같은 생각입니다.

PM, 디자이너 협업 도구로의 종단 테스트 테스트 자동화는 단순히 개발자만의 영역이 아닙니다. 서비스 기획(사용자 스토리)과 UX 디자인(화면, 인터랙션)에서도 깊이 관여할 여지가 많습니다. 따라서 PM과 디자이너가 종단 테스트에 참여하거나 그 결과를 검토할 때, 협업 효율이 좋아질 것이라 생각합니다. 실제 운영 환경에서 나타날 오류를 여러 관점으로 빠르게 찾아낼 수 있을 겁니다.

PM과 함께 종단 테스트하기 프로토타입을 평가할 때, 로그인, 회원가입 같은 필수 시나리오를 종단 테스트로 검증하며 출시 일정과 우선순위를 체계적으로 관리할 수 있습니다. 만약 테스트가 실패하면 곧바로 PM이 스프린트 목표를 다시 설정하거나 주요 결함 해결 우선순위를 재조정할 수 있으니까요. QA로 배포될 때까지 기다리지 않아 기민한 대응이 가능합니다.

즉, 사용자 스토리 기반으로 종단 테스트를 수행하고 진행 상황을 관리하면, 실제 운영 환경에서 발생할 문제에 미리 대응할 수 있어 출시와 배포의 안정성을 제고할 수 있습니다.

유남주: 그러니까 PM이 직접 테스트 코드를 짜는 건 아니지만, 일정 기반으로 설계에 관여하는 방식이군요. 우선순위가 조정되면 다음 스프린트에 영향을 미칠 테니까요.

한날: 일반적으로 사용자 시나리오를 정의하는 주체는 PM이니까요. 사용자 시나리오야말로 어떤 흐름을 중점적으로 테스트할지 결정하는 데 중요한 역할을 합니다.

유남주: 그런데 설명 중에 사용자 스토리도 있었는데, 사용자 스토리는 어떻게 연계하는 건가요?

PM이 작성한 사용자 스토리, 이를테면, 모바일 장바구니 동기화나 결제 흐름 간소화 등을 그대로 테스트 시나리오에 반영하면 어떨까요? 실제 요구사항을 충족하는지, 그에 대한 검증을 자동화할 수 있습니다. 기획-개발-테스트가 원활히 맞물려 돌아가도록 함으로써, 초기에 결함을 발견하고 일정을 효율적으로 조정하는 데 유리합니다.

유남주: 종단 테스트는 정말로 사용자 스토리와 밀접하게 연동되겠네요.

한날: 예를 하나 들면 무엇이 있을까요?

유남주: 가 하면 한다. 어때요?

좋은 예시입니다. 이런 스토리에 대응해 환영 페이지를 로그인 상태에서만 볼 수 있게 구현하고 종단 테스트를 수행할 수 있습니다. 곧 종착 페이지의 URL이 환영 페이지인지 검증해 문제가 있는지를 명확하고 빠르게 탐지할 수 있겠죠.

PM이 종단 테스트의 시나리오를 이해하고 숙지하고 있다면, 문제가 발견되었을 때도 개발자와는 다른 관점으로 문제를 추적할 수도 있습니다. 글로 작성된 사용자 스토리를 보며 문제를 추적하는 것과 실제로 동작하는 걸 눈으로 보는 건 많이 다르니까요. 주어진(given) 테스트 조건을 조금씩 조정하면서 짧고 빠르게 재현해 피드백을 받을 수 있습니다.

디자이너와 함께 종단 테스트하기 디자이너에게도 종단 테스트는 유용합니다. 물론 디자인 시스템, 스토리북 등 사전에 검증할 방법과 도구가 있지만, 화면 차원에서 사용자와 상호작용하는 모습은 제품이 실제 개발 서버나 스테이징 서버에 배포되어야 확인할 수 있습니다.

하지만 종단 테스트가 있다면, 보다 이른 시점에 UI/UX 흐름을 분석할 수 있습니다. 클릭 후 레이아웃 등이 어긋나지 않고 의도대로 동작하는지, 로딩 등으로 인한 사용자 경험이 어떨지 직접 테스트하거나 녹화 영상을 보며 피드백할 수 있지요. 특히 관찰하고 검증할 시나리오를 한정해 테스트를 수행할 수 있어 효율성 있는 디자인 검토가 가능합니다.

유남주: 디자이너도 테스트 시나리오 작성에 참여하는 건가요?

한날: 그럼요. 사용자 인터랙션 설계는 디자이너의 주 영역이므로, 어떤 화면 전환이나 애니메이션이 중요한지 반영해 주면 협업에 도움이 될 거예요.

유남주: 디자이너가 녹화 영상을 보고 직접 수정안을 낼 수도 있으니 빠르게 의견을 조율할 수 있겠어요.

한날: 바로 그 점이 종단 테스트를 함께하는 협업의 장점입니다. 개발만의 테스트가 아니라, PM, 디자이너 모두가 테스트 결과를 확인해 문제를 함께 해결할 수 있어요.

몹 프로그래밍에 활용하기 종단 테스트를 잘 수행하면 프로그래밍 언어를 모르더라도 시나리오로써 코드를 이해할 수 있습니다. 다른 직군과 협업할 여지가 열리지요.

유남주: 프로그래밍 언어 문법을 모르는데 맥락을 읽어낼 수 있을까요?

한날: 물론 가독성 좋은 코드를 짜야죠. 세밀한 주석도 필요하고요. 하지만 그런 일은 개발 직군 동료, 미래의 나에게도 유용하니 노력할 가치가 있어요.

유남주: 그렇다면 프론트엔드 직군의 종단 테스트 코드를 백엔드 직군이 보며 협업할 수도 있겠네요. 이상적으로만 운영한다면 팀이 다 함께 종단 테스트로 협업하는 것도 가능하겠어요.

그런 협업 방법으로 “몹 프로그래밍(Mob programming)”이 있습니다. 몹 프로그래밍은 여러 명이 함께 컴퓨터 한 대를 공유하며 실시간으로 협업하는 개발 기법입니다. 보통 한 명이 드라이버(Driver) 역할을 맡아 코드를 작성하고, 나머지는 내비게이터(Navigator)가 되어 아이디어와 방향을 제시합니다. 둘이 협업하며 코드를 짜는 페어 프로그래밍의 다수 버전이라고 생각할 수 있죠.

이 방식은 지식 공유와 문제 해결 과정을 가속하는 장점이 있는데, 활용 범위를 프로젝트 기획이나 디자인 영역으로 확장하려면 명확한 사용자 스토리와 시나리오가 있어야 합니다. 그리고 그것이 실체화되어 동작하는 테스트가 바로 종단 테스트죠.

제 경험을 들려 드릴게요. 장바구니에서 결제 완료로 이어지는 과정을 종단 테스트로 수행한 적이 있습니다. 사용자 흐름 상 특이 사항이 있지는 않았습니다. 다만 당시 PM과 UI 디자이너는 쇼핑몰을 개발해 본 적 없는 신입이었고, 그래서인지 기획과 디자인 산출물이 미묘하게 일반적 흐름에서 벗어나 있었죠. 그 때문에 구현하는 입장에서 ‘냄새나는 코드(Code smell)’가 만들어져 개발하는 내내 꺼림직하던 상황이었습니다.

이런 문제야말로 가르쳐주면 해결되는, 비교적 간단한 문제입니다. 둘을 제 옆에 나란히 앉히고 함께 몹 프로그래밍을 시작했습니다.

[단계별 몹 프로그래밍]

1. 사용자 스토리, 시나리오 준비 : PM이 작성한 사용자 스토리를 기반으로, 디자이너가 UI/UX 관점에서 중요한 지점을 명확히 정리합니다. 예를 들어 “장바구니에 담긴 상품이 결제 화면에서도 동일하게 보이고, 결제 완료 시 주문 번호가 표시된다.” 같은 시나리오를 준비합니다.

2. 몹 세션 구성: 한 대의 컴퓨터 앞에 PM, 디자이너가 내비게이터로, 개발자가 드라이버로 모여 일정 시간 동안 집중합니다.

3. 테스트 코드 작성: 내비게이터는 어떤 흐름을 자동화해야 하는지, 어떤 화면 전환이 중요한지 구체적으로 설명합니다. 드라이버는 이를 듣고 E2E 테스트 코드를 실시간으로 작성하거나 업데이트합니다. 코드를 작성할 때, 내비게이터들은 UI나 비즈니스 로직 측면에서 필요한 셀렉터, 애니메이션 시점, 검증 포인트 등을 제안합니다.

4. 실행과 피드백: 작성한 테스트를 즉시 돌려 보고, Trace Viewer나 스크린샷을 확인합니다. 이를테면 디자이너가 “상품 구성 순서를 이렇게 하면 UI가 깨지면서 다음 단계로 진행하지 못해 테스트가 실패한다”고 제시하면, 드라이버가 ARIA 기반 셀렉터로 교체하는 등 빠르게 수정합니다. PM은 결제 흐름 전체가 사용자 스토리에 부합하는지를 모니터링하고, 문제가 있으면 우선순위를 재설정합니다.

종단 테스트 협업을 현실로 만들 실무 프로세스 유남주: 잘 동작한다면, 설레고 멋진 협업이겠네요. 그런데, 정말 누구나 실용적으로 이런 방식을 도입하고 실천할 수 있을까요? 실제로 이렇게 협업하려면 어떤 역량과 환경을 갖춰야 하는지 잘 감이 안 와요. 해본 적이 없어서 그럴까요.

좋은 지적입니다. 우선 현실적으로 종단 테스트를 타 직군과의 협업 수단으로 활용한 경험자는 많지 않을 겁니다.

유사한 협업의 한 형태인 몹 프로그래밍만 하더라도, 드라이버와 내비게이터 간 대화와 판단이 원활하게 이뤄지지 않으면 오히려 비효율이 발생할 수 있습니다. 그래서 미리 각자의 책임과 발언 권한을 합의해 두는 게 좋은데, 이는 경험으로 맞춰가야 합니다. 또, 하다 보니 해결하고자 하는 문제에서 벗어난다거나, 드라이버인 개발자의 숙련도가 낮아 코딩 과정에서 지연이 생겨 내비게이터들이 멍하니 기다리기도 하지요.

이제 그런 한계를 딛고, 종단 테스트를 현실의 협업에 활용하는 과정에서 필요한 프로세스를 소개하겠습니다. 단순히 몹 프로그래밍에 대한 내용이 아닌 종단 테스트를 협업 수단이자 도구로 활용하는 것에 대한 이야기입니다.

1. 사전 준비

협업 과정에서의 역할 분담과 프로세스를 명확히 정의합니다.

2. 사용자 스토리 > 자동화 시나리오 매핑

PM이 작성한 사용자 스토리와 시나리오에 고유 번호나 태그를 부여하고, 이에 대응할 종단 테스트 파일이나 테스트 케이스 ID(예 : PC-0001)를 매핑하여 문서화합니다. 기획이 달라지면, PM은 해당 ID의 문서를 업데이트하고, 개발팀은 연관 테스트 시나리오를 수정해 동기화 정확도를 유지합니다.

3. UI/UX 디자인 리뷰와 테스트 접점

디자이너는 와이어프레임, Low-fi(Low fidelity) 혹은 프로토타입 단계에서 이동 경로, 애니메이션, 주요 버튼 위치 등을 명시합니다. 개발자는 이러한 정보를 바탕으로 Playwright 테스트를 작성해, 클릭 지점이나 전환 효과가 정상적으로 동작하는지 검증하고, 이를 자동화합니다. UI 수정 이슈가 나오면, 디자이너가 테스트 영상(Trace Viewer, 스크린샷)을 보고 수정안을 마련합니다. 개발자가 UI를 반영한 다음 종단 테스트를 재실행해 최종 확인합니다. 테스트 영상이나 스크린샷은 자동으로 특정 공간에 업로드해 편의성을 높입니다.

4. 디자인 QA & A/B 테스트

종단 테스트는 정상 흐름을 검증하는 데 초점을 맞추고, UI/UX 디테일이나 사용성 측면은 별도의 디자인 QA 과정을 둡니다. 특정 화면 레이아웃을 변경해 A/B 테스트를 할 경우, Playwright 시나리오를 분기 처리해 조건별 경로를 자동화하며 검증합니다. 예를 들어, A안에서는 버튼 위치가 상단, B안에서는 하단에 있을 때, 시맨틱 셀렉터나 ARIA 속성을 통해 두 경로를 모두 커버하도록 구성합니다.

5. 협업 도구와의 연계(Jira, ClickUp, Asana, Slack 등)

PM은 테스트 결과와 이슈 트래킹을 Jira 같은 협업 툴과 연동합니다. 또, 각 사용자 스토리가 테스트를 어느 정도 통과했는지 대시보드 형태로 시각화합니다. 디자이너도 스크린샷이나 테스트 영상을 Confluence 또는 위키 등 문서에 첨부합니다. 애니메이션 오류나 레이아웃 문제 등은 Slack 채널에서 논의합니다. (Jira 등에 연동해 메신저에서 이슈 상태를 변경하면 더욱 편리합니다.)

6. Playwright 테스트 리포트 공유

Playwright에서 제공하는 HTML 리포트 등을 CI/CD 파이프라인 이후 단계에서 자동 생성하면, 팀 전체가 쉽게 접근해 테스트 결과를 확인할 수 있습니다. 실패가 발생했을 때, 해당 Trace 파일이나 스크린샷을 PM, 디자이너가 한 번에 볼 수 있게 링크를 공유합니다.

이러한 프로세스의 핵심은 “협업 공통 프로토콜에 집중하는 환경을 조성하는 것”입니다. 예를 들어, 종단 테스트 중 녹화된 동영상을 PM이나 디자이너가 확인하기 어렵거나 매번 개발자가 도와줘야 한다면 종단 테스트 기반 협업을 모두 부담스럽거나 거추장스럽게 여길 겁니다.

PM은 비즈니스 로직과 정책에 집중해 테스트를 보고, 디자이너는 화면 요소나 사용자 경험에 집중해 테스트를 볼 수 있어야, 모두가 테스트 피드백 루프에 온전히 올라타며 효과가 생겨납니다.

마치며 유남주: 프론트엔드에서 종단 테스트하는 방법이나 방향을 알고 싶어 멘토링을 요청했는데, 협업 방법론까지 듣게 될 줄은 몰랐어요.

한날: 종단 테스트 역시 모두 함께 결과를 확인하고 빠르게 피드백을 교환하면, 프로젝트 전반의 품질을 높이는 데 도움을 줘요. 이런 작업이 개발자만의 업무가 아닌, 실제 사용자 흐름을 검증하고 개선하는 과정으로 모든 직군이 참여할 공동 영역이 되는 거죠.

하지만, 반드시 종단 테스트를 협업과 연결해야 한다는 부담은 갖지 않아도 좋습니다. 하면 좋은 이상적인 사례를 든 것이지 필수 요소는 아니니까요. 종단 테스트라는 수단과 방법을 이해하고, 그 특성을 활용할 수 있는 가능성을 찾아보는 것이 중요합니다. 우선은 종단 테스트 도구인 Playwright부터 익히며 여러 시도를 해보는 것도 좋습니다.

종단 테스트로 시작해 PM, 디자이너와 협업하는 이야기를 하니 함께 일할 때의 즐거움이 새록새록 떠오릅니다. 최근에는 주로 인공지능과 페어 프로그래밍하듯 효율적이고 효과적으로 일하고 있는데요, 가끔은 사람과 좌충우돌 우당탕탕 협업하고 싶다는 생각도 듭니다.

다른 직군의 동료와 어떻게 협업을 시작할지 막막하신가요? 우선 종단 테스트로 함께 협업해 보는 건 어떠세요? 무엇보다 재밌을 겁니다.

관련 자료 How to do End-to-end Testing in Agile Teams by Leapwork Endgame Testing: Exploring Your Agile Product End to End by AgileConnection Why End-to-End Testing is Important for Your Team by FreeCodeCamp How to Collaborate Effectively Across Teams for End-to-End Testing by HogoNext Improve End-to-End Testing by TestRail Benefits of end to end testing and how to implement it by American Technology