IT Life

품질보증(QA: Software Testing)으로 기술을 완성하다! (1편)

2014. 6. 3. 10:34

 

안녕하세요! LG CNS 대학생기자단 백종수입니다.

제품 출시 이후 미처 생각지 못한 부분에서 오류가 발생하면 유통이 되었더라도 제품을 회수하거나 교환해 주는 등 큰 홍역을 치르곤 합니다. 더욱이 위험한 물질을 다루는 공장과 같이 사회적으로 규모가 큰 장소에서 예상치 못한 문제가 발생할 경우에는 특히 사람들에게 큰 피해를 줄 수도 있는데요. 오류는 눈에 쉽게 보이는 않는 작은 것에서부터 시작되는 것이 대부분이죠.


따라서 소프트웨어(SW)의 결함에 따른 피해를 최소화하고 기획한 대로 제품과 서비스를 제공하기 위해 오류를 발견하는 테스팅 과정과 품질 검증이 반드시 필요합니다. 


우리에게 친숙한 마이크로소프트나 블리자드 등의 기업들은 하나의 제품 생산에 투입되는 개발비용과 인력만큼 품질검증을 위해서도 할당하고 있다고 하는데요. 기술의 발전과 함께 소프트웨어가 모든 제품을 관장하면서 품질검증의 중요성은 점점 높아지고 있는 것인데요. 오늘은 제품의 질을 높이고 기술을 향상하는 품질보증의 개념에 대해 자세히 알아보겠습니다.

 

그레이스 호퍼(Grace Hopper)라는 프로그램 개발자가 버그(Bug)라는 용어를 컴퓨터에 처음 사용하였습니다. 세계 최초의 범용 컴퓨터의 업그레이드 버전인 하버드 마크 II (Harvard Mark I)의 오류를 컴퓨터 기기 진공관 사이에 들어간 곤충(Bug: 나방)을 제거하여 해결한 데서 그 용어가 시작되었죠. 미 해군 연구소(NSWC: Naval Surface Warfare Center)에서는 이때 제거한 나방을 지금도 전시하고 있다고 하네요. 

현재 우리가 사용하는 ‘버그’라는 용어의 의미는 프로그램의 소스 코드나 설계 과정에서 발생한 실수와 오류 때문에 발생하는 것으로 소프트웨어가 예상한 동작을 하지 않고 잘못된 결과를 내거나, 오류가 발생하거나, 작동이 실패하는 등의 문제를 말합니다. 소프트웨어 버그는 크게 아래의 다섯 가지로 분류할 수 있습니다.


1) 제품 명세서에서 동작하도록 명시된 일을 수행하지 않는 경우

2) 제품 명세서에서 동작하지 않도록 명시된 일을 수행하는 경우

3) 제품 명세서에서 언급하지 않은 일을 수행하는 경우

4) 제품 명세서에서 언급하고 있지는 않지만 해야 할 일을 수행하지 않는 경우

5) 테스터의 관점에서 이해하기 어렵고, 사용하기 힘들고, 속도가 느려 사용자에게 직관적으로 편리하게 보이지 않는 경우


위와 같은 상황을 버그가 발생했다고 이야기하고, 버그 발생을 최소화시키기 위해 테스트를 실시합니다.

 

테스트는 소프트웨어의 성공적인 작업 수행을 방해하는 문제를 발견하기 위해 실행하는 작업입니다. 소프트웨어를 기반으로 하는 제품이 처음 의도한 대로 100% 작동되기란 어려운 일이지만, 테스트를 통해 프로그램 시스템의 안정적인 작동에 대한 확신을 높여가는 것이죠. 이처럼 테스트를 통해 해당 제품의 품질을 높이고 검증하는 일을 품질보증(Quality Assurance)이라 합니다. 즉, 품질보증은 소프트웨어의 ‘프로세스’와 ‘제품’의 품질을 관리하고 향상시켜 고품질로 재생산하는 작업입니다.

고품질 소프트웨어의 판단 기준은 사용자와 개발자 관점에 따라 다른데요. 판단 기준에 따른 내용은 다음과 같습니다.


 사용자 관점

 사용자가 원하는 기능을 제공하여 유용하고 쉽게 쓸 수 있고 신뢰성이 높으며 필요에 따라 계속 발전하는 소프트웨어

 개발자 관점

 좋은 설계 구조를 가지고 쉽게 유지, 보수할 수 있으며 테스트가 용이하고 환경에 맞도록 변경이 가능한 소프트웨어


이렇듯 소프트웨어는 활용에 따라 고품질의 소프트웨어를 판단하는 기준이 다릅니다.

 

그렇다면 좋은 품질의 소프트웨어를 제공하기 위해 어떤 테스트를 거칠까요? 대개는 소프트웨어를 설계하고 구현한 후에 테스트를 진행하는데요. 최근에는 요구 분석 단계부터 테스트를 수행함으로써 버그를 보다 빨리 찾아내고, 버그 발생에 따른 피해를 줄이고 있습니다. 테스트는 총 네 단계에 걸쳐 이루어집니다. 각 단계에 맞게 테스트가 진행되었을 때 그 효과가 빛을 볼 수 있습니다.


 기능 테스팅 

 소프트웨어가 수행하는 기능에 대한 품질 특성 검증

 비기능 테스팅

 신뢰성, 사용성과 같은 비기능적인 품질 특성 검증

 구조적 테스팅

 소프트웨어, 시스템 구조나 아키텍처에 대한 검증

 확인/ 회귀 테스팅

 결함에 대한 수정이 이루어 졌는지에 대한 확인 검증


이 외에도 테스트는 관점에 따라 블랙 박스 테스팅(Black Box Testing)과 화이트 박스 테스팅(White Box Testing)으로 나눌 수 있는데요. 화이트 박스 테스팅은 분석 대상이 되는 SW의 소스코드를 대상으로 취약성이 발생 가능한 패턴을 분석, 점검함으로써 SW가 적절하게 데이터를 처리하는지를 점검하는 방식입니다. 블랙 박스 테스팅은 SW의 입력부에 데이터를 주입하고 SW의 동작을 모니터링하는 방법을 통해 안전성을 점검합니다.


소프트웨어의 안전성을 분석하기 위해서는 분석 대상 SW가 제공해주는 자원의 수준에 따라 분석 방법을 결정하는데 실행프로그램만 제공되는 경우에는 블랙 박스 테스팅을, 소스코드가 제공되는 경우에는 화이트 박스 테스팅을 수행할 수 있습니다.

 

앞서 말씀 드렸듯 각 단계와 주어진 상황에 맞는 테스트는 품질 검증의 효과를 높일 수 있습니다. 따라서 제대로 된 테스트 체계를 확립하는 것은 매우 중요한데요. 테스트 체계가 필요한 이유 중 대표적인 네 가지를 언급하면 다음과 같습니다.


1) 시행착오 감소

프로젝트의 요구 분석 단계부터 품질보증 인력이 투입되면 제품 생산 초기부터 결함을 파악하고 내용을 수정하고 보완할 수 있습니다. 그래서 향후 발생할 문제를 미리 파악하여 해결할 수 있습니다.


2) 인력∙조직 관리의 문제점 해결

테스트의 프로세스가 없거나 체계화되어 있지 않으면 기업이 개발자 개인에게 의존할 가능성이 높습니다. 이처럼 개발자에 대한 의존도가 높아지면 개발자가 회사를 떠날 가능성이 높아집니다. 따라서 테스팅 체계가 확립되어 있어야 인력과 조직 관리를 원활히 할 수 있는 것입니다.


3) 테스트 자체의 효율성 증대

테스트는 소프트웨어의 개발과는 달리 장비와 환경 구축이 절대적으로 필요하며 테스트의 수행을 위한 경험과 테스트에 대한 숙련도가 필요합니다. 이 모든 테스트의 체계가 확립되어 있으면 그렇지 않은 경우에 비해 전체 프로젝트 시간의 30% 정도를 절약할 수 있으며 테스트의 효율과 제품의 질을 높일 수 있습니다. 


4) 커뮤니케이션 효율 증대

테스트의 체계 확립은 개발자, 기획자 및 UX 디자이너의 협업 과정에 있어 원활한 커뮤니케이션을 가능하게 합니다. 테스트 수행 중에는 다양한 문제가 발생할 수 있는데요. 테스트에 대한 정확한 기준과 체계가 없다면 소통 과정에 문제가 발생할 수 있겠죠. 


지금까지 좋은 품질의 소프트웨어와 이를 위한 테스트 방법에 대해 살펴봤는데요. 소프트웨어의 버그를 줄이고 제품의 질을 높이기 위해 테스팅을 통해 품질보증을 하며 이때, 테스트 과정이 체계적으로 확립되어 있어야 효율성을 증대시킬 수 있는 것입니다. 그럼 다음 2편에서는 품질검증을 통한 실제 개선 사례에 대해 살펴보도록 하겠습니다.




Posted by IT로 만드는 새로운 미래를 열어갑니다 LG CNS

댓글을 달아 주세요

위로