Robot Framework - 테스트 자동화란

QA(Quality Assurance), 품질 보증을 위해 Product 개발 및 운영 모든 과정에서 프로세스 정립, 문서화 및 테스트 등 소프트웨어 품질을 보증하기 위한 활동을 하게 되는데, 다양한 활동 중 자주 실패하게 되는 영역 중 하나가 바로 Test Automation(테스트 자동화) 이라고 생각한다.

그동안의 테스트 자동화 시도와 실패 사례를 경험을 바탕으로, 과연 왜 테스트 자동화가 쉽지 않았으며, 어떤 도구가 도움이 될지 고민했던 내용을 정리해 본다.

테스트 자동화의 어려움

Hump of Pain

Hump of Pain, 즉 고통의 언덕 이라고 불러보자.

어떤 것이든 새로운 것을 시작하려면, 일정 기간의 험난한 언덕을 맞이하게 되고, 고통스럽게도 이 언덕을 넘어가기 위한 부단한 노력이 필요하게 된다. 특히 테스트 자동화하는 일은 이 고통의 언덕이 상당히 가혹한 편인 것 같다.

업무가 자동화 된다면, 당장에 커피 마실 시간도 좀더 생기고 일찍 퇴근할 수 있을것 같지만, 자동화 환경 구축부터 스크립트 작성등 고통의 언덕이 반드시 넘어가야만 그 효과를 어느정도 경험할 수 있게 될 것이다.

그동안 이 언덕을 넘지 못하고 포기 했거나, 넘었다고 생각 했으나 다시 이 언덕을 맞이 하고 좌절을 경험했던 주요한 원인은 아래와 같았다.

• 테스트 자동화를 위한 내재화된 역량 부족

  • 테스트 케이스 스크립트를 작성하는 역량 (UnitTest, Integration Test, Selenium 또는 Appium 에 대한 이해)
  • 스크립트 실행을 위한 pipeline과 Queue 구성
  • CI/CD 와 Integration 등

• Product의 변화가 너무 잦아서 테스트 케이스 스크립트 수정이 도저히 못 따라가는 경우

  • 테스트 케이스 스크립트를 작성을 위한 구조 설계가 초기부터 확장성 있게 모듈화 되어 있지 않은 경우
  • Product의 변화가 테스트 케이스 시나리오 까지 빠르게 연결되지 않는 프로세스의 문제 등

• Product 기획 부터 설계/개발/배포 까지의 모든 단계에서의 각 담당자간의 협업의 어려움

  • 전 직군의 테스트 자동화에 필요성이나 효과에 대한 이해 부족
  • QA 가 초기 기획부터 배포까지 전반적인 품질을 보장하기 위한 개입이 어려운 상황
  • 테스트 자동화에 대한 품질 거버넌스의 부재 등

이외에도, 테스트 자동화 적용 커버리지를 현실적인 수치로 잡지 않아 실패하거나, 너무 자동화에 집중하면 오히려 제약이 발생하는 영역이 늘어 효율을 더 떨어뜨리는 상황도 있을 수 있다.

Test Automation Pyramid

테스트 자동화는 소프트웨어 전반에 걸쳐 활용될 것이다. 전체 테스트 비중을 설명하고 있는 Test Automation Pyramid 이며, 3가지 Layer 로 설명하고 있다.

• E2E Testing - 10%, GUI 테스트로 실제 작동되는 화면에서 사용자 테스트 수행한다. 웹 어플리케이션의 경우 웹브라우저에서 직접 웹사이트를 열어서 테스트 하는 영역이 되겠다.

• Integrating & API Testing - 20%, Integrating Testing 으로 Unit Testing 을 마치고 개발자가 결합된 Feature 단위의 테스트를 수행한다. 작게는 하나의 API 를 호출하여 주요 기능을 테스트 하거나, 비즈니스 요구사항에 맞게 여러개의 API 를 호출 하여 정상 동작 여부를 확인한다.

• Unit Testing - 70%, 최소단위의 테스트로 개발자가 구현 함수나 모듈/컨포넌트 단위의 테스트를 수행한다.

전체 테스트 비중은 Unit Testing (70%) > Acceptance Testing (20%) > GUI Testing (10%) 이고, 당연히 최하단의 Unit Testing 에서 발견되는 결함일 수록 초지하는데 소요되는 비용이 가장 적을 것이다.

만약 이미 구축된 소프트웨어이고 자동화 테스트가 적용되지 않은 경우라면, UI 즉 E2E 테스트를 자동화 하는것이 전체적인 테스트 커버리지를 개선하는데 가장 빠른 방법이 될 것이다.

Our immediate problem was a huge, buggy legacy system where the presentation, business logic, and database layers were intertwined. The fastest way to get some automated regression test coverage was through the GUI

- Beautiful Testing , O’Reilly

그리고, 위에서 이야기 한 고통의 언덕(Hump of Pain) 이 가장 험난한 영역도 E2E Tests 라고 생각한다.

Unit Tests와 Integrating & API Tests는 QA 프로세스와 개발 가이드에 따라 개발 조직 위주로 겪어야 하는 고통이겠지만, 피라미드의 최상단 E2E Tests 는, 개발자가 아닌 테스트 전담 조직이나 기획자 등도 참여하게 될 것이기 때문에, 여러 조직과 직군이 고통의 언덕을 경험하게 될 것이다.

Unit Tests와 Integrating & API Tests는 기반 기술 구조에 따라 구현 방식이 상이할 수 밖에 없다. 이부분은 향후 모바일 앱 Unit Test 하는 방법에 대한 글을 작성해 볼 예정이다. 반면에, E2E Tests는 사용자 UI 를 보고 테스트 하는 영역이라 구현 기술에 독립적이고, 이번 글에서 다뤄 보려고 한다.

이제 과거의 과오를 뒤로하고, "테스트 자동화를 하느니, 차라리 수동 테스트(Manual Testiing) 하는게 효율적이다." 라는 말이 안나오도록 해봐야 겠다.

Test Automation Generation

오래전부터 다양한 방법으로 테스트 자동화를 시도했었고, 시대의 변화는 현재도 활발하게 진행 중이다.

Record & Playback

사용자는 녹화 기능을 실행한 후 웹브라우저에서 동작을 취하면, 동작이 레코딩 되면서 자동으로 스크립트가 작성되는 방식이다. 대표적인 도구들은 Web 기반의 E2E 도구인 Selenium IDE 와 모바일 앱 E2E 도구인 Appium IDE 가 있고, 대부분의 RPA 솔루션 역시 이런 방식으로 동작한다.

이런 도구 들은 웹 사이트의 Web Element 를 자동으로 인식하여 Script 를 생성해 주는 방식이고, 이렇게 자동으로 작성된 Script 를 회기실행 하게 되면 테스트 자동화가 되는 것이다.

얼마나 손쉬운 테스트 자동화 방법인가? 처음에는 신세계를 경험한 것 처럼 눈이 번쩍 뜨이는 것 같지만, 시간이 지날 수록 점점 많아지는 테스트 케이스로 인해 Script는 계속 증가하게 될 것이고, 수시로 변화 하는 어플리케이션이기 때문에 여기저기 다시 녹화 해서 Script를 만들어야만 하는 상황이 많이 발생하게 된다.

심지어 만약 수많은 테스트 Script 에서 실행되는 공통 영역이 변경되면, "테스트 자동화했지만 계속 다시 녹화해야 하니, 차라리 수동 테스트(Manual Testing) 하는게 효율적이다." 라는 말이 나올수도 있겠다.

Use & Reuse of functions

점점 많아 지는 테스트 케이스에서 반복해서 동작해야 하는 영역들을 모듈화 하여 재사용 가능하게 하는 것으로 Modular Driven Approach 라고도 한다.

앞의 Record & Playback 의 경우 녹화만 하면 자동으로 만들어지는 Script 를 수정해야 하는 경우는 극히 드물었지만, 이 단계 부터는 테스트 Script 를 직접 손을 대야만 하는 상황이 발생하게 된다.

그리고, Record & Playback 방식과 혼용되면, 자동으로 생성되는 영역과 테스트 스크립트를 수정하여 모듈화 해야 하는 영역의 혼용되어 일관되지 않은 테스트 스크립트 생성 과정에 혼선이 많이 발생해본 경험도 있다.

Data Driven Scripts

테스트 Script의 실행 로직에서 테스트 데이터를 텍스트 파일, Excel, CSV, DBMS 등 외부 저장소에 분리하는 것이다.

다양한 테스트 데이터 세트로 동일한 테스트 로직을 실행해야 하는 경우 큰 효과를 볼 것이고, 테스트 Script 에 테스트 데이터가 하드코딩되어 들어가지 않는 유지 관리하고 수정하기 용이하다.

그리고 복수의 데이터 세트를 조합하여 테스트 케이스를 실행하는 Pairwise Testing (Combinatorial Test Case Generation) 에도 활용되어 품질을 높이는데 효과 적이다.

Pairwise Testing - A black-box test design technique in which test cases are designed to execute all possible discrete combinations of each pair of input parameters.

- ISTQB Glossary

다만, 숙련된 테스터이거나 개발자가 참여하지 않으면 환경을 구축하거나 스크립트를 작성하는데 어려움이 발생할 수 있겠다.

Action Keyword Scripts

테스트 Script 는 테스트 환경에 맞는 개발언어로 작성해야 한다. Selenium 의 경우 훌륭하게도 Python, Java, Javascript 그리고 C# 등 다양한 언어로 작성이 가능하기도 하다.

Keyword-Driven Approach 라고도 하는 Action Keyword Scripts 는 테스트 Script 를 자연어 형태로 표현된 미리 정의되어 모듈화된 스크립트를 호출하도록 하는 방식이다.

결국 개발 언어로 작성해야 해서 개발 역량이 필요한 기존의 방식과 다르게, 처음 접하는 사람도 이해 할 수 있는 자연어 기반으로 작성할 수 있도록 하는 것이다.

Robot Framework 는 대표적인 Keyword 기반의 Automation Framework 이며, 테스트 자동화와 RPA에 주로 사용되고 있다.

Robot Framework has an easy syntax, utilizing human-readable keywords. Its capabilities can be extended by libraries implemented with Python, Java or many other programming languages. Robot Framework has a rich ecosystem around it, consisting of libraries and tools that are developed as separate projects.

- Robot Framework Official Site

Scriptless Automation

Machine Learning 을 통해 앱 사용을 학습하고, 이를 기반으로 AI 엔진이 직접 테스트 하는 방식으로 동작 한다. 최근에 이 분야에 기업의 관심이 커지고 있고, 나 역시 관련된 업체들과 PoC 해보기도 했다.

사람이 찾기 쉽지 않은, 하지만 아주 Critical 한 예외 케이스를 발견할 수도 있다.

하지만, 모든 테스트 케이스를 테스트 하는 것을 보장할 수 없기에, 부가적으로 필요한 테스트 기법이 아닌가 하는 생각도 해본다. 즉, 테스트 케이스 기반으로 작성된 테스트 Script 들과 AI Tests 가 같이 적용 된다면 보다 품질 높은 Product 를 서비스 할 수 있지 않을까?

그래서,

성공적인 테스트 자동화를 위해 위에서 언급한 재사용 가능한 모듈화, 테스트 데이터 분리, 키워드 기반의 스크립트 작성 모두가 고려된 Robot Framework 를 선택해 본다.

녹화 해서 자동으로 만들어 지는 Record & Playback 방식으로는 계속 증가하게 될 테스트 케이스와 수시로 수정해야 하는 상황을 대응하기 어렵다고 판단하게 되었다.

이외에도, 반드시 고려해야 하는 Page Object Model 과 같은 테스트 스크립트 구조 설계와 CI/CD 연계 Pipeline 등은 이어 설명할 예정이다.

도구만 좋다고 품질을 확보 할 수 있는 것은 결코 불가능한 일이다. 조직내 품질 확보를 위한 프로스세와 문화가 기반이 되어야 하는 것은 당연한 일이다.

다음 글에서는 본격적으로 Robot Framework 에 대해 알아보자.

부디 이번에는 고통의 언덕을 잘 넘어가 휘파람 불며 한가롭게 평지를 걸을 수 있기를 바래본다.