2016년 12월 27일 화요일

모바일 SW 개발 사례 연구 - 품질/테스트


최근 몇 년 사이에 스마트폰의 급격한 증가와 함께 다양한 모바일 소프트웨어가 늘어나고 있고, 상당수의 컴퓨팅 작업들도 스마트폰에서 실현되고 있다. 이러한 이유로 모바일 소프트웨어 사용자의 요구사항이 늘어나고 있으며 요구사항을 반영하기 위한 설계, 개발 기법이나 품질, 테스트 기법들의 필요성도 함께 요구되고 있다. 이번 회에서는 모바일 소프트웨어의 품질과 테스트 방법에 대해 살펴보도록 한다. 품질 확보를 위해 고려해야 하는 테스트 방법을 잘 이해하여 효율적인 모바일 소프트웨어 개발이 되기를 기대한다.

사례 연구 전 확인 사항

모바일 소프트웨어의 개발 환경과 품질 체크 포인트


매우 빠른 트렌드 변화를 보이는 모바일 소프트웨어가 성공하기 위해서는 기존의 소프트웨어 개발 방식이 아닌 모바일만의 개발 환경의 특징을 고려하는 것이 중요하다. 거의 유사한 OS와 해상도에서 구동되는 PC 기반 소프트웨어와는 달리 모바일 소프트웨어는 다양한 플랫폼과 해상도에 맞춰 개발해야 하기 때문에 개발자의 많은 노력과 시간이 요구된다.
모바일 소프트웨어는 마우스와 키보드 없이 사용자와 인터페이스를 해야 하기 때문에 UI/UX 관점의 검토도 필요하지만 모바일 소프트웨어에서 가장 주목해야 할 것은 비즈니스 환경이다. 하루에도 수많은 모바일 소프트웨어가 등록되기 때문에 짧은 시간 안에 개발해야 하고, 품질 측정과 테스트도 빠른 방법이어야 한다. 그림1은 앞에서 설명한 내용을 바탕으로 모바일 소프트웨어의 특징을 7가지로 나타내었다.


<그림1> 모바일 소프트웨어의 특징
출처: Design of Quality Evaluation Model for Mobile Application


모바일 소프트웨어의 개발 시간을 줄이기 위해서는 개발이 필요한 부분만 신경 쓸 수 있도록 개발 환경을 표준화 하는 것이 좋지만 대부분의 개발자들은 각자의 방식으로 개발 환경을 구축하여 소스 코드가 잘못 관리되거나 약간의 개발 환경 변화에도 이전에는 발생하지 않던 오류가 나타나기도 한다. 표준화 된 개발 환경은 개발 효율성을 높이기 위해 필요하다는 것을 잊으면 안된다.


2016년 12월 26일 월요일

IBM의 Rational Test Workbench

출처: IBM Knowledge Center
IBM의 모바일 테스트 기능은 Android나 iOS 디바이스에서 네이티브, 웹, 그리고 하이브리드 소프트웨어의 기능과 성능의 테스트 계획, 실행, 그리고 분석을 자동화하는 것을 기본으로 한다.
IBM 모바일 테스트의 목표는 모바일 소프트웨어가 설계와 개발에 필요한 요구사항이 충족되었는지 확인하는 것이다. 이 목표를 충족할 수 있도록 Rational Test Workbench 는 테스트 프로세스에서 그림2와 같은 테스트 스테이지를 구현한다.


<그림2> IBM 테스트 프로세스의 스테이지


<참고사이트>
iOS 시뮬레이터에 모바일 테스트 클라이언트 설치
http://www.ibm.com/support/knowledgecenter/ko/SSBLQQ_8.7.0/com.ibm.rational.test.lt.moeb.do
c/topics/t_install_ios_client.html

(1) 테스트 워크벤치
윈도우(Windows)나 리눅스(Linux), 애플의 맥(Mac) 등에 설치할 수 있고, 특히 기본 컴포넌트는 모바일 앱 테스트를 지원하도록 설계되어 있다. 테스트 네비게이터에는 테스트를 생성하는데 필요한 모바일 수신 레코딩, 테스트 프로젝트, 테스트 및 모바일 디바이스가 나열된다(그림3).


<그림3> 테스트 네비게이터



모바일 소프트웨어의 품질 평가

PC 기반의 소프트웨어와 모바일 소프트웨어의 품질 평가는 근본적인 평가 관점은 유사하지만 모바일 소프트웨어는 그림1의 특징이 있어 저성능 이지만 고효율을 발휘할 수 있는 관점으로 품질을 평가해야 한다. 모바일 소프트웨어의 품질 평가 모델을 정의하기 위해 ISO/IEC 25000의 평가 항목과 모바일 애플리케이션의 특징을 연결하여 6개의 품질 평가 항목으로 정리된다(표1). 자세한 품질 속성과 메트릭에 대해서는 아래 사이트를 참고한다.

<표1> 모바일 소프트웨어의 품질 평가 항목

<참고사이트>
품질 속성과 메트릭의 맵핑
http://www.kpubs.org/article/articleMain.kpubs?articleANo=HOJBC0_2014_v18n10_2451


핀테크 소프트웨어와 오픝 플랫폼

Q: 핀테크 소프트웨어를 개발하기 위해서는 오픈 플랫폼을 이용하면 된다는 말씀이군요. 그런데, 핀

테크 서비스를 은행권에서만 하는 것은 아니지 않습니까?

네, 맞습니다. 오픈 플랫폼을 공동으로 쓰라고 해서 반드시 해야하는 강제 사항은 아니니까요. 은행권 공동 오픈 플랫폼도 금융위원회나 시중 17개 은행만 참여하고 있습니다. 참여하지 않는 곳은 별도의 대안을 마련해야 하는 것이지요.
핀테크 3요소를 살펴본다면, 정의하는 사람마다 다르겠지만 효율성, 편의성, 안정성이라고 말합니다. 많이 건드리지 않고 편하게 쓸 수 있어야 하지만 매우 안정적이어야 한다는 것이죠. 그만큼 핀테크는 신중히 접근해야 합니다.
기존 금융 서비스는 은행과 고객 간 서비스였기 때문에 매우 단순한 서비스 방법을 취했습니다. 고객이 은행가 가거나 인터넷 뱅킹을 통해 원하는 서비스를 받게 됩니다. 하지만, 은행과 고객 사이에 핀테크 서비스가 추가되면서 다중 서비스 개념으로 변하게 되었고, 이러한 변화는 많은 문제점을 가지게 됩니다(그림6).

<그림6> 핀테크의 위험 발생 요인

Q: 새로운 서비스가 추가되면서 그만큼 보안 문제도 발생할 수 있다는 말씀으로 들리네요.

핀테크는 금융 기관 주도로 운용된 것이 사실입니다. 기존 금융 시스템은 대부분B2C를 대상으로 하지만 핀테크 업체까지 대상이 확대되기 때문에 핀테크 금융 시스템은 B2C와 B2B를 모두 고려해야 합니다. 그렇기 때문에, 금융 사고에 대한 위험이 더 많이 존재하고 고객 정보가 외부에서 관리되는 등 정보 보호 문제도 발생할 수 있습니다. 이러한 문제들은 핀테크 관련 규제가 많아지는 가장 큰 요인이 되고 있습니다. 소프트웨어 개발 측면에서 본다면, 여타 시스템보다 훨씬 더 높은 보안 품질을 유지해야 하는 이유이지요.


2016년 12월 23일 금요일

소프트웨어의 테스트 자동화에 대한 장단점 분석


한동안 소프트웨어의 품질을 높이기 위해 QA(Quality Assurance) 활동이 주류를 이루었다. QA의 하나로 가장 주목받는 분야가 테스트라는 것은 누구도 부인하기 어려울 것이다. 그만큼 소프트웨어의 완성도를 확인하기 위해 중요한 활동이 테스트이고, 아직까지도 충분한 만족도를 내지 못하는 분야이기도 하다. 최근에 테스트 자동화를 통해 이러한 한계를 해결하고자 노력하고 있지만, 끊임없는 테스트자동화 도구가 나오는 이유는 아직도 요구를 충분히 만족시키지 못하기 때문일 것이다. 이번 회에서는 테스트 자동화에 대해 국제대학교 김성철 교수를 만나 자세한 얘기를 들어본다.


Q: 안녕하세요. 소프트웨어 테스트에 대한 말들이 요새 더 많이 나오기 시작하는 것 같습니다. 테스트 자동화에 대해 말씀해 주시죠.

테스트는 소프트웨어 개발에 있어 없어서는 안되는 중요한 활동 중의 하나입니다. 소프트웨어라는 것이 처음 나왔을 때부터 지금까지쉼없이 발전하는 분야 중의 하나이기도 합니다. 하지만, 소프트웨어 테스트의 발전은 더디기만 했습니다. 가장 큰 이유는 소프트웨어테스트가 항상 수작업으로 이루어질 수 밖에 없었기 때문입니다. 사람이 할 수 있는 것에는 한계가 있는데 아무리 노력해도 모든 테스트 케이스를 커버하기도 어렵고, 일정한 테스트 수준을 유지하기도 어려웠습니다. 이러한 것을 보완하고자 TDD(Test Driven Development)나 테스트 자동화 같은 분야들이 나오기 시작한 것이죠.

Q: TDD에 대해서는 지난번 185호 인사이드 이슈에서 말씀하셨는데요. 테스트 케이스를 개발하기 전에 만들어 개발한 코드가 정상적으로 동작하는지 미리 확인하자는 것으로 기억하고 있습니다. 그렇다면, 테스트 자동화가 소프트웨어 개발에서 필요한 이유는 무엇인가요?

소프트웨어 테스트는 소프트웨어가 정상적으로 동작하는지를 살펴보기 위해 테스트 데이터를 샘플로 만들어서 개발자가 직접 테스트를 했습니다. 이러한 수작업은 모든 테스트 케이스를 만들 수 없었고 일관된 테스트도 하기 어렵습니다. 그리고, 테스트 계획을 수립할때도 효과적인 테스트 케이스를 만들기 어렵습니다(그림1).

<그림1> 테스트의 효율성과 유효성
출처: http://www.tssg.org/

가장 좋은 테스트는 모든 테스트 케이스를 포함하고 빠르게 테스트가 가능해야 합니다. 그림1에서 보는 것처럼 유효한 테스트가 효율적으로 이루어져야 좋은 테스트가 되고, 좋은 테스트를 통해 안전한 소프트웨어를 완성할 수 있습니다. 표1은 테스트 자동화를 통해 얻을 수 있는 효과를 나타냅니다.

<표1> 테스트 자동화의 효과


Analytic Database 사례



Analytic Database와 DWDB의차이점













SW 특징 - 4차 산업혁명, 품질의 중요도


Real World – 실시간 제어
교통 의료 에너지 전쟁 …
Cost of poor quality (COPQ)

• 도요타의 프리우스 16만대 리콜 2005
• 대량의 방사선 누출 사망 - Therac-25 엑스레이 1985-1987
• 소련 가스 파이프라인 사고 – 역사상 가장 큰 폭발 1982
• 화성탐사선 마리너 1호 - 4분만에 대서양 추락
• 아리안 5 로켓 40초만에 폭발 1996년
• 패트리엇 미사일 -28명의 미국 병사 사망 – 1991
• 심장박동기 오동작 – 미국 메디트로닉스사 - 1994