모바일 QA에 대한 효과적인 방법

기본적인 소프트웨어 테스팅과 크게 달라지지는 않지만 장비와 테스트 환경이 모바일로 달라진다면 그 특성상 약간은 달라진다. 또한 어떤 모바일 기기인지 플랫폼인지에 따라 달라진다. 따라서 디바이스와 플랫폼의 한계를 파악하고 테스팅 하는 것이 중요하다.

 

- 버그와 개선사항을 관리하는 것은 동일

- 복합상황이 나올 가능성이 많기 때문에 미리 이러한 상황을 계산해 테스트 케이스를 만들고 처리해야한다.

- Decison Table 혹은 다른 기법으로 모든 복합상황을 추출해서 테스트 한다.

- 임베디드와 모바일 앱은 심심찮게 Memory Leak과 예외처리가 되지 않는 경우가 나타날 수 있다. 따라서 코드 리뷰를 하거나 Stress testing을 통해 사용자 시나리오를 추려 테스트 자동화를 하는 것이 이상적이다. 

- 출시 이후 버그 패치에 대한 대책 / 모바일 기기에서 어플을 업데이트해서 버그를 패치하는 과정은 복잡하고 길기 때문이다. 따라서 출시 후 AS 및 유지 보수 비용이 많이 들 수 밖에 없다. 미리 Contigency plan을 세워 두고 critical bug가 나타나는 경우를 미리 대비해야한다.

 

* 복합상황 : 음성 / 영상에 대한 리소스를 동시에 사용하지 못한다. 다시 말해 라이브 스트리밍을 보고 있다가 전화가 온다면 오디오, 비디오 리소스를 바로 전화로 전환시켜줘야 한다. 또한 전화가 끊기면 다시 리소스를 라이브 스트리밍으로 연결해주어야 한다. 

 

* Decision Table(결정 테이블) : 요구사항의 논리와 명세화된 조건에 따라 나타날 수 있는 결과를 테이블로 만들고, 가능한 조합을 고려해 테스트 케이스를 생성하는 기법.

 

* Memory Leak(메모리 누수) : 사용하지 않는 객체가 회수되지 않고 계속해서 누적되는 현상. 주로 많은 전역변수의 선언이나 리스트, 해쉬맵 같은 콜렉션을 사용하고 저장한 객체를 해제하지않고 계속해서 유지하면 발생하게 된다.

 

Memory Leaks and Java Code - DZone Java

 

* Contigency plan : 테스팅에서만 쓰이는 용어는 아니고 크리티컬한 이슈의 잠재적 영향을 완화하시 위한 상설 정책을 의미하는 말이다.