E2E 모바일 테스트를 위한 17가지 전략

>이 글은 ymedialabs사의 블로그에서 가져온것입니다. 모든 저작권은 ymedia에 있으며, 좋은 정보를 공유하는 차원에서 올립니다. 빠르게 번역하느라 오역의 소지가 있습니다. 댓글로 남겨주시면, 빠르게 수정하도록 하겠습니다. 원본은 이 링크를 참고하세요

QA(Quality Assurance)는 매력적이지 않습니다. 매력적인 적도 없었고, 앞으로 결코 매력적일수도 없습니다. 소프트웨어 개발시 간과하는 영역이며, 일이 잘못되어질때 비난받는 그룹이 됩니다. 일반적으로 말하자면, 사람들은 모바일 디자인 , 유즈 케이스, 수익 창출의 기회에 대한 화려함을 좋아합니다. QA 테스트는 HR과 매우 유사합니다. 팀이 필요하다는 것을 알고 있지만 추적 가능한 ROI를 산출 할 수 없다고 인식하여 QA 및 모바일 테스트를 보류하고 이를 다른 “비즈니스를 할수 있는 비용”으로 분류합니다.

대부분의 사람들이 이해하지 못하는 것은 QA 테스트가 소프트웨어 개발 사이클에서 가장 중요한 프로세스가 될 수 있다는 것입니다. QA는 가장 중요한 파트입니다. 만약 제품을 출시한 이후에 기능이 동작하지 않는다면, 고객들은 열을 받아, 다시는 앱에 돌아오지 않습니다. 마찬가지로 사용자에게 무한한 가치를 제공하는 가장 멋지고, 유용하며, 아름다운 앱을 만들 수는 있지만, 페이지를 로드하는데 12초가 걸리면, 누구도 사용하지 않습니다. 잘 해봤자 마지 못해 사용하는 정도 일 겁니다.

모바일 앱 성능과 연관된 고객의 불만에 대한 소설을 작성해 보겠습니다. 모바일 앱 성능에 만족하지 못하는 고객이 앱을 포기하고 절대 돌아오지 않는 것이 분명하다는 많은 데이터가 수집되었습니다. 쇼핑객의 51 %는 앱 로딩 시간이 느리기 때문에 페이지를 포기했다고 주장합니다. 모바일 사용자의 85 %는 모바일 앱이 데스크톱 웹 사이트보다 빠르거나 빠르다고 기대합니다 (!!!! 정말). 모든 모바일 사용자 중 64 %가 모바일 페이지가 4 초 이내에로드 될 것으로 예상을 합니다. 그리고 이 기준으로는 오직 100대 eCommerce 기업중에 2%만이 이 기준을 통과합니다. (출처 — radware blog / 당신이 알아야만 하는 55가지의 웹 성능 통계 )

이러한 자료들을 보고 어떻게 판단해야 할까요? 우리는 수년 동안 악화에서 악화로 갔습니다. 2011 년 최종 사용자에게 제공되는 평균 모바일 페이지 크기는 390KB였습니다. 2015년 요즘은 얼마나 될지 맞춰 보시겠습니까? 1180kb( 모바일 웹 성능에 대해서 알아야만하는 23가지 진실 ). 따라서 모바일 사용자가 시간이 지남에 따라 모바일 앱 성능에 점점 더 많은 불만족을 느끼고 있음에도 불구하고 모바일 페이지가 무겁고 무겁게 만들어져 고객의 모바일 사용자 환경을 악화시키고 있습니다.

대부분의 경우 이러한 문제 중 일부는 해결 될 수 있거나 최소한의 QA 전략으로 개선 될 수 있습니다. 회사가 강력한 모바일 앱 테스트 전략을 수립하는 데 시간을 할애 했다면 우리는 모바일 페이지가 4초이내에 로딩되지 못하는 상황이 99 %나 되지는 않았을 겁니다. 대부분의 원인은 너무 느리게 로드되는 UI Component 입니다. (당신이 알아야만 하는 55가지의 웹 성능 통계)

얼마나 나쁘게 웹사이트와 모바일 앱이 동작하는지 알고싶다면, Google 도구를 보고 원하는 웹사이트의 URL을 입력하세요 (PageSpeed Insights). 또다른 재미나 실례로 google.com 을 입력해보세요. 모바일 웹 사이트조차도 100 점 만점에 53 점이 부족(46점)하다는 것을 알 수 있습니다. (2015년 기준이며, 현재는 79점입니다.)

핵심은 회사가 일반적으로 이러한 문제가 발생하지 않도록하는 체계적인 품질 보증 절차를 수립하지 않기 때문에 현재의 상황에 있다는 것입니다. 이 기사에서는 훌륭한 테스트 전략의 각 각의 주요 구성 요소에 대해 간략히 설명 드리 겠습니다. 이 기사는 다음 두 섹션으로 구분됩니다. 먼저 모바일에서도 사용할 수있는 일반적인 테스트 방법 을 다루겠습니다. 이러한 전략은 모바일 앱 및 모바일 웹 사이트를 비롯한 모든 소프트웨어 테스트에 적용됩니다. 두 번째 섹션은 주로 모바일에만 특화된 난제들과 모범 사례에 대해 중점적으로 설명하겠습니다. 이상적으로 모든 회사는 이 글에서 언급하는 모든 단계를 고려하여 수동및 자동 테스트 계획을 세울 것입니다. 이렇게만 한다면, 당신의 최종 모바일 제품이 고객의 기대치를 만족시키는 것을 보장할 수 있습니다.

일반적인 소프트웨어 테스팅 전략들

1. QA 테스터는 핵심 팀의 일부이며 전체 소프트웨어 개발주기에 참여해야 합니다.

소프트웨어 개발 프로세스를 일련의 이벤트로 살펴보면 QA 부분은 자연스럽게 (프로젝트가 끝나는) 종착점 또는 그 근처에 있습니다. 전통적인 폭포 회사에서는 테스터가 일반적으로 프로젝트의 테스트 단계 몇 주만 참여를 합니다. 애자일 프로젝트에서는 QA 리소스가 핵심 팀의 한 부분으로 활동하는 것이 적절합니다. 이는 프로그램의 전반적인 성공에 결정적으로 중요합니다. 테스터는 요구 사항 / 아이디어 단계에서부터 각 새로운 기능의 출시까지 프로젝트싸이클에서 한 부분이 되어 참여해야 합니다. 초기부터 테스트가 참여한 형태로 팀이 셋업되어 있다면, 무엇을 먼저 테스트 할 것인지 알수 있으며, 요구 사항 관점과 사용자 경험 / 디자인 관점에서 무엇을 기대하는지 정확히 알 수 있습니다. 폭포수와 애자일 방법론을 간략히 비교하기 위해 이전 기사 중 하나를 읽어 보시길 바랍니다. (참고)

2. 요구 사항 단계(get go)에서 테스트 스크립트 정의

테스트 스크립트 또는 테스트 케이스는 모든 QA 전략에서 전체적인 성공을 가늠하는 핵심적인 부분입니다. 경험이 부족한 매니저가 관리하는 소프트웨어 프로젝트들은 소프트웨어 테스팅에 대한 매우 느슨한 가이드라인을 가지고 있습니다. 일전에 회사 부 대표에게 이러한 요청을 들은 적이 있습니다. “QA 테스트가 그렇게 어렵습니까? 모든 것이 제대로 작동하는지 확인하십시오. “ 이것은 테스트와 테스트를 어떻게 수행해 하는지 이해가 완벽하게 부족하다는 좋은 실 사례 입니다. 단순히 “모든 것을 테스트”할 수는 없습니다. 현재로는 불가능한 상황입니다. 모바일 흐름을 개선하거나 새로운 기능을 출시 할 때 QA 테스터에게 명확한 문서를 제공하여 테스트가 논리적이며 체계적인 방법으로 테스트 팀이 테스트 스크립트를 명확하게 문서화하고 이해하도록하는 것은 일반적으로 제품 팀의 책임입니다 템플릿은 간단해야하며 소프트웨어 개발을 수행하는 사람이라면 그 누구라도 따라야합니다. 실례로 간단히 예를 들어보겠습니다.

3. Unit Testing (단위 테스트)

단위 테스트는 종종 개발자가 수행하지만 QA 엔지니어도 이 활동에 참여합니다. 단위 테스트는 일반적으로 개발중인 코드의 다양한 기능을 테스트하는 행위를 말합니다. 단위는 응용 프로그램의 테스트 가능한 가장 작은 부분에 지나지 않습니다. 단위는 테스트 할 함수, 모듈 또는 클래스가 될 수 있습니다. 많은 기업들이 자동화 된 단위 테스트 도구에 투자하기 시작했지만 아직은 매뉴얼 (수동) 프로세스를 일반적입니다. 단위 테스트 및 프로세스의 이점에 대한 훌륭한 소개는 이 글을 통해 읽을 수 있습니다.

4. Functional Testing (기능성 테스트)

기능 테스트는 두 개의 질문에 답변을 할수 있어야 합니다. “사용자가 작업을 완료할수 있습니까?” 그리고 “ 그 기능이 실제로 동작합니까?” 사용자가 개발하고 있는 특정 플로우의 모든 단계를 앞뒤로 이동할 수 있는 것을 보장하기 위해, 테스터는 변경되는 플로우를 면밀하게 볼수 있어야 합니다. 목표는 순전히 기능적인 관점에서 모든 단계가 예상대로 작동하고 절차가 결함이 없도록 보장하는 것입니다. 에를 들어 이전 페이지(previous page)로 못돌아가거나, 나가는 방법이 없이 모바일 페이지가 종료된다면, 기능 테스트에서는 결함으로 간주합나다. 기능 테스트에 대한 심층적인 분석(?)을 위해 , 이 글을 읽어보세요.

5. UX/Comps Testing (사용성 비교 평가/테스팅)

소프트웨어 테스트의 중요한 단계중 하나는 UXA 및 디자이너가 작성한 사용자 경험이 최종 구현과 일치하는지 확인하는 것입니다. 오랫동안 일해 봤지만, 이 테스트를 즉시 통과한 단일 기능이 기억나지 않네요. 여러가지 이유로 (일부는 의도적이거나 그렇지 않은 경우가 있음) 개발자는 디자이너가 설명한 정확한 방법으로 기능을 구현하지 못하는 경우가 많습니다.

많은 경우, 이러한 불일치를 잡기 위해 고도로 숙련된 QA 테스터가 필요합니다. 저의 경험에 비추어 볼 때, 디자이너가 의도한 사용자 경험과 동작하는 소프트웨어 간의 차이는 상당히 작습니다. 하지만 여전희 눈에 띄는 것들로는 : 보여지는 것과 최종 코드 간의 다른 폰트 ,다른 스타일, 너무 작거나 너무 큰 라인 사이의 패딩(공간), 디자인과 일치하지 않는 오류 처리, 잘못된 사본 등이 있을수 있습니다. 숙련된 테스터는 이러한 유형의 세부 사항을 고려해야하며 즉시 이러한 문제를 파악할 수 있어야합니다.

6. Performance Testing (성능 테스트)

성능 테스트의 가장 간단한 규칙은 다음과 같습니다. 기능이 추가됨으로써, 변경된 (유저) 플로우의 전반적인 성능 저하가 발생하지 않는 것을 보장해야 합니다. 모바일 앱의 환경에서 보자면, 새로운 기능이 추가 될 때 앱의 전반적인 속도와 반응을 모니터링 하는 겁니다. 이러한 측정 항목을 현재 제품의 유저 플로우 (기능 성능 분석 전후)와 비교하고 새 기능이 전체 장치 및 장치의 배터리 성능에 영향을 미치는지 여부를 결정합니다. (성능 테스트에 대한 자세한 내용은 AngryBird의 사례를 참고하세요 )

7. Load Testing (부하 테스트)

부하 테스팅은 거대합니다. (할게 많습니다) . 특히 인기있는 앱과 웹 사이트 같은 소프트웨어에서는요. 최종적으로 어플리케이션의 한계점을 테스트 하는 것입니다. (일반적으로는 부하 테스팅을 자동화된 스크립트로 사용합니다) . 다르게 표현하자면, 앱이 크래시되거나, 응답을 할수 없게 만들러면 얼마나 많은 사용자가 필요한지를 알아내는 것입니다.

블랙 프라이데이 시즌이 때마다 제대로 작동하지 않는 앱이나 웹 사이트를 있다고 하면, QA 팀이 부하 테스트를 잘 수행하지 않아, 서버가 대용량 트래픽을 견딜 수 있는지 확인을 하지 않았다는 좋은 싸인이 됩니다. 게다가 앱의 한계점을 테스트하기 위하여, 앱의 속도가 느려지기(여전히 사용할수 있지만 성능 지연이 보여지는 경우) 전에 수행하는 작업을 밝혀내야 합니다. 예를 들어 일부 전자 상거래 모바일 앱은 장바구니(카트)에 일정량의 항목을 추가 한 후에 관리하기가 훨씬 어려워집니다. 그것은 비지니스 관점에서는 받아 들이수는 있지만, 테스터는 실제 앱을 문제가 되는 지점을 수행하고 앱이 서서히 속도를 늦추는 조건을 문서화 해야합니다. (부하 테스트에 대한 모범 사례는 여기에서 더 보실 수 있습니다.)

8. Regression Test(회귀 테스트)

회귀 테스트란, 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 결함 수정 이후 변경의 결과로 새롭게 만들어 지거나, 이전 결함으로 인해 발견되지 않았던 또 다른 결함을 발견하는 테스트를 말합니다. (원문에서는 시간 여행 사례를 드는데 와 닿지 않아 정의로 대체함)

가장 작은 코드 변경조차도 전체 응용 프로그램에 대해 의도하지 않은 결과를 초래할 수 있습니다. 당신은 실제 발생하는 것을 보기 이전까지는 상상하기 힘들수도 있습니다. 예를 들어, 지난주 나는 작은 변화가 있었던 (체크 아웃된) 특정 페이지를 테스트하기로 했습니다. 결제 버튼을 클릭하는 사용자 흐름에 들어가면, 더이상 액션 버튼이 작동되지 않았습니다.

문제가 발생한 변경된 부분이 사용자 플로우안에 매우 깊은 곳 (3 단계)에 있더라도, 어떻게든 개발 과정에서 전체 흐름이 깨졌습니다. 변화가 발생한 후에, 개발자가 수정한 엔드 투 엔드 플로우가 여전히 작동하도록 보장하기 위함 입니다.

9. Manual vs Automated Testing (매뉴얼 vs 자동화 테스트)

단위 테스트가 자동화 될 수 있다는 사실을 간략하게 언급했으며, 다양한 유형의 QA 테스트는 완전히 자동화 될 수 있어야합니다. 단위 테스트, 기능 테스트, 부하 테스트, 성능 테스트, 기초 안정성 테스트(Smoke Test), 회귀 테스트 -이 모든 테스트 유형은 완전히 자동화 될 수 있습니다. 디자이너가 만든 설계서와 개발자가 작성한 최종 환경간에 불일치가 있는지 컴퓨터가 인식하지 못하지만 예상대로 작동하지 않는 사용자 플로우의 내용을 쉽게 테스트하고 문서화 할 수 있습니다. 개발자는 변경 작업을 마친 후 하룻밤 사이에 쉽게 테스트 스크립트를 실행하고, 돌아와서 (출근해서) 테스트 소프트웨어가 식별한 이슈 목록을 확인 할수 있습니다. 개인적으로는 연구를 수행하고 자동화 된 테스트 솔루션을 선택하는 것이 좋습니다. 시간과 비용을 절약 할 수 있으므로 정확성이 향상되고 개발자가 품질 보증 절차에 들어가기 전에 문제를 확인하고 수정할 수 있습니다. 특정 QA Task는 컴퓨터 / 소프트웨어로 대체할수 없지만, 자동화 된 테스트 도구를 사용하여 수행 할 수있는 많은 작업이 있습니다. 여기 수동 및 자동 테스트의 장단점에 대한 훌륭한 기사가 있습니다.

10. User Acceptance Testing (사용자 검수 테스트)

사용자 검수 테스트는 잘못된 이름입니다. 진짜 최종 사용자가 새 기능을 테스트하지 않기 때문입니다. 대신 회사 내에서 이 프로세스에 참여하도록 지정된 사용자 그룹을 선택하고 새 소프트웨어 변경 사항을 테스트하고 양호한 경우 배포합니다. 여기 힌트가 있습니다. : 거의 100% 이슈없이 테스트를 통과하는 경우는 없습니다. 그리고 그건 괜찮아! 이 단계는 일반적으로 웹과 응용 프로그램에 내장된 모든 기능에 대해 검증을 하는 (라이프 사이클의) 마지막 단계입니다.

일반적으로 UAT 전략은 사전에 잘 계획되어 있으며 전체 테스트 계획의 일부입니다. 소프트웨어의 복잡성과 회사 규모에 따라 다양한 이해 관계자 / 내부 사용자가 다양한 기능들을 검증하기 위해 UAT에 참여하게됩니다.

기능-특화적인 UAT는 보통 다음과 같은 절차를 따릅니다: 세션을 계획, 테스트 사례 초안 작성, UAT 이해 관계자 선택, UAT 세션의 범위와 범위를 벗어난 사항을 이해 관계자에게 설명하고, 주요 시나리오를 통해 테스터를 안내하고, 실제 기능을 테스트하고, 버그 / 문제점을 문서화하고, 끝마칩니다. (go / no-go 결정이라고도 함). 사용자 테스트 및 관련된 각 단계에 대해 더 자세히 읽고 싶다면 여기 훌륭한 입문서가 있습니다.

지금까지 웹 사이트, 모바일 웹 사이트, 기본 또는 하이브리드 응용 프로그램 또는 웨어러블 기술 등 모든 유형의 소프트웨어 제품에 공통적으로 적용되는 다양한 테스트 전략에 대해 살펴 보았습니다. 다음 파트에서는 스마트 폰 테스트와 관련된 일련의 모바일 관련 테스트 문제와 실 사례를 빠르게 살펴 보겠습니다.

모바일-특화 테스트 전략들

모바일 테스팅은 어렵습니다. — 이것은 사실입니다. 왜냐면 매우 많은 다른 사이즈의 스크린들, 운영체제 버전들, 네트워크 의존성 그리고 다른 요소들이 당신의 테스트 계획과 스케줄에 영향을 줄수 있습니다. 개인적으로는, 모바일 앱 테스팅이 어람나 어려운지를 보여주는 아래 두 개의 슬라이드를 좋아합니다.

자 좀더 자세하게 이러한 이슈들을 다루어 보겠습니다.

1. Device Testing (디바이스 테스팅)

웹 사이트를 구축하고 테스트하는 것이 멋진 이유는 무엇입니까? 테스트 대상으로는 Mac과 Windows 랩톱 / 데스크톱의 두 가지 장치 유형 만 있습니다. 물론, 그들은 당신이 설명해야 할 다양한 해상도를 가지고 있지만, 그것들은 확실히 범위가 제한되어 있습니다. Android에만 얼마나 많은 기기 유형이 있는지 알고 있습니까? 현재 24000개 이상의 유형이 존재합니다. OpenSignal의 행렬은, 얼마나 안드로이드 마켓이 머리가 아픈지를 보여줍니다. (글로벌 마켓에서는), 적절한 QA 테스트에 영향을 미칩니다. 기본적으로, 아래에서 볼 수있는 행렬은 안드로이드가 실행되는 모든 다른 화면 유형의 조감도입니다.

Android 기기는 문자 그대로 다양한 (2,3차원적으로) 형태를 제공됩니다. QA 전략의 전반적인 성공을 위해서는 응용 프로그램을 최적화 해야하는 장치와 화면 크기를 결정해야합니다. 단순히 지원되지 않는 일부 장치 및 화면 크기가 있을 수 있으므로, 테스터가 규칙을 준수하고, 지원되는 모든 장치를 테스트할수 있는 명확한 회사 정책을 가질수 있게 하세요.

2. OS Version Testing and Support (운영체제 버전 테스팅및 지원)

모바일 테스트에 대해 귀찮은 것은 장치가 엄청나게 파편화된 그 이상이의 문제가 있기 때문입니다. iOS와 Android 모두 시장에 존재하는 상당수의 운영 체제 버전을 보유하고 있습니다. iOS가 Android와 비교해 월등히 뛰어났으며 지원되는 운영체제 버전이 3 가지 밖에 없다는 것을 알 수 있습니다. 이는 회사가 iOS (소스)에서 첫 번째 응용 프로그램을 개발할 것을 제안하는 많은 이유 중 하나입니다.

대조적으로, 안드로이드는 미국에서만 여전히 시장에 나와있는 적어도 7 개의 다른 OS 버전을 가지고있다. 공정하게 말하자면, 애플은 아이폰 용 제조업체이자 소프트웨어 공급자이기 때문에 사용자들이 이용할 수있는 버전의 수를 완전히 통제 할 수 있습니다. 안드로이드는 다양한 버전을 완전히 제어 할 수 없습니다. 대신 제조사에 의존하여 업데이트를 푸시합니다.

테스팅의 관점에서 볼 때 고객은 제조사의 운영체제 버전에 대해서는 언급하지 않습니다. 이것은 완전히 악몽입니다. 즉, 테스터가 각 운영체제의 모든 새로운 기능을 확인할 수 있도록 지원되는 Android / iOS 버전을 명확하게 지정하는 테스트 정책을 회사에서 마련하는 것이 매우 중요합니다.

3. Device testing vs emulator testing policy (디바이스 테스팅및 에뮬레이터 테스팅 전략)

모바일 테스트의 복잡성을 감안할 때 QA 테스트 간소화를 위한 SaaS 서비스 이해가 급증하고 있습니다. 현재 QA 테스터가 특정 기능을 신속하게 테스트하는 데 사용할 수있는 클라우드 기반 에뮬레이터가 풍부합니다.

아마도 이들 중 가장 인기가 browserstack.com, 회사는 신속하고 효과적으로 어떤 모바일 앱을 테스트하는 데 사용할 수있는 구독 기반의 솔루션입니다. 온라인 시뮬레이터로만 시작되었지만 2016년에는 실제 장치에서도 테스트가 진행되고 있습니다.

테스트 관점에서 볼 때 QA 엔지니어는 몇대의 기기에서 수동으로 테스트합니다. 적어도 Android 및 iOS에서 가장 인기있는 버전을 테스트해야 합니다.

그러나 자주 사용되지 않는 장치 유형, 화면 크기 및 iOS 버전에 대한 많은 테스트가 시간과 비용을 절약하기 위해 에뮬레이터를 통해 수행되어야합니다. 예를 들어, BrowserStack은 다음과 같은 모바일 유형을 지원합니다. 그리고 이와 동일한 경쟁자들이 많이 있습니다.

4. Carriers Testing & Network Connectivity testing (통신사 & 네트워크 연결성 테스트)

우리 모두 알고 있듯이 다양한 통신 사업자는 고객에게 다양한 연결 옵션을 제공합니다. 1G에서 LTE까지의 모든 것. 테스터가 고려해야 할 추가 사항 중 어떤 기능의 성능이 통신 업체마다 다를 수 있다는 점입니다. 예를 들어 앱 성능 테스트가 전적으로 WiFi에서 수행되어서는 안됩니다.응용 프로그램의 작동 방식을 확인하려면 실제 3G, 4G 및 LTE 모바일 통신 표준에서 응용 프로그램을 구체적으로 테스트해야합니다. 이상적으로 Verizon, TMobile, ATT 및 Sprint와 같은 거대 통신 사업자 중 적어도 일부에 대해서는 테스트를 시도해야합니다.또한 연결이 끊어 지거나 갑자기 4G에서 1G로 바뀌면 어떤일이 발생하는지 테스트해야 합니다. 응용 프로그램은 어떻게 작동하는지? 사용자는 무엇을 하는지?

5. Interrupt condition ( 인터럽트 상황)

스마트폰 및 모바일 애플리케이션의 인기가 높아지면서 회사는 인터럽트가 발생한 상황을 위한 테스트 방법 및 비즈니스 규칙을 따라 잡았을 것입니다. 하지만 당신은 틀렸을 것입니다. 인터럽트 조건은 무엇입니까? 들어오는 알림, 텍스트 메시지 또는 통화가 인터럽트 조건의 일반적인 예입니다. 사용자가 앱에서 무언가를 하고 있으며, (앱을 떠나려 고하지 않은 상태에서) 결함이 없는 상황에서, 갑자기 인터럽트가 발생합니다. 질문은 “인터럽트가 끝났을 때 앱이 어떻게 작동해야 합니까?” (예 : 전화를 끊습니다).

불행하게도 많은 대기업들이 인터럽트가 발생한 경우 매우 부족한 태도를 보이며 이를 처리하는 방법을 전혀 모릅니다.

• 캔디 크러시 게임을 하는 중에 누군가 전화로 전화를 했습니다. 게임에 다시 돌아 오면 기본 화면으로 부팅되어 모든 진행 상태를 잃어 버리게됩니다.
• Groupon 앱은 중단되기 전에 특정 제품 세부 정보 페이지에 있었던 경우에도 자동으로 홈페이지로 돌아갑니다.

이것들은 인터럽트가 발생했을 때의 나쁜 습관의 몇 가지 예에 지나지 않습니다. 테스터는 중단이 발생할 때 어떤 일이 발생하는지 항상 확인해야하며 비즈니스 팀에게 이러한 문제를 보고하여 고객이 실망하지 않도록 적절한 조치를 취해야합니다.

6. Crowd-Source Testing (크라우드 소싱 테스팅)

크라우드 소싱 테스트는 소프트웨어 테스트 분야, 특히 모바일 테스트 분야에서 뜨고 있는 기법입니다. 개념은 간단하며 포커스 그룹을 사용하는 것과 유사합니다. 특정 사용자 경험을 테스트하기 위해 포커스 그룹을 사용하는 경우 실제 사용자 또는 객관적으로 제품에 대해 대화 할 수있는 잠재적인 사용자를 모아 써드 파티 회사와 계약을 맺습니다.
포커스 그룹이 완료된 후 써드 파티 회사는 보고서를 준비합니다. 크라우드 소싱 테스트는 타사 대행사와 계약한다는 점에서 비슷합니다. 대행사는 일반적으로 어떤 것도 사전에 청구하지 않습니다. 대신, 그들은 테스터 풀을 모집하고, 앱을 앞에두고, 대행사와 테스터 모두 그들이 발견 한 버그를 기반으로 돈을받습니다.

크라우드 소싱 테스트에는 여러 가지 장점이 있습니다. 첫째, 크라우드 소싱 테스트 회사는 수천 명의 테스터에게 제품을 전달할 수 있습니다. 즉, 테스트를 빨리 마칠 수 있으므로 제품 출시시기를 앞당길 수 있습니다. 발견 된 버그를 기반으로 사람들에게 비용을 지불하기 때문에 확실히 비용 효율적입니다. 또한 회사의 이러한 추가 장치를 구입하지 않고도 다양한 장치, 장치 크기, 운영 체제 및 OS 버전을 테스트 할 수 있습니다.

크라우드 소싱 테스트에는 몇 가지 중요한 단점이 있습니다. 첫째, 비밀 프로젝트에 종사하는 경우 사용자가 통제 할 권한이 없는 임의의 테스터가 제품에 액세스하는 것을 원하지 않을 수 있습니다. 또한 크라우드 소싱 테스트를 위한 복잡한 온라인 플랫폼이 등장하더라도 테스터와 커뮤니케이션 하는 것은 어려울 수 있습니다. 마지막으로, 얼마나 많은 테스터가 자격이 있는지 정확히 알지 못하기 때문에, 얼마나 빨리 작업을 완료 할지 모르게 되고, 전체 프로젝트 계획을 관리하기가 어려울 수 있습니다. (크라우드 소싱 테스팅의 장 단점은 이 글을 참고하세요)

7. Security Testing (보안 테스팅)

무서운 통계에 따르면, 요즘 모바일 애플리케이션의 보안 테스트가 필수적입니다.최근의 Arxan “애플리케이션 보안 보고서 연례 보고서 (2016 년 1 월)”에 의하면 :

• iOS 및 Android에서 가장 인기있는 앱의 100 %가 해킹 당했습니다.
• 해킹하는 방법 일부를 적용하여 테스트해보니, 애플리케이션의 90 %가 적어도 2 가지의 치명적인 취약점을 가지고 있습니다.
• 조직의 50 %가 보안 테스트 전용 예산을 가지고 있지 않습니다.

별도의 글로 보안 모범 사례를 다루 겠지만 테스트해야하는 최소 보안 취약점을 살펴 보겠습니다.

• 첫 번째는 데이터 흐름의 취약점입니다. 사용자가 요구하는 개인 식별 정보 및 데이터 입력을 포함하는 플로우에 대해 빠른 QA 테스트를 수행하십시오. 이 데이터는 어디에 저장되어 있습니까? 정보가 보안 채널을 통해 전송되고 항상 암호화되어 있는지 확인하고 어느 시점에서든 클라이언트 측 (스마트 폰)에 저장되지 않도록하십시오.
• 둘째, 데이터 누출에 초점을 맞추세요. 데이터가 로그 파일을 통해 유출되지 않았는지 확인하십시오 (여러 번 본 적이 있습니다!).
• 마지막으로 앱에서 서버 측으로 이동하는 모든 웹 데이터가 보호되는지 확인하십시오. 가장 강력한 앱은 데이터 암호화에 HTTPS를 사용합니다. 따라서 회사가 이러한 관행을 따르는 경우 CSS, 스크립트 및 이미지를 비롯하여 모든 인증 된 페이지가 HTTPS를 통해 제공되도록 빠른 보안 테스트를 수행해야합니다.

결과

이 기사에서는 모바일 장치에서 새 기능을 테스트하는 과정에서 사용할 수있는 적어도 17 가지 이상의 테스트 전략을 제공합니다. 이것은 매력적인 작업은 아니지만 강력하고 성숙한 테스트 전략을 수립하는 것이 애플리케이션 성공의 열쇠입니다.

(불완전한 앱을 배포한지 ) 하루가 지나면 대부분의 모바일 사용자는 용서를받지 못합니다. 모바일 앱이 계속로드되는 데 2–3 초 이상 걸리면 모바일 앱을 포기하고 다시 돌아 오지 않습니다. 사용자 플로우에서 한 부분이 망가져, 현재 진행중인 작업을 진행할 수 없으면 앱을 징벌합니다 (별점 테러). 고객의 입장에서는, 아이콘을 클릭한 후 생각한대로 작업이 완료되는 것 만큼 중요한 것이 반응성입니다(의역) .

QA 테스터는 모바일 앱 개발의 숨겨진 영웅입니다. QA 테스터는 빛나는 새로운 응용 프로그램이 부드럽고 편한 방식으로 고객에게 실제로 배포되는 것을 보장하는 사람입니다. 이 17 가지 전략을 따르면 99.99 %의 모바일 앱이 버그없이 무료로 출시됩니다.