5시간 작업을 5분으로

안녕하세요, 사장님들의 주문처리를 위한 Windows Application 개발, 운영 및 보수를 하고 있는 장정환입니다.
이번 글은 사용자와 상호작용하는 Front-end의 검증 간 활용 가능한 ‘UI 자동화 Test 도입 배경’과 ‘준비 과정의 경험’을 공유코자 작성하였습니다.

상세한 내용에 앞서 이번 글에 관해 미리 알아두면 좋은 내용 간단히 먼저 공유드립니다.

• 이 글은 개발자만이 수행하는 Unit-test, Intergrated-test 외에 사용자와 상호작용하는 UX/UI에 관한 테스트의 자동화를 이야기합니다. 전체적인 논의 또는 문맥상의 이해를 위한 인용을 포함하나 설명하지는 않습니다.
• 사장님향 주문접수채널 (iOS, Android, Windows) App은 배달의민족 App (iOS, Android)에서 발생된 주문의 수신 및 접수/거절/취소/완료/배차 등을 기능을 제공, 사장님께 주문 전달 및 편의 제공을 위한 프로그램입니다.
• 주문접수채널 서비스팀의 소개는 본 링크를 참고해 주세요.

문제 배경

저희는 2개의 Windows 사장님향 주문접수 프로그램을 개발/운영하고 있습니다.

• PC주문 접수: 2016년도 현재까지 5년간 운영 중
• 배민주문접수PC: 2019년 ~ 현재까지 3년간 운영 중

5년이라는 운용 기간은 변화의 수용하는 과정이었으며, 조금씩 조금씩 개발/검증 비용이 누적되었습니다.
수용했던 변화를 요약하면 목록과 같습니다:

• 우아한형제들의 사업 변화
• 사장님 운용환경(Windows XP ~ Windows11)의 변화 수용
• 그로 인한,
  • 새 기능 추가, 기존 기능의 개선
  • Back-end의 변화 수용

이로 인한 비용(개발 인력/시간)의 증가는

• 성급한 영향 범위 파악
• 작은 실수/버그의 누적으로 이어지고,

결과적으로 Hotfix 배포 빈도 증가를 불러왔습니다. 이로써 2가지 큰 문제가 드러났습니다.

• 우리가 만든 프로그램이 사장님 사업의 장애를 유발할 것 같은 불안과 걱정
• 개발 파트의 낮아진 자존감에 의한
  • 개별 개발자의 의욕/자신감 하락
  • 팀 내 적극적인 의사소통 빈도 감소

문제 진단 및 이룰 수 있는 성취: 자동화된 UI 테스트 도입을 고민

사실 제품 개발 중단 없이 시장의 변화를 수용해가며, 사용자의 증가, 그리고 조직의 비즈니스가 구현된 우리 제품을 운용하는 것은 개발자에게 큰 행운입니다. 개발만 잘해서는 결코 이룩할 수 없는 부분이기도 합니다.
때문에 해결 가능한 문제와 해결이 어려운 문제를 분류하고 문제 해결을 위한 가설과 방안을 이 검토되었습니다.

해결 가능한 문제와 그렇지 않은 문제

해결할 수 없는 문제

• 완벽한 기획은 있을 수 없고,
• 버그 없는 완벽한 개발은 불가능하며,
• 제품의 무결함을 보장하는 QA는 존재하지 않는다.

해결 가능한 문제

사장님의 상호작용 UX/UI 및 비즈니스 시나리오의 검증은

1. 기획 간에는 기획자가 판단한 영향 범위로 한정되고,
2. 개발 간에는 개발자의 판단 범위로 한정되며,
3. 배포 전에는 QA팀 의존적이며, Test-Case의 수행 범위에 한정된다. 이때 1회 수행 비용(시간+인력)이 매우 비싸다.

해결 가능한 문제 목록

• 기획자/개발자가 판단한 범위를 회귀 검증 시 기획자/개발자의 판단 범위 확대를 통해 안전성을 도모한다.
• QA 간 수행 비용을 감소를 통해 TC 고도화 및 탐색적 테스트 수행시간을 늘린다.

문제 해결은 다음의 성취를 이룰 수 있다는 가설을 수립 후, 자동화 테스트 도입을 준비하였습니다.

이룰 수 있는 성취

• 안전성 확보
  • 자동화 도구의 도입으로 기 개발된 기능 + 개/보수된 기능을 빠르게 테스트하고, 개발 단계에서 문제에 대응할 수 있다.
  • QA 간 탐색적 테스트 기회 ↑
  • 개발 간 반복적 UI 테스트 기회 ↑
• 결론적으로, 개발 간 사장님 요구 수용 기회 ↑

자동화된 UI Test 비용

자동화된 UI Test 도입의 당위는 비용(인력, 시간) 측면의 두 가지 이점을 꼽아, 후술하는 도표를 근거 삼어 논의 후 진행하였습니다.

• Test 행위별 수행 시간 감소 ↓
• Test 행위별 수행 빈도 ↑

Test 행위별 수행 시간

⇒ 기존 UI 테스트는 1회 수행 비용이 크다.
이는, 컴퓨터(자동화)가 아닌 사람이 작성한 TC 수행 → 평가 → 보고 과정이 전부 수작업 으로 이루어지기 때문입니다.

Test 행위별 수행 빈도 (Worst case)

⇒ (최악의 경우이기는 하지만) 개발 마지막 단계 출시 전 사람에 의한 반복적 QA 테스트는 그 비용이 가장 비쌀 수밖에 없다.
⇒ (기능의 복잡도, 구현 범위, 일정등의 현실 상황에서) 종종 회귀검증은 불가하였으며, 아이스 크림콘과 같이 서로 분리된 단위의 테스트만이 수행된다.

가능성을 확인

Windows Application UI Test Automation 으로 google을 검색하면 상단에 2개의 상용도구가 검색됩니다.

• Smartbear 사의 Test-Complete
• Ranorex 사의 Ranorex Studio

Ranorex사의 Ranorex Studio를 선택

두 제품 모두 기능의 큰 차이 없이 자동화된 UI테스트 작성을 제공합니다. Test-Complete는 시장에서 오랜 기간 검증되고 사용되었던 제품으로 개발 간 JavaScript, Python, Delphi-script, VB 등의 다양한 스크립트 언어를 사용, 정교한 확장이 편리한 반면 비 개발직군이 테스트를 구성하는 편의 나 UX는 조금 부족하다는 판단하에, Ranorex studio를 선택하였습니다. Ranorex 역시 녹화된 테스트의 수행 외에, C#으로 그 기능을 확장하여 테스트를 확장할 수 있습니다. 비 개발직군의 사용성에 좀 더 편리성이 있다고 판단하였습니다.

구매 준비

먼저, 해당 제품의 실용성과, 가능성 실험을 위해, Ranorex사에서 제공되는 30일 체험판으로, 간단한 테스트 데모를 작성,
구매의 당위와 진단된 문제의 극복 가능함 조직과 함께 논의하였습니다.

추가 도구 구현 – Mocking 배민App의 작성

자동화 가능한 Test-case는 사람이 개입되지 않아야 합니다. 예를 들어 프린터 인쇄물의 검증 또는 휴대전화로부터 수신된 SMS 인증번호 입력과 같은 작업자가 필요하다면 자동화할 수 없습니다.

다만, 자동화된 테스트 구현의 중요한 목적은, 사용자의 주문데이터를 사장님께 전달하는 것인데, 이 또한, 현재 테스트가 불가능합니다.

• 주문접수채널 App은 스스로 주문을 만들 수 없습니다. 오직, 배달의민족 App(iOS, Android)을 통해 생성된 주문이 있어야 합니다.

자동화된 주문 생성 도구의 작성

배달의민족 App의 사용 API는 여러 부서로 협력 구성되었으며, Swagger 형태의 문서를 제공하고 있습니다. 다행히도, 이에, Windows 환경에서 주문을 생성 가능한 Mocking App을 개발하여, UI Test에 주문 생성과정을 포함하기로 하였습니다.

작성된 시나리오

1. (사전에) 테스트에 필요한 가계는 찜한가계(즐겨찾기)에 등록한다.
2. Mocking App에서 찜한 가계를 로드한다.
3. 배달의민족 App(iOS, Android)에 제공하는 주문생성의 기능을 수행한다.

시나리오를 구현한 테스트 도구

개발 간 염두에 둔 것들

• 주문접수 App은 Windows 8 이상의 환경을 지원하지만 일부 사장님 환경에서 Windows XP를 포함하기에 테스트에 이를 포함하기로 하였습니다.
• Windows는 HTTP Client 개발을 위한 WinHttpLib(see-MSDN)을 지원합니다. 해당 Lib는 Windows 7부터 사용이 가능하며, Windows XP에서는 몇 가지 제약이 존재합니다. (Windows XP의 경우 별도 업데이트를 통해 지원이 가능하지만 2021년은 이미 공식적으로 Window XP 업데이트는 지원되지 않습니다.)
• 때문에
• Windows XP 환경에서는 Indy Lib(TCP/IP 수준에서 HTTP Client가 구현된 Delphi Component) + OPEN SSL을
• Windows 7 이상 환경에서는 THttpClient(WinHttpLib를 감싸고 있는 Delphi Component)를 사용하기로 하고, 다음과 같이 구현하였습니다.

자동화 테스트 결과를 전파하기

Ranorex Studio + Mocking App을 전파하기

UI Test 자동화의 도입과 평가는 전문 QA팀 없이는 불가능합니다. 성공적인 안착을 위해,

• 작업의 시작/진행을 공유하고,
• 자동화된 UI 테스트 도입으로 확보 가능한 알파(시간, 인력 등의 자원)에 대해 서로의 눈높이를 지속적으로 맞추며 테스트 도구에 대한 피드를 확보하였습니다.
• Pit-Stop(우아한형제들의 년 1회, 전사 참여, 쌓아놓은 부채 청산을 위한 2주의 시간)을 통해 이를 전파하였습니다.
  • 테스트 도구 완료 후, 전문화된 Test-case 확보 및 활용을 위한 학습자료(테스트 도구 및 Ranorex Studio)를 공유하였으며
  • 3일 동안 일일 5시간 동안 Online 대기로 실시간 Feed 하였습니다. Test-case 작성자는 이를 통해 기술적에 대해 빠르게 해결하고, Test-case를 축적하였습니다.
• 향후 진행 계획을 함께 고민하여, 현재까지의 진행을 포함하여 3단계로 구분하였습니다.

자동화 테스트의 도입을 앞두며

성과: 5시간 → 5분

QA팀은

• 새로운 기능의 검증은
  • QA작업자가 직접 Test-case를 작성하고, 테스트를 수행하는 기존과 동일한 과정으로 수행됩니다.
• 기존 기능의 검증은
  • 회귀적 자동화된 UI Test 도입
  • QA작업자 1인 기준, 검증비용은 5시간 → 5분으로 줄었습니다.

개발팀은

• 기 작성된 기능의 자동화된 회귀적 검증 절차를 확보하였습니다.

문서의 마지막에 자동화 UI TEST 도구 도입을 지원해 주시고, 바쁜 시간을 쪼개어, 같이 작업해 주신 이한샘님의 회고 일부를 인용하였습니다.

진행 및 향후 계획

Phase 1 (완료)

• 배민주문접수의 주문 타입 3개의 반영률 95% 자동화
• 배민주문접수 프로그램의 기본 기능 자동화
• 주문접수PC 프로그램의 주문타입 (배민배달, 배민포장, 배민매장) 자동화
• 주문접수 PC 프로그램의 전반적인 기본 기능 자동화

Phase 2 (예정)

• Git을 통한 Test-case 협업(QA팀, 주문접수채널서비스팀)
• CI/CD에 Ranorex Studio를 연동하기

Phase 3 (예정)

• Test Case 추가 확보
• 배달/포장/매장, 배민/배민1/배라를 포함하는 Test-Case 확보 및 도입

QA작업자의 회고

성과

작업 기간

• Ranorex 가이드 교육 : 8월10~ 8월11일 (1.5일 소요)
• UI자동화 테스트 작업: 8월12일 ~ 8월19일 (3일 소요) *Ranorex license 이슈 1.5일 소요 제외

주문타입	전체TC	자동화 반영 TC	자동화 반영률
배민 배달	106개	72개	67%
배민 포장	131개	44개	34.5%
배민 매장	113개	45개	39%

• 배민주문접수의 3개의 주문타입 pilot – Test 기준 예정되었던 정상 범위 내용은 반영은 완료(주문이 들어온 시점으로 부터, 접수 > 처리 > 완료 기준의 UI 테스트 시나리오를 돌릴 수 있어야 하며, 정상적으로 한 Cycle이 돌아야 하는 기준)
• 주문타입별로 반영률이 다른 부분은 TC케이스에 들어갈 자동화 항목에 대한 체크를 주문타입별로 따로 정의하지 않았기에 차이가 발생
• 작업 기간 내에 주문을 생성할 수 있는 목업프로그램 서버 이슈로 인한, 주문 처리 불가 시나리오가 전체적으로 돌아가지 못한 부분도 발생하여 제약 발생
• UI 자동화 테스트 작업 기간 내에 Ranorex Studio Lisence 문제로 인하여 1.5일 진행하지 못한 일정이 소요되었음

도입배경

1. 안정적이고, 변경점이 크게 없는 기능 중 반복적 TestCase의 내용을 UI자동화 테스트로 대체하면 살충제 패러독스를 해소할 수 있지 않을까?
2. UI자동화 테스트로 대체해 주는 수행 비용을 줄이고, 새로 배포된 기능 테스트에 좀 더 집중할 수 있지 않을까?(탐색적 테스트 포함)
3. 자동화테스트에 관심이 많았고, 이번 작업을 통해 QA 관점에서 UI자동화가 어느 정도의 효율성이 있는지 측정을 해보고 싶었습니다.

작업순서

1. 기능 변경이 적은 케이스
2. 영향도가 높은 케이스
3. 시나리오 도출 이후, 유사한 케이스에 적용할 수 있어 활용도가 높은 케이스

회고(느낀점)

이번 UI 자동화 테스트를 진행하면서 좋은 프로그램(비싼)을 통해 UI 테스트에 대한 경험치를 얻었다고 생각합니다.

배민주문접수채널에 UI 테스트 시나리오를 진행하면서 느꼈던 점은 UI 테스트 자동화도 충분히 효율적일 수 있다입니다. (단 아래의 조건들이 충족이 되어야 합니다.)

• UI 테스트를 준비하기 전 기존 테스트 항목을 시나리오에 어떻게 분류하고 나눌 것인지 충분한 고민이 필요함을 느꼈고, 분류하지 않고 원스텝으로 작업을 진행하게 되면 이후 유지보수 차원에서도 더 많은 시간과 비용을 지불할 것으로 생각됩니다. 결국 다시 회귀하여 수동 테스트를 진행할 수 있다고 느꼈습니다.
• 꾸준한 유지보수가 필요함을 느꼈습니다. 실제로 작성한 시나리오 동작이 실패로 떨어지는 상황이 있었는데요. 이는 주문접수 프로그램이 업데이트가 되면서 UI상으로는 변경이 없었으나, 주문접수 프로그램 내부의 Element 변경으로 실패가 되어 기 반영된 시나리오가 동작하지 않았던 상황이었습니다. 이는 체계적인 CI/CD 자동화를 통하여 지속적인 유지보수가 필요함을 느꼈습니다.
• 초기 공격적인 UI 테스트 자동화 작업을 진행해야만 안정적으로 자동화가 될 수 있다고 느꼈습니다. 애매한 일정과 인력이 되면 오히려 두 벌씩(기능TC, 자동화TC 등) 작업하게 되는 결과를 만들 수 있다고 느꼈습니다. (초기 투입 인력이 어느 정도 필요함)
• 개발자, QA엔지니어 간 충분한 커뮤니케이션 및 협업이 있어야 한다고 생각합니다. (당연한 이야기…) 개발자가 지원해 줄 수 있는 영역, QA엔지니어로써 지원해 줄 수 있는 영역에서 서로 도움을 충분히 받고, 구축한다면 저는 UI 자동화 테스트가 충분히 효율적으로 돌아갈 수 있다고 생각합니다.

감사인사

🙏 바쁜 시간에 자동화된 UI 테스트 도구 도입을 위해 지원해 주신 품질개발팀, 회원인증파트 구성원분들께 고맙다는 인사를 전합니다.

♥ 고맙습니다. ♥ 도와주신 덕분에 사장님께 조금 더 좋은 환경을 제공할 수 있게 되었습니다.

🙏 자동화된 UI 회귀테스트의 도입에는 개발팀은 그 시작에 발을 같이 올렸을 뿐, 이후 Test-case의 확보 및 구현, 향후 확대까지 품질개발팀의 도움이 꼭 필요했습니다. 시작부터 고민해 주시고, 주도적으로 업무를 이끌어 주신 품질개발팀과 이한샘님께도 인사를 드립니다.

고맙습니다. ㅠ_ㅠ 앞으로도 잘 부탁드리며, 제가 할 수 있는 일은 언제든 이야기 주시면 저도 도와보겠습니다.

🙏 팀 내부적으로는 첫 번째 도입 실패 후 두 번 만에 성공할 수 있었습니다.

그 길었던 시간의 실패를 넘어 재 도전 가능한 팀문화, 실패한 실험적 프로젝트를 다시 도전할 수 있게 도움 주신 우리팀 고맙습니다. ㅠ_ㅠ