에어브릿지(Airbridge)는 다양한 플랫폼 환경에서 광고의 성과를 분석하고 측정하기 위한 데이터를 자동으로 수집하고 이를 서버에 전달하기 위한 SDK를 제공하고 있습니다.
이런 SDK는 1억대 이상의 디바이스 안에서 하루 10억 건에 달하는 데이터를 수집하고 있기에 어떤 환경 속에서도 데이터를 수집하고 이를 전송을 해야하는 중요한 목표를 가지고 있기 때문에 배포 전 후로 철저한 테스트를 진행합니다.
이런 테스트 과정 중 하나인 Android SDK 자동화 테스트에 대해 소개하고 자동화 환경 구축기를 아래와 같이 총 3개의 시리즈로 나눠 공유드리고자 합니다.
1.
Android SDK 자동화 테스트 환경 구축기 1화 - 자동화 테스트 환경 소개
2.
Android SDK 자동화 테스트 환경 구축기 2화 - 테스트 구성하기
3.
Android SDK 자동화 테스트 환경 구축기 3화 - CI/CD 구성하기
이번 글은 자동화 테스트 환경 구축기의 첫번째 글로 자동화 테스트 환경을 소개하고, 제가 왜 자동화 환경을 구성하려고 계획하였는지, 그리고 이런 자동화 환경을 준비, 구성하는데 있어 어떤 고민을 했는지 살펴보는 시간을 가져보겠습니다.
왜 테스트 자동화를 도입하게 되었을까?
도입부에서 설명하였듯이 Airbridge SDK는 웹, iOS, Android 등 다양한 환경에서 다양한 데이터를 수집하고 있습니다. 물론 직접 수동으로 테스트를 진행 할 수 있겠으나 효율성의 문제 뿐만 아니라 수집되는 데이터가 많고, 종류가 다양하다보니 Human Error의 위험이 크기 때문에 자동화 테스트를 도입하기로 결정하였습니다.
다양한 사용자 환경, 버전과 같이 세부적으로 나눈다면 수동으로 테스트를 진행하기에는 무리가 있다.
어떤 것을 자동화 테스트 환경으로 구성할까?
일반적으로 사용하는 웹이나 앱과 달리 SDK의 주 사용자는 개발자로 이루어져있습니다. 그리고 개발자는 SDK를 활용하여 새로운 서비스를 개발하고, 이용자(개발자가 만든 서비스 이용자)에게 제공하고 있습니다. 이러한 특징 때문에 테스트 진행 시 두 가지 항목에 대해서 테스트하는 프로세스를 갖고 있습니다.
SDK를 활용한 서비스 제공 과정
1.
SDK를 활용하는 개발자의 입장이 되어 이용 가이드를 참고하여 테스트 앱을 제작, SDK를 사용해보며 오류 사항 탐색 (위 그림 중 1번)
해당 항목의 경우 제 3자의 입장이 되어 개발 단계에서 활용되는 테스트 앱과는 별개의 앱을 제작합니다. SDK를 직접 심어보면서 개발 기획 단계에서 의도한 내용이 모두 들어가 있는지, 내용을 참고하였을 때 어색한 표현이 없는지, 사용성 등 다양한 요소를 직접 확인하고 있습니다.
2.
이용자(고객)의 입장이 되어 SDK가 심어진 앱을 조작하며 오류 사항 탐색 (위 그림 중 4번)
이번 자동화 테스트 환경 구성 대상으로 개발자의 입장에서 제작했던 테스트 앱을 디바이스에 설치하고, 다양한 동작을 시도하면서 개발자가 만든 서비스 안에서 데이터를 잘 수집하고, 잘 전송하고 있는지, 오류는 발생시키지 않는지 등을 확인하는 프로세스를 만들고자 하였습니다.
무엇을 활용해서 자동화를 구성할까?
우선 최종적으로 자동화 테스트 환경 구성을 위해 사용한 환경은 아래와 같습니다.
•
Framework: Appium Java, Cucumber JVM•
Language: Kotlin (Java 11)•
CI/CD: Github Action, SlackFramework
자동화 환경의 초석이 될 Framework의 경우 고민없이 Appium과 Cucumber을 선택하였습니다.
웹 환경에서 E2E 테스트를 진행한다고 하면 주로 사용되는 Selenium, Cypress와 같이 모바일 E2E 환경을 테스트하기 위해서는 대표적으로 Appium이 사용되기 때문에 고민없이 Appium을 사용했습니다.
Cucumber의 경우 BDD Test Framework 중 하나로 Airbridge SDK가 고객의 행동에 따라 데이터를 수집하기 때문에 사용자 행동을 기반으로 시나리오를 작성할 수 있는 Cucumber를 선택하였습니다.
일반적인 코드를 활용한 Given - When - Then 패턴
물론 Framework없이 코드만을 통해 위와 같이 BDD처럼 쓸 수 있으나 시나리오를 주석으로 관리하고 코드와 함께 있어 관리가 어렵다는 불편함이 있습니다.
Cucumber를 활용한 Given - When - Then 패턴 (왼쪽 feature, 오른쪽 kt 파일 )
반면 Cucumber를 활용하였을 때 시나리오는 시나리오대로(*.feature 파일), 이를 동작시키는 코드는 코드대로 분리해서 관리 할 수 있어 유지보수, 관리 측면에서 뛰어나기 때문에 굉장히 큰 매력을 느꼈고 이번 자동화 환경에 포함시키게 되었습니다.
(위 예시에서 볼 수 있듯이 한글도 지원하고 있습니다.)
Language
자동화 환경을 구성하면서 가장 많이 고민을 했던 부분입니다. 많은 사람들이 ‘프로그래밍에서 언어는 하나의 도구일 뿐 아무거나 사용해도 된다.’ 고 하지만 앞으로 유지 / 보수 등을 고려하였을 때 신중하게 고를 수 밖에 없었습니다.
자동화 환경을 구축하는데 후보 언어로는 JavaScript, Python, Java(Kotlin)가 있었으며, 몇 가지 기준을 세워 비교해보았습니다.
1. 환경 구축
•
JavaScript: Appium과 동일한 언어, NPM 하나로 환경 구축이 쉬움
•
Python, Java(Kotlin): Appium 이외에 Appium-Python/JVM 추가 설치 필요
2. 언어 사용(활용) 경험
•
JavaScript: 적음
•
Python: 중간
•
Java(Kotlin): 많음
3. Github 활성화 (Appium, 2022년 5월 기준)
•
JavaScript: Star 15k, 마지막 릴리즈 2022년 5월 4일
•
Python: Star 1.3k, 마지막 릴리즈 2018년 11월 22일
•
Java(Kotlin): Star 979, 마지막 릴리즈 2022년 5월 7일
4. 기타
•
Python Cucumber의 경우 semi-offical 임
먼저 JavaScript의 경우 환경 구축부터 활성화 정도까지 모두 뚜렷한 장점을 가지고 있어 JavaScript를 사용하는 것이 가장 좋을 것으로 보이나 숙련도의 문제가 있어 아쉽게도 가장 먼저 제외하였습니다. ( )
)JavaScript의 제외로 남게 된 Python과 Java의 사이에서 몇 날 며칠을 고민을 했던 것 같습니다. GitHub 상의 마지막 릴리즈를 보았을 때는 유지보수 측면에서 꾸준히 지원되고 있는 Java를 선택하는 것이 좋을 것 같으나, Python의 압도적인 코드 사용성 때문에 고민을 하였습니다.
# Python Example
print("Hello Airbridge!")
Python
복사
// Kotlin Example
fun main(){
println("Hello Airbridge!")
}
Kotlin
복사
// Java Example
public static void main(String args[]){
System.out.println("Hello Airbridge!")
}
Java
복사
(위에서부터 순서대로) Python, Kotlin, Java에서 콘솔 텍스트 출력 방법
그러던 중 Kotlin 환경에서 Appium, Cucumber의 Java 환경이 호환 된다는 내용을 접하였고, 위 기준에 Kotlin을 대입해 보았을 때 Java의 이점과 Python의 일부 이점을 챙길 수 있을 것 같다는 판단을 했습니다. 이런 내용들을 토대로 Kotlin을 자동화 환경에 사용할 언어로 최종 결정 하였습니다.
CI/CD
개발 - 테스트 - 배포 Flow가 물 흐르듯이 흘러 갈 수 있다면 QA Engineer - SDK 개발자 사이에 업무 효율성이 증가 할 수 있고 더 나아가 어쩌면 QA Engineer, SDK 개발자가 손잡고 커피 한 잔을 마시러 갈 수 있다고 생각을 했습니다.
이런 커피 타임을 가질 수 있도록 CI/CD 환경은 Github Action과 Slack을 사용하였으며 자세한 내용은 아래에서 다뤄보겠습니다.
커피 한 잔을 위한 작업
성보님! 이번에 릴리즈 될 SDK 테스트 부탁드릴게요!
테스트 자동화까지 구성한 뒤 외부에서 테스트 요청이 왔을 때 테스트 시작 버튼을 눌러두고 결과를 공유하는 것만으로도 테스트 자동화의 목적은 50% 정도 달성했다고 볼 수 있습니다. 하지만 QA Engineer, SDK 개발자가 손잡고 커피를 마시러 가기 위해 아래와 같은 추가 작업을 진행하였습니다.
1.
언제 어디서나 누구나 쉽게 사용 할 수 있는 테스트 환경 구축
2.
개발 - 테스트 - 배포 프로세스에 활용 할 수 있을 것
3.
테스트 결과 공유 자동화
한 번 상상을 해봅시다. 자동화 테스트 환경을 모두 완성 시키고 기쁜 나머지 제가 14박 15일 연차를 썼다고 가정해봅시다. 그런데 5일 차 되던 날, 이전에 배포한 SDK에서 HOTFIX가 필요한 항목이 발견되어 수정 후 테스트가 필요하다면? 이때 가능한 시나리오는 두 가지 정도가 있을 것 같습니다.
1.
혹시 몰라 챙겨온 회사 노트북을 켠 뒤 테스트를 진행하고 결과를 공유해드린다.
2.
미리 공유드렸던 사용법, README.md를 참고하여 SDK 개발자분이 직접 테스트를 실행한다.
가장 먼저 2번 시나리오로 가정해봅시다. 앗차! SDK 개발자 분 PC에는 자동화 환경이 구성되어 있지 않아 환경 구축부터 해야하네요!
극단적인 상황으로 README.md를 참고하여 환경 구축을 진행했는데 SDK 개발자분의 환경과 충돌이 발생하여 테스트를 진행 할 수 없는 환경이 된다면? 어쩔 수 없이 1번 시나리오로 돌아오게 됩니다.
한 번 더 극단적인 상황으로 제가 만약 비행기를 타고 있었다면? 1번 시나리오도 불가능하게 되며, 제가 비행기에서 내려 연락이 가능할 때까지 테스트는 딜레이됩니다.
지금까지 구성한 방법으로는 제가 자리에 있을 때만 가능한 프로세스였습니다. 이번 작업을 진행하면서 제가 자리에 없더라도 다른 개발자분이 보다 쉽게 테스트를 진행할 수 있도록 환경을 구성했습니다.
여기서 활용한 방법이 GitHub Actions입니다. 버튼 클릭 한번으로 SDK가 삽입된 앱 Build → 테스트 진행 이 될 수 있도록 구성하였습니다. 더 나아가 제가 사용 중인 PC를 가지고 있지 않아도 GitHub 상에서 버튼 한번으로 테스트를 시작할 수 있게끔 하였습니다.
버튼 하나로 SDK 테스트 가능하며, 옵션을 추가하여 다양한 테스트를 할 수 있도록 구성
이를 좀 더 응용하여 수동 동작 이외에 GitHub API를 활용하여 Request를 보내면 위처럼 자동으로 Action이 동작(Trigger)할 수 있도록 명령어를 구성하고, 다른 개발자분들이 손쉽게 사용하실 수 있도록 문서를 작성, 공유하였습니다.
덕분에 다른 개발자분도 이전에 사용하던 개발 프로세스 사이에 해당 프로세스를 추가한다면 개발 완료 후 자동으로 테스트를 시작할 수 있게 되었습니다.
요청 주셨던 테스트가 끝났어요! 결과는 ...
물론 이정도 환경을 구축하고 테스트 결과를 직접 SDK 개발자 분께 공유드리는 것도 엄청난 프로세스 개선이라고 볼 수 있습니다. 하지만 해당 챕터 앞에서 말했듯이 방금 내린 커피에 얼음까지 넣는 여유를 가지기 위해 테스트 결과를 공유하는 자동화 프로세스까지 도입하고자 했습니다.
Slack Bot이 테스트 결과를 공유하는 모습
이를 위해 Slack Bot을 활용, Plain 메시지를 통해서 간략하게 테스트 정보(통과한 시나리오, 실패한 시나리오 등)을 공유하고 추가로 Cucumber에서 제공하는 Report파일을 공유하여 다른 개발자분들이 쉽게 확인 할 수 있도록 Bot의 코드를 구성하였습니다.
End? To be continue!
이번 첫번째 글에서는 테스트 자동화 프로세스 도입이라는 큰 틀에서 제가 구성했던 자동화 환경에 대해서 소개해드렸습니다. 해당 프로세스 도입을 통해 SDK를 테스트하는데 소모되는 인력을 크게 줄일 수 있을 것으로 예상되며 더 나아가 SDK 안정성을 높이는데 도움을 줄 것이라고 기대하고 있습니다.
다음 글에서는 본격적으로 Kotlin과 Appium을 활용하여 어떻게 자동화 환경을 구성하였는지 알아보는 글로 찾아뵙도록 하겠습니다.
감사합니다!
ᴡʀɪᴛᴇʀ
Seongbo Hong @NongE
QA Engineer
