7. 결제 단말기 E2E 자동화 도입 및 운영 사례

QA 컨퍼런스에서 일곱 번째 발표를 맡아주신 이성수 님의 발표 내용을 정리해 보도록 하겠습니다.

토스 단말기에 대한 E2E(End to End) 테스트 자동화를 도입한 사례에 대한 설명을 해주셨습니다.

시작부터 끝까지, 왜 그렇게 자동화를 구성했어야 했는지에 대한 설명을 상세하게 말씀해 주셔서 재밌게 본 발표였습니다. 

제품의 사진을 직접 보여주셔서 집 앞에 있던 기계인데! 바로 생각났습니다 😃😃
말씀해주신 내용으로 발표를 정리해 보도록 하겠습니다

제가 작성하는 내용은 컨퍼런스 후기일 뿐입니다!
QA 컨퍼런스에 직접 참여하셔서 발표를 들어보시는 것을 정말 추천드립니다!

QA 코리아 컨퍼런스 : https://www.qa-korea.com/

이성수 님 링크드인 : 링크드인 연결 링크

 

 

QA 컨퍼런스의 일곱 번째 발표는 이성수 님이 발표해 주셨습니다. 토스 플레이스의 토스 단말기를 테스트하는 방식을 설명해 주시면서 E2E 테스트를 어떤 방식으로 자동화했는지, 자동화할 수밖에 없었는지에 대해 설명을 해주셨습니다.

 

QA 업무 중 테스트 업무를 진행하다보면 기기 별, 환경 별 테스트를 진행하다 보면 자동화가 꼭 있으면 좋겠다고 생각이 드는데 토스 플레이스에선 어떤 방식으로 진행했는지 궁금하게 만드는 도입부였습니다.

제가 업무할 때 기기별(PC, 태블릿, 모바일), 브라우저 별(Chrome, Edge, IE 11, Samsung Internet 등), OS 별(Android, iOS) 테스트를 해봐야 했던 업무가 있었는데 자동화 환경이 구축되면 정말 좋겠다는 생각을 많이 했기 때문입니다 😂

 

 

발표를 시작하기 전 토스 단말기를 소개해주셨고, 고객용 단말기에서는 Adb(Android Debug Bridge)를 사용할 수 없도록 제작되었기에 테스트용 기기에서만 테스트 자동화를 수행할 수 있다고 알려주셨습니다. 실제 결제 수단을 사용해서 결제를 하는 것까지 자동화 테스트를 수행한다고 하시네요.

 

테스트 자동화 도입 배경부터 구현 범위를 선정하고 실제 테스트 구현과 어떤 방식으로 운영되는지에 대한 설명을 해주신다고 말씀해 주셨습니다.

 

 

테스트 자동화를 도입하게 된 배경은 역시 테스트에 많은 리소스를 투입하는 것은 어렵기 때문이라고 하셨고, 고객의 니즈를 맞추기 위해 매주 배포 작업을 진행하는데, 매번 매뉴얼 테스트를 진행한다면 테스트 작업에 많은 공수가 투입되는 것이 문제였다고 부가적인 말씀을 해주셨습니다.

 

자동화 테스트가 도입되었을 때 가장 좋은 장점에 대한 이야기를 해주셨습니다. 테스트 자동화가 구축되면 매주 테스트를 수행하는 공수도 없어지고 오히려 데일리 빌드 방식으로 돌리면 더 자주 테스트가 수행될 수 있기 때문입니다. 테스트 자동화는 처음 도입 시 가장 많은 공수가 사용되지만, 환경만 구축된다면 공수 절감 효과는 분명하니까요 😎

 

자동화 테스트는 프로그램에서 가장 중요한 결제 시나리오에 대한 E2E 테스트 자동화를 도입하는 것을 목표로 자동화 구성 작업을 진행하셨다고 하셨습니다.

 

 

자동화 구현하기 전 구상한 구현 순서에 대한 설명을 해주셨고, 자동화 플랜 작성에 대한 이야기를 해주셨습니다. 

플랜 작성에는 자동화 구현 허들에 대한 내용이 있었는데, 자동화 구현 시 제약사항과 구현 범위를 선정하는 일이었다고 하셨습니다. 

 

첫 번째 제약사항은 목록에 보이시는 것처럼 IC, NFC, QR 등 실제 결제를 수행할 수 있기 때문에 다양한 방식에 대한 커버리지를 달성하는 것이 필요했다고 말씀하셨습니다. 

 

 

두 번째 제약 사항은 다양한 기기를 지원해야 한다는 것이었습니다. 제가 알고 있는 기기는 결제 금액을 누르고 카드를 기계에 긁는 카드 결제 단말기나 키오스크나 크기가 작은 키오스크 결제 기기 이 정도만 알고 있었는데 더 다양한 기기들이 있었고 이 기기들을 각각 테스트를 수행해야 한다고 했습니다.

 

세 번째 제약사항은 다양한 Van 사의 결제 처리 방식이 다르게 동작하기 때문에 Van 사 별 테스트를 진행해야 한다고 하네요. 처음엔 Van 사가 뭘 말하는 건지 몰랐는데, 가맹점과 금융 기관 사이에서 중계자 역할을 하는 업체라고 하네요. 그래도 이해가 잘 안 돼서 한번 찾아봤습니다.

 

 

어디서 본 듯한 마크와 본 듯한 이름들의 회사네요. 영수증이나 인터넷 쇼핑할 때 메일로 발송 오는 결제 청구서에서 본 이름들 같습니다! 이렇듯 다양한 Van 사 마다 결제 처리 방식이 다르기 때문에 테스트를 수행해야 한다고 하셨습니다.

 

 

위에서 언급한 내용들을 다 조합해서 테스트를 한다면 2000개 이상의 조합이 나오기 때문에 오히려 테스트 수행 시간이 오래 걸릴 것이라 판단하여, 정말 필요한 항목들만 추려내고 Dev 환경을 지원하는 항목만 대상으로 선정해서 테스트 범위를 수정했다고 하셨습니다. 

 

줄인다 해도 많아 보이는 테스트 케이스와 기기나 결제 수단 테스트는 어떤 방식으로 구현했을지 점점 더 궁금했습니다. 

 

 

자동화 구현 단계에 대한 설명을 해주셨는데요, 자동화 툴 선정 시 고려한 항목에 대해 설명해 주셨습니다. 포스와 VCat 환경에서 테스트가 가능하며 Java/Kotlin 언어를 지원하고 병렬로 동시 테스트가 가능한 테스트 도구는 Seleniuim과 appium 밖에 없어서 이 도구를 선정해서 테스트를 수행했다고 하셨습니다. 그리고 TestNG를 병행해서 테스팅을 수행했다고 하시네요.

 

제가 알기로도 Selenium이 자동화 부분에선 가장 오래된 만큼 테스트 환경을 지원하는 범위가 가장 넓다고 알고 있었습니다. appium은 현재까지도 모바일 테스트에서 가장 많이 쓴다는 것으로 알고 있는 툴이었습니다. 그래도 Selenium의 경우 다른 툴로 대체되는 경우가 종종 있는데, 사용하시는 이유가 궁금하긴 했습니다 🤔

다른 분이 QnA로 관련 질문하셨긴 했는데 잘 못 들어서 나중에 QnA 답변 목록으로 봐야겠습니다 😮

 

 

그리고 여러 드라이브를 동시에 컨트롤할 수 있는 환경을 만들기 위해서 구조를 커스텀하는 작업을 했다고 하셨습니다. 단순히 클릭하는 동작들이 여러 드라이브로 다르게 구현하고 적용해야 한다면 많은 시간이 걸리기 때문에 공통으로 묶을 수 있는 Action 기능들은 통합하여 관리하셨다고 하시네요. 구조를 커스텀했기 때문에 드라이브 환경에 맞게 동작되도록 처리했다고 하셨습니다.

 

 

이후 자동화 구현에서 가장 중요하다고 생각하신 E2E 테스트에 대한 설명을 해주셨습니다. 사용자가 실제 환경에서 동작하는 것과 동일한 시나리오를 작성해서 검증하는 것이며 검증할 때 가장 중요한 건 Mocking을 최소화하여 구현한다는 점을 강조하셨습니다.

 

Mock은 아마 QA 관련 자격증 공부를 해보셨거나 개발자라면 테스트 케이스를 작성할 때 알 수 있을 것 같은데요,  Test Stub과 유사한 역할이라고 생각할 수 있습니다.(같지는 않습니다!)

가상의 객체를 사용하여 행동을 검증하는 테스트 방식입니다. 예를 들자면 결제에 대한 테스트를 할 때 Mock 개념을 사용하면 실제 결제는 하지 않았지만 "결제 됐어 다음 테스트 진행해도 좋아"라는 가상의 수행 동작에 대한 응답을 주어 테스트 작업을 수월하게 진행할 수 있습니다. 하지만 이런 부분을 최소화했다는 것은 테스트할 때마다 실제 결제를 통해서 했다는 것인데 놀라웠습니다 😮 

 

실제와 동일한 동작을 수행하지만 매번 할 수 있는 건가?라는 생각도 들었습니다

 

 

그리고 키오스크 결제 방식을 예로 들고 직접 테스트 코드를 보여주시면서 내용을 설명해 주셨습니다. 기능의 동작마다 함수가 있고 이를 호출만 수행하면 상황에 맞는 동작을 하게 된다고 하시네요.

 

이를 구현하기 위해서는 자동화 코드는 POM(Page Object Model) 구조로 만들어야 한다고 하셨습니다.

각 페이지에 기능을 캡슐화하고, 테스트 스크립트와 객체를 분리하여 유지 보수, 가독성을 향상했다고 하시네요.

 

저도 POM 구조를 만들어서 자동화 작업을 구성하고 있는데, 확실히 유지보수나 테스트 스크립트 관리하기가 편합니다. 페이지 모델에 기능을 만들어두면 시나리오에 대한 스크립트를 작성할 때 페이지 이동에 따라 관련 함수를 호출만 해주면 동작이 되기 때문입니다. 미리 만들어둔 기능을 조립만 하면 하나의 스크립트가 바로 완성이 되는 것이죠!

 

 

그다음으로 실제 상황을 생각하여 하나의 시나리오 구조를 설계했다고 하셨습니다. 카페 상황을 예시로 들어서 고객이 직접 주문하는 경우에 대한 과정들을 시퀀스 다이어그램 형식으로 보여주시며 설명해 주셨습니다. 

 

스크립트를 작성하기 전 동작할 수 있는 상황들을 예상하고 각각의 동작들을 캡슐화된 코드로 작성해 두면 필요한 부분에서 바로 호출해서 사용할 수 있을 것 같네요. 코드를 구현하기 전 어떤 상황에 대한 시나리오를 작성할 것인지 미리 그려두고 작성하면 좋을 것 같다는 생각을 하게 되었습니다. 저도 여러 시나리오를 구상해보고 있는데 제 업무에 바로 적용할 수 있을 것 같아서 더 집중하게 되었습니다 🤤

 

 

그리고 다양한 환경에 대한 테스트 대응 방법에 대한 설명을 해주셨습니다. 기기별로 다른 상황에서 동일한 코드를 수행하기 위해 Page Factory 개념을 사용하셨다고 하셨어요.

 

 

기기 환경에 따라 다른 점은 Element 경로가 다르기 때문에 태그를 주어 상황에 맞는 Element를 사용하도록 구성하셨다고 하셨습니다. 환경마다 표시하는 태그 값이 다를 수 있는 환경에서 사용하면 좋을 것 같았습니다. 기능과 관련된 부분은 다르게 작업할 부분이 없기에 Element 정보를 관리하는 부분만 위와 같은 방식으로 구성하셨다고 하네요.

 

 

그리고 많은 결제 수단 별 테스트를 하기 위해 여러 단말기를 병렬 동작으로 스크립트를 수행할 수 있는 시스템을 사용해서 테스트 시나리오를 수행했다고 하셨습니다. 병렬로 수행한 덕분에 전체 테스트 시간을 줄일 수 있었다고 하시네요.

 

 

그리고 만들어진 테스트 자동화의 운영은 모두가 쉽게 사용할 수 있도록 환경을 구성하셨다고 하셨습니다. 자동화 실행 봇을 Slack으로 연결해서 봇을 통해서 대상 버전과 Branch 설정만 하면 테스트 자동 수행을 누구나 할 수 있도록 구성하여 자동화 시스템을 더 많이 사용할 수 있도록 제공하셨다고 하시네요.

 

추가적으로 테스트 결과에 대한 알림 봇을 만들어서 결과를 알려주고 테스트 실패 시 실패 영상을 전달할 수 있도록 하여 빠른 피드백 환경을 만드셨다고 하네요.

 

 

테스트 자동화 환경이 구성된 만큼 개발자가 더 많이 사용해서 업무 효율성을 올릴 수 있었고, 복잡한 결제 시스템 중 결제 관련된 테스트의 신뢰성을 쌓을 수 있는 효과를 가져왔다고 하셨습니다. 큰 변경사항이 있을 때만 테스트를 집중적으로 수행할 수 있어서 효율적인 업무 분담이 가능해졌고, 매뉴얼 테스트를 진행하지 않기 적은 공수로 많은 효과를 불러올 수 있었다고 하셨습니다.

 

그리고 이 시스템은 QA 프로세스에도 영향을 주어서 자동화 시스템을 통과하지 못했다면 QA Request를 할 수 없는 프로세스를 만들었다고 하시네요. 그리고 개별 Feature의 매뉴얼 테스트와 자동화 시스템의 개발도 작업도 동시에 진행하여 RC 버전 테스트에 바로 적용할 수 있는 프로세스를 구축했다고 하시네요.

 

발표를 들은 소감은 정말 자동화의 장점에 대한 이야기를 많이 해주신 것 같다. 그리고 자동화를 어떤 방식으로 사용하냐에 따라 효율성이 더 많아지도록 사용할 수 있구나라는 것을 배웠습니다. 

저도 지금 자동화 환경을 구성하고 있어서 어떤 방식으로 만들어야 개발자가 자주 사용할 수 있고 간단하게 사용할 수 있는지 검토하고 있는데 슬랙 봇 연결 아이디어를 얻어서 연결 방식을 바로 찾아봐야 할 것 같습니다 🤩

 

그리고 다양한 환경과 수많은 경우의 수를 테스트하기 위한 노력과 많은 아이디어를 구상했던 것 같아서 대단하다고 느꼈고 많은 시행착오도 숨어있겠구나라는 것도 생각하게 되었습니다. 자동화의 운영과 계획 관점에서 많이 배울 수 있었습니다 👍👍

 

다음은 포스팅은 마지막 발표 주제인 테스트 케이스 우선순위 선정 방법에 대한 주제로 포스팅해보겠습니다