프로젝트/ITAMS2013.03.26 01:46

본 프로젝트는 SW마에스트로 1기 2단계 과정을 통해 진행하였습니다.


--


소프트웨어 테스팅은 소프트웨어 산업뿐만 아니라 전반적인 IT산업나아가 첨단 산업 전반에 걸쳐 영향을 미치고 있다.


<그림 1. 시스템 또는 제품의 결함에 의한 피해>


과거 오라클의 DBMS인 11g가 프로그래밍 실수로 보안취약성을 드러낸 적이 있다. 간단한 프로그래밍 실수로 인해 발생한 보안 취약점이지만, 프로그램을 수정하고 다시 재배포하기까지는 엄청난 비용이 발생하는 것은 당연한 수순. 이런 실수는 비용 발생에 그치는 것이 아니라 오라클이라는 글로벌 소프트웨어 업체의 위상에도 심각한 타격을 주는 것이다.


“오류 없는 소프트웨어 없다”는 개발 내 격언처럼 오류 없는 완벽한 소프트웨어는 한 번도 출시되지 않았으며, 이를 개발할 수 있는 개발자 또한 현재까지 존재하지 않는다. 이 때문에 소프트웨어의 오류를 발견하고 이를 수정하기 위해서는 또 다른 작업이 필요한데, 이것이 바로 소프트웨어 테스팅이며, 이는 소프트웨어 개발 과정 상 필수적인 요소다.


또한 그간 소프트웨어 제품들은 전통적인 소프트웨어 영역에서는 오류가 발생해도 사용자의 이해와 함께 빠른 패치를 통해 커버할 수 있었지만, 최근 첨단 산업 군에서 소프트웨어 비중이 높아짐에 따라 소프트웨어 오류는 커다란 나제로 부각됐다.


미션 크리티컬한 기업용 애플리케이션이나 휴대폰, 자동차, 항공기, 가전제품 내부에서 오류가 발생하면 기업 업무가 마비되거나 대규모 리콜사태, 심지어는 항공기 추락과 같은 엄청난 사건이 발생할 수도 있다. 가전제품이나 휴대폰 자동차의 대규모 리콜 사례의 원인을 분석해보면 내장된 소프트웨어 문제가 대다수였다는 점은 이제 잘 알려진 사실이다.


자동차의 신형 모델에는 80개 이상의 CPU가 탑재되고, 수없이 많은 소프트웨어가 내장돼 자동차를 제어하고 고급 기능을 수행한다. 최근 자동차 리콜의 경우 많은 원인이 소프트웨어 결함으로 판명됨에 따라 소프트웨어의 품질 향상에 심혈을 기울이고 있고 그 핵심에는 소프트웨어 테스팅이 자리하고 있다.


이렇게 판매 이후에 발생하는 문제 외에도 소프트웨어의 오류는 제품 출시 시기까지 영향을 미치고 있다. 그래서 기존에는 제품 양산 직전에 테스트가 이뤄지는 것이 대부분이었는데, 그런 테스트만으로는 소프트웨어가 가질 수 있는 문제점을 커버할 수 없다는 인식이 생기게 됐고, 소프트웨어 개발 프로세스 과정에서부터 개발이 끝난 제품의 소프트웨어까지 오류를 사전에 진단하고 정상 작동 여부를 시험하는 전사적인 테스팅의 중요성이 점점 부각되고 있다.



<그림 2. 오류에 따른 수정 비용>



<그림 3.결함의 이해>


[그림. 2]는 소프트웨어 개발 과정에서 결함을 바로 잡는 데 드는 비용이 단계가 빠를수록 적게 든다는 점을 잘 나타내 주고 있다. 이와 함께 [그림. 3] 은 소프트웨어 주요 결함 중 대다수는 요구사항 정의와 설계 단계에서 발생하지만, 이런 결함을 발견하는 것은 사용자 인수 테스트 단계에서 발견하게 됨으로써 시간과 비용 측면에서 많은 누수현상이 생김을 알 수 있다. 


* 소프트웨어 개발 수명 주기에 따른 테스팅 이론은 다음 링크를 참조한다.




<그림 4. 소프트웨어 테스팅 수명 주기>


[그림. 4] 과 같이 기존의 테스트 개념이 테스트 수행이라는 수면 위로 드러난 빙산의 일부분 이였다면, 테스트 계획과 제어, 분석과 설계, 평가와 마감 등과 같은 수행 이전 단계와 이후 단계는 수면 밑에 보이지 않는 거대한 부분이라고 할 수 있다.


즉, 소프트웨어 오류를 찾아내는 것이 테스팅의 목적이라면, 좀 더 적은 비용으로 오류를 찾아내기 위해 테스트 수행 이전 단계에서부터 테스팅의 범주에서 진행해 프로젝트 수행 이후까지 포함 한다는 결론에 이르게 되었고, 이런 개념의 확장은 테스팅 업계가 마케팅 차원에서 확장시킨 것이 아니라 고객들의 필요성과 수요에 따라 확장된 것이라 할 수 있다.


완벽한 제품이나 소프트웨어를 만들기 위해서는 모든 부분을 철저하게 테스트하고 관리하면 되지만, 지금까지 오류 없는 완벽한 소프트웨어는 한 번도 출시되지 않았으며, 이는 현실적으로 유한한 리소스(시간, 비용)를 가지고 제품 또는 소프트웨어의 모든 부분을 테스트하는 것은 불가능하다는 것을 의미한다.


그래서 소프트웨어 테스팅의 주요 방법론으로서 리스크 기반 테스팅(Risk Based Testing) 을 꼽을 수 있다. 리스크는 테스팅을 시작하는 시점을 결정하고, 더 강력하고 깊이 있게 테스트할 부분을 결정하기 위해 사용될 수 있으며, 리스크 제어 활동으로 프로젝트 초기 단계부터 리스크에 미리 대처할 수 있게해 제품의 리스크 수준을 줄여나갈 수 있다.


* 리스크 기반 테스팅 기법은 다음 링크를 참조한다. - http://lyb1495.tistory.com/102


그럼 리스크는 과연 무엇인가? 리스크에 대한 정의는 다음과 같다.


  • P(f) 어떤 기능에서 결함의 발생 가능성을 의미하는 Likelehood로 표현된다.
  • C(f)는 결함이 발생되었을때 비즈니스에 끼치는 영향도를 의마하는 Impact로 표현된다.
  • 그리고 리스크는 이들 두가지 요소의 곱으로 최종 산출된다.

<그림 5. 리스크의 정의>



리스크 기반 테스팅의 전반적은 흐름은 다음과 같다.


<그림 6. 리스크 기반 테스팅 프로세스>


즉, ITAMS(Integrated Testing Asset Management System)
는 리스크 기반 테스팅 기법에 근거해 요구사항, 리스크 데이터, 테스트케이스 등 테스팅 자산을 전사적으로 관리해주며, 프로젝트의 리스크가 무엇이고 그것들의 우선순위를 식별하도록 돕는 솔루션이다.

  • 요구사항, 테스트케이스, 결과 등 테스팅 자산관리 시스템
  • ISO/IEC 29119 및 TMMi 에서 제안하는 프로세스를 구현하기 위해 구체적인 리스크 기반 테스팅을 제공
  • 리스크와 결함 분석을 통한 의사결정 지원 데이터 제공
  • UI와 데이터를 가장 효율적으로 분리할 수 있는 최신의 소프트웨어 아키텍처 적용
  • 요구사항에 대한 Traceability 제공
  • 모바일 디바이스 지원


ITAMS의 주요 구동 화면은 다음과 같다.


<그림 7. 리스크 분석>


[그림. 7]은 정해진 내부 이해 관계자가 개인적으로 리스크를 분석하고 평가하기 위한 화면이다.


모든 이해 관계자가 개인별 리스크 평가를 완료하였다면, 정해진 이해 관계자가 모여 리스크 평가 결과를 공유하고 협의를 이끌어 낸다. 이해관계자는 서로 다른 시각을 지니고 있으므로 동일한 리스크에 대해 리스크 평가 결과가 다른 경우가 훨씬 많다.


<그림 8. 리스크 데이터 시각화>


[그림. 8]은 분석된 리스크들의 커버리지 챠트 및 리스크 매트릭스이다. 


커버리지 챠트에서는 프로젝트의 리스크와 각 리스크에 할당된 리소스를 분석할 수 있다. 리스크가 높은 영역에는 상대적으로 많은 리소스(TC, 고급인력, 시간 등)가 할당 되어야 한다. 이와 같은 차트를 통해 리소스가 많이 투입되어야 하는 영역에 리소스가 올바르게 할당 되었는지, 낭비되고 있는 리소스가 존재하는지 확인할 수 있다.


일반적으로 테스팅은 제한된 시간과 자원을 가지고 수행되기 때문에 리스크의 우선순위에 따라 테스팅을 진행해야 효과적인 테스팅을 수행할 수 있다. 리스크 매트릭스는 리스크를 4가지 영역으로 구분하고 각 영역에 위치한 리스크가 무엇인지 확인할 수 있는 차트이다.


  • STA(Servere Test Area) : 가장 강도 높게 테스트 해야 하는 영역
  • ITA(Intensive Test Area) : 테스트 가치가 있음
  • STTA(Strong Test Area) : 테스트 가치고 있고, 테스트를 해야함
  • FTA(Fundamental Test Area) : 테스트할 수 있음


<그림 9. 결함 S커브>


[그림. 9]는 결합의 분포비율과 처리상태, 결함 S커브를 확인할 수 있는 화면이다.


결함 S커브는 프로젝트의 개발 기간 동안 발견 된 결함의 개수와 해결된 결함의 관계를 나타내는 그래프이다. 전형적인 결함 추이 그래프는 S곡선을 그리게 되는데 이는 프로젝트가 막바지에 이르게 될수록 발견되는 결함의 개수는 적어지고 해결되는 결함의 개수가 많아져 프로젝트의 종료 시점에는 남은 결함의 개수와 해결된 결함의 개수가 일치하게 되는 것을 의미한다.  


<그림 10. 리스크 매트릭스 구분에 따른 결함 S커브>


[그림. 10]는 결함 S커브를 리스크 매트릭스의 영역별로 확인할 수 있는 화면이다.


의사결정자는 위와 같은 데이터를 통해 제품 출시 일정에 대한 계획을 할 수 있다. 예를 들어 심각한 결함을 의마하는 STA영역에서 결함이 지속적으로 발견되고 있고, 결함 해결 추이가 지연되고 있다면 당연히 제품 출시를 미룰수 밖에 없을 것이다.


<그림 11요구사항에 대한 Traceability>


[그림. 11]은 프로젝트 요구사항에 대한 리스크 아이템, 테스트슈트, 테스트 케이스, 결함 등에 대한 연관 정보를 나타낸다.



<그림 12전체적인 화면 구성>


소프트웨어 테스팅이 소프트웨어 품질관리 있어서 필수 조건이라는 점을 인식하면서도 제대로 테스팅을 하지 않는다는 것은 자사의 제품 품질에 관심은 있지만, 향상시키지는 않겠다는 것과 마찬가지다. 글로벌 경쟁 시대에 접어들면서 품질에 대한 중요성이 나날이 증대되고 있으며, 각 산업에서의 시장 상황 또한 이를 반영해 준다.


소비자들은 이미 품질에 대해 눈을 뜨기 시작했으며, 인터넷을 통해 이런 정보를 실시간으로 공유해가고 있다. 단적인 예로, 온라인 게임의 경우 클로즈베타를 할 경우 예전엔 각종 오류나 미완성 부분에 대해 많이 격려하고 완성도를 높이기 위해 소비자들이 적극적으로 참여했지만, 현재는 유료화 단계의 서비스 품질이 아니면 시장에서 살아남을 수 없다.


 소프트웨어 테스팅 업계 관계자는 “그렇다고 무작정 소프트웨어 품질을 턱없이 고도화하자는 주장이 아니며, 제품 출시 때 자사가 필요한 소프트웨어 품질 수준만큼의 시간과 비용을 투자하라는 것”이라고 설명했다. 소프트웨어 품질은 테스팅에 소요된 시간과 비용만큼 비례하는 경향이 있지만, 어느 수준에 이르게 되면 더 이상 올라가지 않는 한계가 있다.


 STA의 권원일 대표는 “업계에서 테스팅에 관심 있는 개발자와 테스트 엔지니어 등을 대상으로 교육을 진행하다 보면 수강자들이 테스팅에 대해 너무 단편적으로 알고 있다는 것에 놀라곤 한다”고 전했다. “테스팅의 가장 중요한 개념인 테스트 커버리지(Test Coverage)에 대한 개념을 제대로 이래하고 사용하는 이는 거의 없고, 그나마 알고 있는 테스팅 개념과 기법들을 적용하고 있는 경우는 더 찾아보기 힘들다”고 토로했다.


ITAMS와 같은 솔루션을 통해 ISO/IEC 29119와 같은 테스팅 국제 표준을 국내에 소개하고, 나아가 SO/IEC 29119에 기반하고 Risk Based Testing 기법을 지원하는 통합 테스팅 솔루션으로 자리 잡아 소프트웨어는 물론 자동차, 항공기, 의료 등과 같은 첨단 산업분야에서도 고객과 성공하는 프로젝트를 만들어가는 것을 기대한다.



* 프로젝트에 도움을 주신분들









'프로젝트 > ITAMS' 카테고리의 다른 글

프로젝트 개요  (0) 2013.03.26
리스크와 테스팅  (0) 2013.03.26
소프트웨어 수명주기와 테스트 레벨  (0) 2013.03.26
소프트웨어 수명주기와 테스팅  (0) 2013.03.26
Posted by devop

댓글을 달아 주세요