The edge of the pyramid
모든 회사가 동일한 테스팅 피라미드(Unit test/Component test/End2End test)을가져야 할까요? 스포츠 디바이스 업체 Leomo의 Elena Alejo는 그렇지 않다고 이야기합니다. 왜일까요?
Ice cream anti-pattern
여러분의 회사의 테스팅 문화가 아이스크림 패턴이라면 이것은 좋지 않은 신호입니다. 여러가지 증상으로 이 패턴을 감지할 수 있습니다. 아래 중 혹시 해당하는 것이 있는지 한번 생각해볼까요?
- 테스트 진행 속도가 느림
- 빌드가 실패
UI 테스트(End2End)는 Unit 테스트에 비해 실패하기 쉽습니다. 네트웍 문제, 기기의 문제, 예측하지 못했던 UI 혹은 기능의 수정들이 원인입니다.
Original testing pyramid
Mike Cohn의 “Original testing pyramid”는 그의 저서 “Succeeding with Agile” 에서 처음 등장했습니다. 아마 대부분의 제품팀에서 테스팅 문화를 어떻게 만들어 갈지 고민할 때 이 패턴을 염두에 두고 테스트를 진행할 것입니다. 작고 독립적인 단위의 테스트는 빠르게 수행됩니다. 크고 복잡하게 연결되어 있는 통합테스트는 느리게 진행됩니다. 그러므로 개발 프로세스에서 작은 단위에 테스트가 많이 수행될 수록 비용이 절감됩니다.
Case study: Leomo의 피라미드
TIP 1: Know your architecture
테스트 피라미드를 만들기 위해서는 서비스 구조에 대해 이해해야 합니다. Leomo의 웹서비스의 구조는 다음과 같이 이루어져 있습니다.
- React website
- REST API Server
- S3(Static file storage. fonts, images, etc)
- DB
- Worker
그리고 구조를 도식화하면 이런 그림이 될 거에요.
Tip2: Make your team feel part of the quality process
내용 보강 필요.
QA Engineer 뿐만이 아닌 Software engineer 역시 제품 품질에 참여할 수 있는 문화가 마련되어야 합니다.
Tip 3: Choose which layer is the best for your test
제품 개발 환경에 맞는 테스트 레이어를 선택하는 것이 중요합니다. 모든 것을 알 수 있는 상황이라면 Whitebox testing을 시도해 볼 수 있습니다. 하지만 협업이 제한적이라면Graybox testing으로 결함을 찾아 볼 수도 있습니다. 시간이 제한적이고 제품기능의 정의만 알고 있는 정도라면 Blackbox testing도 좋은 선택이 될 수 있습니다. 참고로 말씀드리자면 Leomo는 Graybox testing을 선택했습니다.
테스터는 기능의 내부적인 동작 과정을 전혀 알 수 없습니다. 입력과 출력에 나타나는 정보만을 알고 테스트를 진행합니다. 다시 말해 무엇이 수행되고 완료되는지 - 기능 명세 정의 - 만을 알고 있으며, 왜 그렇게 되는지에 대해서는 알지 못합니다. 이 테스트는 Unit, Component, Integration(통합), Acceptance(인수) 테스트 등의 모든 단계에서 사용될 수 있습니다.
테스터는 기능의 내부 동작과정의 일부를 알고 있습니다. 이 방법은 Blackbox testing과 Whitebox testing을 섞어 놓은 것입니다. 테스터는 DB에 접근해서 테스트된 데이터를 조회할 수 있으며, 알고리즘 구조와 서비스 아키텍쳐에 대해 부분적으로 알고 있습니다. 그리고 서비스 기능 동작이 정의된 높은 수준의 문서를 관리하고 있습니다. 그럼으로써 서비스의 결함을 빠르게 파악할 수 있습니다.
테스터는 기능의 내부 동작과정을 완전히 알고 있습니다. 테스터는 입력값이 무엇이고, 출력값이 어떻게 나와야 할지 알고 있습니다. 그리고 에러가 발생했다면 몇번 라인에서 발생했으며 원인이 무엇인지 알 수 있어야 합니다. 이것은 Unit 단위의 작은 테스트에서 선호되었던 방법이었지만, 지금은 통합 테스트나 시스템 테스트같은 큰 단위의 테스트에서도 사용되고 있습니다.
Let’s take a look into the Leomo’s pyramid — Website
Unit testing layer
- UI Test는 Enzyme을 사용합니다
- Backend에서는 Django를 사용합니다
- 비즈니스 코드를 테스트하기 위해 Whitebox tesitng을 진행합니다
- 테스터와 엔지니어가 Pair testing을 진행합니다
Component testing layer
Leomo는 Django로 REST API 컴포넌트 테스트를 진행합니다.
Api testing vs Unit http testing
- Unit http testing
Backend 코드내에서 http 응답을 주고 받는 과정을 Mock 객체로 대신해서 테스트하는과정을 말합니다. 실제로 통신을 네트워크로 주고 받지 않으므로 매우 빠르게 테스트가 진행될 수 있습니다. 초당 100회 이상의 테스트가 가능합니다. 구글에서 제공하는 Http Unit Testing 라이브러리가 좋은 예입니다. 하지만 이 테스트가 실제 서비스가 연동되어 하는 동작들을 검증하기는 어렵습니다.
2. Api testing
앞서 말한 Django로 진행하는 Api 테스트입니다. 실제로 Api 서버에 Api 호출을 통해 서비스의 기능을 확인해 볼 수 있습니다. 하지만 네트워크를 통해 통신이 이루어지므로 속도가 느립니다. 계정 등록, 로그인 등의 기능을 검증하는데도 몇초에서 몇분이 걸릴 수 도 있습니다.
Leomo’s Api testing flow
API Testing을 통해 얻을 수 있는 가장 큰 장점은 여러 대의 Device가 연결되어 진행되는 기능들을 Device없이도 재현해 볼 수 있었던 점입니다. 이 방법으로 UI에서 보여지는 사전 조건을 미리 만들어 둘 수 있습니다. Sign up 전의 조건과, Sign up 후의 조건에 따라 Mobile app의 화면이 달라질텐데요, 이를 위해서 Manual로 실제로 Sign up을 할 필요가 없이 Sign up Api testing을 수행하면 되는 것이죠.
Leomo’s UI Testing
- End2End 테스트에 집중하고 있습니다
- Selenium으로 다양한 브라우저를 테스트합니다
- Smoke test도 수행합니다
- 수동으로 탐험적(Exploratory) 테스트를 진행합니다
Leomo’s Test pyramid shape — Website
Leomo의 테스트 피라미드를 살펴볼께요.
- Manual explorative test
- Automated End2End test
- Automated API test
- Automated Integration test
- Automated Component test
- Automated Unit test
위쪽일 수록 빈도가 적고 아래쪽일수록 빈도가 높습니다.
Leomo’s Mobile Testing
UI Test
Integration test
- Android: Robolectric
Unit test
Leomo’s Mobile testing pyramid
Conclusion
- 여러분의 서비스 구조(Architecture)를 알아야 합니다
- 테스팅 툴에 대해 조사하세요
- Unit level에서 최대한 많은 테스트를 만드세요
- Gray testing을 진행하세요
- 개발자와 Pari testing을 하세요
소감
조금 두서없이 차례가 진행되기는 했지만, Device를 만드는 업체에서 어떻게 테스트 자동화를 진행하고 있는지 알 수 있었던 기회였습니다. 그리고 개발자와 협업을 최대한 많이 하는 제품 개발 문화도 다소 부러웠던 것도 사실이었습니다. 세션 이후 개발자와의 협업을 이끌어 내기 위한 방법에 대한 질문을 개인적으로 드렸었는데, 이것은 개인과 팀의 성향의 방향인 것처럼 보였습니다. 테스트에 관심이 많은 사람들과 먼저 이런 시도를 해보고 확대해 가는 것이죠. 그리고 이런 흐름을 더 크게 키워가는 것입니다. 그리고 다양한 툴로 테스팅 과정을 구축한 것도 흥미로웠습니다.
