내가 재직 중인 Myrealtrip TQA 팀은 매주 금요일 1시간씩 팀 스터디 세션을 갖고 있다.
팀 스터디 세션에서 UI 자동화에 대한 내 생각을 전할 기회가 있어 발표했던 자료를 재정리해 보았다.
PPT를 마크다운으로 옮기다 보니 어색한 부분이 많이 있는 듯..
UI 자동화 테스트에 대한 고찰
오늘은 UI 자동화 테스트 그리고 UI 테스트에 대한 제 개인적인 견해에 대해 짧게 이야기해 보려고 합니다.
개발 프로세스에 정답이 없듯이 주관적인 생각이 많이 반영되어 있으니까 ‘아 이렇게 생각하는 사람도 있구나’라고 참고만 해주시면 좋을 것 같습니다.
UI란 무엇인가?
UI 자동화 테스트에 대해 이야기하기 전에 UI가 무엇인지 이해할 필요가 있습니다.
UI는 사용자 인터페이스의 약자이고 사용자는 UI를 통해 우리 서비스와 인터렉션 하게 됩니다. 따라서 UI는 앱 또는 웹 애플리케이션에서 가장 중요한 구성 요소라고 볼 수 있습니다.
UI 매뉴얼 테스트, UI 자동화 테스트는 무엇인가?
일반적으로 UI 매뉴얼 테스트 프로세스는 각 버튼의 기능, 입력 필드 밸리데이션, UI 워크 플로 등을 수동으로 테스트하는 것을 의미합니다.
그리고 UI 자동화 테스트는 자동화 테스트 프레임워크, 라이브러리 등을 활용해서 앞서 언급한 UI 매뉴얼 테스트 프로세스를 자동화하는 것을 의미합니다.
그럼 여기서 “매뉴얼 테스트, 자동화 테스트 결국엔 둘 다 UI 테스트하는 거 아니야? 굳이 자동화를 해야 하나?”라는 의문점이 생길 수 있습니다. 매뉴얼 테스트는 몇 가지 치명적인 단점을 가지고 있습니다.
UI 매뉴얼 테스트의 단점
- (1) 테스트 실행 속도
- (2) 인적 자원
- (3) 테스트 불안정성
- (4) 비용
첫 번째로 테스트 실행 속도가 느립니다. 매뉴얼 테스트는 예상하는 시나리오대로 인력이 투입되어야 하고 A부터 Z까지 모두 사람이 직접 수행해야 합니다.
두 번째로 인적 자원이 많이 투입됩니다. 테스트할 기능이 많다면 테스터 한 명으로는 부족하기 때문에 많은 사람이 투입되어야 합니다.
세 번째로 테스트 불안정성입니다. 매뉴얼 테스트는 사람이 하는 일이다 보니 휴면 에러에 대한 리스크가 있습니다.
마지막으로 비용입니다. 일반적으로 매뉴얼 테스트는 1회 수행 비용이 매우 크게 발생합니다. 가장 큰 이유는 위에 언급한 내용처럼 속도가 느리고, 느린 만큼 많은 인력이 투입되어야 하고, 사람이 직접 TC 수행 → 보고서 작성 등 테스트 프로세스 전반적인 과정을 수작업으로 진행하기 때문입니다.
어? 그럼 UI 자동화하면 다 해결되겠네?우리 자동화 구축하자!
자동화 테스트 프로세스를 구축하면 매뉴얼 테스트의 단점을 모두 보완할 수 있을 것 같지만 현실은 그렇지 않습니다. 자동화 테스트도 많은 단점을 가지고 있습니다.
UI 자동화 테스트의 단점
매뉴얼 테스트만큼이나 자동화 테스트도 많은 단점을 가지고 있습니다.
- (1) 테스트 환경의 다양성을 커버하기 힘듦
- (2) 초기 투자 비용
- (3) 유지 보수
자동화 테스트의 첫 번째 단점은 테스트 환경의 다양성을 모두 커버하기 어렵습니다. 웹, 모바일웹, iOS, Android 등 다양한 운영 체제와 플랫폼에서 UI 자동화 테스트를 최적화하는 것은 매우 어려운 일입니다.
두 번째로 초기 투자 비용입니다. 장기적인 관점에서 자동화 테스트가 초기 투자 비용 대비 막대한 이익을 가져다준다고 하더라도, 자동화 테스트는 초기에 구축 과정에 있어 매우 많은 시간과 인력을 필요로 합니다.
세 번째로 유지 보수입니다. 작성된 테스트 스크립트는 프로덕트 변화에 맞춰 끊임없이 유지 보수 비용이 발생합니다. 또한 어느 시점부터는 자동화 테스트의 효율성보다 테스트 스크립트 유지 보수 비용이 더 많이 투입되는 시점에 직면하게 됩니다.
이처럼 매뉴얼 테스트든 자동화 테스트든 각기 치명적인 단점들이 존재합니다. 따라서 자동화 테스트 도입에 있어서는 ‘자동화 테스트가 왜 우리 조직에 필요한지;’, ‘자동화 테스트를 도입하면 프로덕트 품질에 얼마나 도움이 되는지’ , ‘자동화 테스트의 커버리지는 어디서부터 어디까지 설정해야 할지’ 등 매우 신중하고 면밀한 검토가 필요하다고 생각합니다.
내가 생각하는 UI 자동화 테스트는?
저는 사실 UI 자동화 테스트에 굉장히 회의적인 사람 중 한 명입니다.
UI 자동화 테스트는 빠르게 변화하는 프로덕트에서는 테스트 스크립트 유지 보수 비용이 많이 들고 A/B 테스트라든지 여러 가지 변수에 취약할 수밖에 없습니다. 따라서 저는 UI 자동화 테스트가 필요하다면 정말 최소한의 영역, 이를테면 CSP 정도까지만 자동화하고 그 외 다른 영역은 불필요하다고 생각합니다.
게다가 UI 자동화 테스트는 대부분이 엘리먼트의 존재를 식별하고 UI 시나리오 기반으로 Assertion을 가져가기 때문에 UI 자동화 테스트로 거를 수 있는 이슈보다 거를 수 없는 이슈가 더 많다고 생각합니다.
그럼에도 불구하고 우리가 UI 자동화 테스트 도입에 대해 고민하는 이유는 명확합니다.
- (1) 빠르고 정확한 테스트 결과 제공
- (2) 반복적인 UI 테스트 수행
- (3) QA Engineer의 탐색적 테스트 시간 확보
UI 자동화 테스트는 빠르고 정확한 테스트 결과를 제공합니다. 그리고 테스트 병렬 수행을 통해 여러 테스트케이스, 여러 플랫폼을 동시에 테스트할 수 있습니다. 또한 인적 자원이 투입되지 않아도 여러 차례 반복 테스트 수행이 가능합니다. 이 점은 잦은 배포 상황에서 매우 큰 장점으로 다가올 수 있습니다. 마지막으로 QA 엔지니어의 탐색적 테스트 시간을 확보할 수 있습니다. UI 자동화 테스트를 통해 확보한 커버리지와 시간 그리고 인적 자원을 탐색적 테스팅에 투자함으로써 테스트 커버리지를 높이고 품질 향상에 기여할 수 있습니다.
그럼 우리는 어떻게 UI 테스트에 접근해야 할까요?
이 그림은 SW 공학에 관심이 있다면 한 번쯤 보셨을 법한데, 애자일 스크럼 방법론 창시에 기여한 마이크 콘이라는 아저씨의 책에서 처음 소개된 피라미드 테스팅 패턴입니다. 피라미드 하단부는 소스코드 영역이고 피라미드 상단부에 가까울수록 유저가 사용하는 영역 즉, UI 영역이라고 보시면 됩니다.
그림에서 보시다시피 소스코드단에서 수행하는 유닛 테스트는 테스트 실행 시간, 비용, 복잡도가 가장 낮습니다. 그리고 사용자 영역인 UI 단까지 올라올수록 실행 시간, 비용 복잡도가 증가합니다.
이 피라미드 테스팅 패턴은 단위 테스트의 중요성을 매우 매우 강조하고 있습니다. 피라미드 테스팅 패턴은 전체 테스트 절대량이 100% 라면 무려 70%는 단위 테스트에서 수행되어야 한다고 이야기합니다.
그 이유는 조금 전에 설명한 내용처럼 공수 대비 가장 큰 효과가 있기 때문입니다.
단위 테스트에서 테스트 수행이 완료되었다면 나머지 20%는 서비스 레이어에서 테스트를 수행하게 되고 마지막 10%는 사용자 영역 즉 UI 테스트를 수행하는 것이 피라미드 테스팅 패턴의 이론입니다.
이상적인 방향이라면 우리는 단 10%의 비중만 UI 테스트에 투입해야 합니다. 그러나 현재 우리는 어떻게 일하고 있을까요?
슬프지만 저는 현재 이게 우리가 일하고 있는 방식이라고 생각합니다. 이 그림은 아이스크림콘 패턴이라고 불리는 안티 테스팅 패턴입니다.
우리는 테스트 실행 시간, 비용, 복잡도가 가장 많이 들어가는 단계에서 테스트 업무를 수행하고 있습니다. 또한 우리는 UI 테스트에 과하게 의존하고 있고 자동화된 시스템이 부족합니다.
따라서 저는 우리가 UI 자동화 테스트를 도입하기 이전에 서비스 레이어에서의 API 테스트가 충분히 이루어져야 한다고 생각하고, API 테스트가 충분히 수행되었다는 전제하에 비로소 UI 자동화 테스트가 의미를 갖는다고 생각합니다.
UI 자동화 테스트만 도입한다면 어떤 문제점이 있을까요?
왼쪽의 서비스 화면은 숙소 상품을 구매하는 과정 중 일부입니다. 서비스 화면 상에서는 어떠한 문제점도 식별할 수 없습니다. 그러나 개발자 도구를 열어보면 실제 이 화면에서는 자동완성 API의 응답이 500으로 내려오고 있습니다.
UI 자동화 테스트에서는 API 응답에 대한 문제점을 식별할 수 없기에 테스트 결과를 PASS로 리포팅할 것이고, UI 자동화 테스트의 결과만 믿고 운영 배포를 진행했다가는 장애가 발생되게 됩니다. 이렇듯 UI 자동화 테스트는 API 테스트가 동반되지 않는다면 반쪽짜리 테스트에 불과합니다.
이제 왜 UI 자동화 테스트가 반드시 API 테스트와 함께 수행되어야 하는지 어느 정도 공감하실 수 있나요?
그럼 여기서 또 한 가지 의문점이 생길 수 있습니다.
저는 API 테스트 안 할 건데 그럼 UI 자동화 테스트는 구축하나 마나겠네요?
그렇지 않습니다.
먼저 기본적인 UI 자동화 테스트의 흐름을 살펴보겠습니다. 테스트 케이스 즉 테스트 스크립트가 있고 이를 실행하는 테스트 러너가 있습니다. 그리고 테스트가 종료되면 결과 보고서를 생성하게 됩니다.
그리고 이 그림은 제가 제안하는 UI 자동화 테스트의 흐름입니다. 테스트 스크립트가 실행되기 전에 프록시 서버를 하나 띄우고 네트워크 패킷을 캡처하기 시작합니다.
그리고 테스트 스크립트가 종료되면 네트워크 패킷 캡처와 서버를 중지합니다. 프락시 서버를 통해 UI 자동화 테스트 스크립트가 실행되며 주고받았던 HTTP/S 요청들을 모두 캡처할 수 있고 응답 코드가 400 또는 500 인 요청들에 대해 필터 할 수 있습니다.
이렇게 프락시 서버를 활용하면 API 테스트를 직접 수행하진 않았지만 UI 자동화 테스트를 수행하며 클라이언트에서 호출한 HTTP/S 요청에 대해 간접적으로 검증할 수 있습니다.
이미지 리소스를 받아오는 것들도 모두 HTTP 요청들이기 때문에 화면 상의 사소한 이슈들도 필터 할 수 있겠죠?
이건 프록시서버가 적용되지 않은 간단한 샘플 코드인데요,
이 setup_basic이라는 메서드는 테스트 케이스가 실행되기 이전의 사전 작업, 그리고 테스트 케이스가 종료된 후의 사후 작업을 정의한 메서드입니다.
빨간 박스의 10번부터 12번 로우는 테스트 케이스 사전 작업에 대한 코드이고 파란 박스는 테스트 케이스 사후 작업에 대한 코드입니다. 즉 빨간 박스는 파이썬의 유닛 테스트 기준으로는 Setup 메서드, 자바의 Junit 기준으로는 BeforeAll 어노테이션입니다.
파란 박스는 파이썬의 유닛 테스트 기준으로는 TearDown 메서드, 자바의 Junit 기준으로는 AfterAll 어노테이션입니다. 사전 작업에서는 크롬 드라이버를 인스톨해주고 있고요, 사후 작업에서는 실행한 드라이버를 종료해 주고 있습니다.
그럼 프록시서버가 적용된 코드를 한번 살펴볼까요?
이전 코드와 비교해 보면 크게 3가지가 달라졌습니다.
첫 번째로 프록시 서버 관련된 코드인데요, 저는 데모를 위해서 browsermob-porxy 라는 녀석을 서버로 활용했고, 관련된 코드는 10번부터 13번 로우입니다.
두 번째로는 브라우저에서 프락시 서버를 거칠 수 있도록 크롬 드라이버 옵션을 설정해 주었습니다.
마지막으로 가장 중요한 HTTP 아카이브 파일 생성인데요 23번 로우를 보시면 HTTP 아카이브 파일을 생성한 것을 볼 수 있습니다.
이렇게 프록시 서버를 활용하면 UI 자동화 테스트만 실행했음에도 HTTP/S 응답에 대해 간접적으로 검증할 수 있습니다. 이 결과값을 토대로 HTTP 응답 코드가 400, 500인 요청들에 대해서 필터하고 별도 리포팅도 할 수 있습니다.
꼭 프록시 서버를 사용하지 않아도 Selenium에서 파생된 다른 라이브러리를 활용해도 HTTP/S에 대한 검증이 가능합니다. 예를 들면 Selenium-wire 라이브러리가 있습니다.
소프트웨어 공학에 있어서 Silver Bullet은 없다.
소프트웨어 공학에 있어서 Silver Bullet은 없다.
어떤 툴, 어떤 활동을 적용하더라도 그 하나만으로는 모든 것이 해결되지 않는다.
여기까지가 제가 준비한 발표 자료인데요, 제가 소프트웨어 엔지니어로서 살아오며 항상 마음속에 새기고 있는 문장을 넣었습니다.
어떤 툴, 어떤 활동을 적용하더라도 그 하나만으로는 모든 것이 해결되지 않습니다. 즉, 마스터키는 존재하지 않습니다. 열릴 듯 말 듯 한 수많은 열쇠만 존재하는 거죠.
그러나 이런 고민과 노력이 지속되면 분명 현재보다 더 나은 프로세스, 더 나은 품질 확보가 가능하리라 믿고 있습니다.
