본문 바로가기

기타

[If Kakao 후기] QA 엔지니어가 바라본 모바일 자동화 테스트

본문 내용은 모두 if kakao에서 진행된 세션을 바탕으로 정리되었고, 사진 자료 또한 발표 자료에서 가져왔음을 밝힙니다.

https://if.kakao.com/2022/session/96


QA엔지니어가 바라본 모바일 자동화 테스트

자동화 테스트는 개발자들이 진행할 경우 코드 관점에서 더 이점이 있다고 한다.

QA 관점에서는 테스트에 대한 여러 방법론과 경험을 통해 아이디어를 낼 수 있다.

 

1. 다양한 변수

풀 테스트를 해도 어려울 수 있다.

 

특정 조건에만 발생하는 이슈들을 자동화 테스트를 통해서 검증할 수 있다.

따라서 자동화 테스트와 메뉴얼 테스트를 병행하면 된다.

 

자동화 테스트는 갱신에 드는 시간과 같은 것들도 검증할 수 있다.

Consistency는 제품 품질의 일관성 확보에 도움을 준다.

 

세 가지 접근법

1. Maintenance (Test Environment / Layer Design)

유지보수성은 개발에서 뿐만 아니라 QA에서도 중요하다. 모바일의 경우 Multi Device, Cross Platform을 지원하는 Test 환경이 필요하다는 것을 고려하여 Appium을 사용했다고 한다. 아래와 같이 멀티 디바이스를 연결하여 병렬로 수행 가능하다고 한다.

https://appium.io/

 

Appium: Mobile App Automation Made Awesome.

Appium Philosophy Appium is built on the idea that testing native apps shouldn't require including an SDK or recompiling your app. And that you should be able to use your preferred test practices, frameworks, and tools. Appium is an open source project and

appium.io

(Appium은 native, web app, hybrid app을 테스트할 수 있는 테스트 자동화 프레임워크이다)

중요한 점은 iOS와 안드로이드의 서로 다른 테스트코드를 관리해야 했다는 것이다. 하나의 스크립트로 자동화 테스트를 수행할 수 있도록 고민한 결과, Layer Strategy를 이용했다고 한다. 아래 세가지 층을 나누어 코드를 작성했다.

 

Control Layer: User Action(버튼 클릭, 스크롤, 라벨 확인 등)

Business Layer : 비즈니스 로직. 각 서비스별 비즈니스 로직을 생성한다. 비즈니스 흐름에 집중한다.

Test Layer: 테스트 케이스를 구현

 

Appium에서는 아래와 같이 iOS, Android의 요소를 하나로 초기화할 수 있다.

Test Layer에서는 테스트케이스의 확장성에 집중한다.

테스트 케이스를 빌더 패턴을 통해서 만들어낸다. 이를 비즈니스 레이어로 전달한다.

 

2. Monitoring(Report, OpenSearch, Grafana, Device Farm)

모니터링 또한 테스트 자동화의 중요한 관점이다.

 

- Log : 로깅을 할때, 테스트를 빠르게 파악 가능하고 디버깅이 용이하게 진행해야 한다.

 

- OpenSearch: OpenSearch를 사용하여 로그를 수집하고, 통합 검색을 하도록 만들었다.

 

- Grafana: 테스트 정보를 공유하다보니, 특정 정보가 강조되거나 커스터마이징하고 싶다는 니즈가 생겼다.

Grafana를 연동하여, 단말 및 플랫폼 별 랩타임이나 원하는 지표를 알 수 있도록 시각화를 할 수 있게 했다.

 

- DeviceFarm: 언제 어디서든 모바일 환경에 접속하여 테스트가 가능한 환경이 필요하다.

재택 근무 등의 이유로 그런 것들이 필요한데, 카카오 DeviceFarm을 선택하여 사용한다. 단말의 상태나 OS 정보를 알 수 있고, 누가 사용하고 있는지에 대해 알 수 있다.원격에서 테스트를 실행하면서, 동료와 함께 모니터링이 가능하다.

 

3. Process

다수의 동료와 협업해야 하는 상황이 많아지면서, 프로세스의 효율성이 중요하게 되었다.

따라서 업무별 프로세스를 만들었다.

 

신규기능 프로세스 : QA 담당자로부터 필요항 요구사항을 전달받는다 -> 타당성을 조사한다 -> 자동화 테스트케이스를 작성한다 -> 테스트 코드를 구현한다 -> 테스트 수행

 

유지보수 프로세스 : 과제 리뷰를 서비스 QA로부터 받는다 -> 테스트 계획을 세운다 -> 자동화 테스트케이스를 작성하다 -> 테스트한다 -> 데일리 리포트를 매일 발행한다 -> 릴리즈 이후에는 운영 모니터링을 진행한다.

 

운영 모니터링 프로세스 : 운영 모니터링이 시작되면 젠킨스에서 디바이스팜 테스트를 만들고, 그라파나 훅을 통해 에러를 알림받는다 -> 에러 여부를 파악한다 -> 담당자에게 전달한다.


QA는 제품의 품질을 보장하기 위한 중요한 과정이다. 개발자가 미쳐 발견하지 못한 부분을 QA에서 많이 발견하곤 했는데, 대규모 서비스에서는 어떻게 효율적이고 정형화된 프로세스를 구성할 수 있는지 궁금했다. 원래 QA Engineering에 대해서는 문외한이었는데, 본 세션을 보고 대규모 서비스에서 서비스의 품질을 유지하기 위해 QA를 어떻게 진행하는지에 대해 대략적인 윤곽을 그려볼 수 있었다. 모바일의 다양한 환경 및 플랫폼을 단일 프레임워크로 테스트할 수 있다는 점이 놀라웠고, 생산성 및 디버깅 효율을 높이기 위해 Monitoring을 다각도로 체계화시키는 방법에 대해서 알 수 있었다.