소셜 미디어 모바일 앱을 위한 테스트 시나리오 설계 by Govindarajan

출처: Designing Test Scenarios for Social Media Mobile Apps By Krishnan Govindarajan, 2018년

https://www.stickyminds.com/article/designing-test-scenarios-social-media-mobile-apps

 

 

모바일 소셜 앱은 메시지를 보내고 받는 기능, 푸시 알림, 미디어(사진, 오디오, 비디오) 공유 기능 등을 특징으로 한다. 저자는 자신의 경험을 바탕으로 소셜 미디어 앱에 대한 테스트 시나리오 몇 가지를 설명한다.

 

 

푸시 알림(Push Notifications)

푸시 알림은 애플리케이션에 의해 사용자 디바이스로 "푸시"되는 소셜 미디어 알림 또는 문자 메시지 알림이다. 푸시 알림은 사용자의 앱 참여 내역(engagement history)을 학습한 다음 이 인터액션을 기반으로 알림을 보낸다는 점에서 흥미롭다.

 

각 운영 체제(Android, iOS, Windows, BlackBerry)에는 PNS(푸시 알림 서비스)가 있다. 앱 게시자는 앱을 올리려는 각 운영 체제의 푸시 알림 서비스에 등록해야 하며, PNS는 API를 앱에 제공한다. 앱 게시자는 앱을 앱 스토어에 업로드하고 사용자가 사용할 수 있도록 한다. 사용자가 앱을 다운로드하여 설치하면 해당 사용자와 해당 디바이스의 고유 ID가 디바이스 운영 체제의 푸시 알림 서비스로 전송된다. 이러한 크리덴셜(credentials) 정보는 앱 서버에 저장되어 향후 인증(authentication) 후 푸시 알림을 보낼 수 있다. 크리덴셜은 디바이스 ID에 특정하므로 테스트할 실제 디바이스에 애플리케이션을 배포해야 한다.

 

푸시 알림을 테스트할 때 테스트 케이스는 OS마다 동일해도 그 동작은 다를 수 있다. 예를 들어 Android와 iOS 디바이스에 대해 살펴보자. 앱이 포그라운드 또는 백그라운드에서 실행되는 경우에 대해 별도의 테스트 케이스를 생성하며, 사용자 A가 사용자 B와 채팅 중이라고 가정해 보자. iOS와 Android 기기 모두 동일 채팅 스레드에서 수신된 메시지에 대한 시청각 알림이 없다. 하지만 이 시간 동안 사용자 C가 사용자 A에게 메시지를 보낸다면 Android 디바이스에서 사용자 A는 오디오와 시각적 알림을 모두 받는 반면 iOS에서는 오디오 알림만 받는다. 앱이 백그라운드에서 실행 중일 때 Android에서는 사용자가 앱을 통해 액세스할 때까지 알림 패널에 알림이 표시된다. iOS에서는 알림이 몇 초 동안 알림 패널에 표시된 다음 바탕 화면의 앱 아이콘으로 내려와 수신 메시지 수가 배지 카운트(badge count)에 표시된다.

 

여러 발신자의 메시지가 표시되는 방식도 Android와 iOS에서 다르다. Android에서는 메시지가 함께 뭉쳐서 표시된다(예를 들어 "2개 대화에서 3개의 새 메시지"). iOS에서는 개별 발신자의 메시지가 알림 패널에 별도로 표시되며 각 발신자의 최신 메시지가 표시된다.

 

잠금 화면에서 사용자가 푸시 알림을 표시하도록 선택한 경우 이러한 알림이 설계된 대로 표시되는지, 또한 실행 가능한 알림이라면 디바이스 잠금을 해제할 필요 없이 팝업 상자에서만 메시지를 스크롤하고 회신할 수 있는지 여부를 테스트해야 한다.

 

동일한 앱의 푸시 알림이 여러 다른 플랫폼, 여러 다른 화면 크기 및 해상도에서 다르게 동작할 수 있다.

 

 

여러 디바이스(Multiple Devices)

테스트할 때 모든 디바이스-OS 구성(device-OS configurations)에 손쉽게 접근할 수 있는 것은 아니다. 이 문제를 해결하기 위해 우리 팀은 타겟 시장의 사용 보고서(usage reports)를 이용했다. 이 보고서를 기준으로 사용 중인 각 모바일 브랜드의 상위 4개 모델을 선택하고, 각 디바이스의 최신 버전과 그 이전 버전을 테스트하여 고객에 대한 80% 테스트 커버리지를 보장하고자 했다.

 

 

미디어 전송(Media Transfer)

미디어 전송은 소셜 앱의 중요한 측면이다. 원래의 압축되지 않은 형태로 미디어를 전송하는 것은 기가바이트의 대역폭이 필요하고 시간이 많이 걸리기 때문에 비용이 너무 많이 든다. 소셜 앱의 경우 디지털 미디어 콘텐츠가 전송되기 전에 압축되기 때문에 데이터 품질이 어느 정도 손상된다. 디지털 콘텐츠가 더 많이 공유될 때마다 부분적인 데이터 손실이 발생하지만 이는 거의 눈에 띄지 않으며, 오히려 이 데이터의 전송, 저장 및 검색 용이성은 데이터 품질의 극미한 손실을 보상하고도 남는다. 여기서 QA의 역할은 이미지 품질 손실이 규정된 한도를 초과하지 않는지 테스트하는 것이다. 테스트의 초점은 전송 후 미디어의 품질이 아니라 전송 속도에 있으며, 이는 부하 테스트를 통해 수행된다.

 

 

부하 테스트(Load Testing)

부하 테스트의 경우 QA 관점에서 ‘속도(speed)’와 ‘사용자 부하(user load)’라는 두 가지 요소가 중요하다. 이러한 측면을 테스트하기 위해 우리 팀은 API 도구를 사용하여 API 호출에 대한 부하 및 예상 응답 시간을 지정하고 그 결과를 확인했다. 예를 들어, 10초 안에 천 명의 사용자 간 미디어 전송을 테스트해야 한다고 가정하자. 천 번의 API 호출을 실행해야 하는데 여기서 API 테스트 도구가 도움이 된다. 이러한 API 호출의 결과에서 전송 데이터 유형(텍스트, 이미지 또는 비디오)에 따른 평균 응답 시간을 계산할 수 있다.

 

API 호출을 로컬에서 실행하면 로컬 인터넷 속도에 따라 워크플로우가 종속되므로 테스트 도구 서버는 이상적으로는 API 서버가 있는 로컬에 있어야 한다. 테스트 팀이 지리적으로 멀리 떨어져 있는 경우라면 테스트 서버의 IP 주소를 API 서버와 함께 화이트리스트에 올릴 수 있다.

 

테스트 케이스는 공유되는 미디어 유형에 따라 달라진다. 동영상의 경우 비디오의 재생 길이(play length)가 모든 연속 전송(every successive transmission)에서 유지되는지 테스트해야 한다. 또는 100명의 사용자가 한 사용자에게 비디오를 전송한다고 가정하자. 테스트 도구를 사용하여 모든 사용자가 동일한 비디오 파일을 보내는 것처럼 동작하도록 스크립트를 실행하여 응답 시간을 균일하게 평가할 수 있다. 또 다른 시나리오는 “사용자가 비디오를 동시에 업로드하는 동안 몇 개의 채팅 스레드를 시작할 수 있을까?”이다. 사용자가 동일한 비디오를 여러 채팅 스레드에 업로드하거나 또는 여러 비디오를 업로드하고자 할 수 있다. 이 테스트를 위해 우리 팀은 최대 4개의 스레드에서 동영상 업로드 제한을 선택했다.