개발자가 알아야 할 소프트웨어 품질의 다양한 얼굴 |
 |
 이영석 stone@sqe.co.kr
SOAP, 웹 서비스 등 XML 기반 기술과 BPM을 통한 프로세스 시스템 신봉자로 소프트웨어 품질에 대한 정통부 GS인증 업무를 수행하는 등 개발자 출신 QA라는 흔치 않은 경력을 가지고 있다. 현재 와이즈스톤 대표로, 소프트웨어 품질관리 교육 및 컨설팅 등을 하고 있다.
2007년 9월 11일
|
|
|
|
원론 1은 중요하다. 사전적 의미처럼 근본이 되는 이론이니 얼마나 중요한가. 하지만 재미가 없다. 근본이 되는 이론 이야기는 철학적 정의를 기본으로 진행된다. 그러니 청자(聽者)에게는 재미가 없다. 또 이미 아는 이야기라 생각하니 흥미가 떨어진다. 사람의 자기 합리화는 대단하다. 세부론은 아니더라도 개론 2적으로 낯익은 이야기라면 그 원론은 이미 자신의 것이 된다. 화자(話者)에게도 원론을 이야기하는 것은 재미없다. 들어주는 사람의 반응이 없으니 그 시간과 노력이 얼마나 허무한가. 화자가 가장 신명 나게 이야기할 수 있는 것은 청자의 반응이 느껴질 때라고 하지 않는가.
응용과학의 원론이 되는 수학, 물리학, 화학 등 순수 학문이 외면당하고 있단다. 매력적인 소재로 짧은 시간에 사람의 마음을 사로 잡아야 하고, 빠른 시간에 결과를 확인하고자 한다. 모든 산업에 오락적 접근법(엔터테인먼트)이 요구되는 시대에서 충분히 설명이 되는 현상이다.
소프트웨어 개발에 있어서는 품질론이 그러하다. 중요한 이론이라는 생각은 든다. 또 품질이라는 단어가 낯설지 않다. 개발하는 프로그램의 소스 코드를 놓고 잘 짠 좋은 코드를 논하며 늘 품질에 신경 쓰고 있지 않은가? 하지만 이론적인 품질 세부론을 시시콜콜 이야기할라 치면 소프트웨어 품질론은 지루하고 재미가 없다.
필자는 소프트웨어 품질에 대한 원론적 이야기를 시작하려고 한다. 앞서 재미없고 지루한 이야기라는 것을 밝힌 만큼 참고 읽어주길 바란다. 왜냐하면 바로 원론이기 때문이다.
소프트웨어 품질론의 원론적 이야기
일반적으로 소프트웨어 품질보증(QA: Quality Assurance)의 국제 표준은 '소프트웨어 제품의 품질 평가' 분야, '소프트웨어 제품의 개발 프로세스 평가' 분야, 품질경영체제 도입을 위한 '소프트웨어 품질 시스템 구축' 분야에 대해 진행된다.
그 중 '소프트웨어 제품의 품질 평가' 분야에 대해서는 McCall, Boehm, Deutsch & Willis, IEEE 등에서 연구가 진행되며 그 중에서도 ISO/IEC9126에서 제시하는 모델이 소프트웨어 품질에 대한 표준적인 모델로 인정 받고 있다. 3
ISO/IEC 9126 4은 소프트웨어 품질특성과 척도에 관한 지침으로 제품을 개발하고, 사용하고, 유지 보수하는 관점에서 소프트웨어에 관한 품질특성(characteristic)과 품질 부특성(sub-characteristic)을 정의한다.
6개의 품질특성으로 기능성, 신뢰성, 사용성, 효율성, 유지 보수성, 이식성을 정의하며, 각각의 품질특성은 하부에 여러 개의 품질 부특성을 포함한다. 또 각 품질 부특성별로 세부적인 품질특성 측정 기준 등을 예시하고 있다. 5
ISO/IEC 9126의 소프트웨어 품질특성은 패키지 소프트웨어, 임베디드 소프트웨어, 멀티미디어 소프트웨어 등 모든 소프트웨어의 품질을 포괄할 수 있도록 매우 일반화된 개념으로 정의되어 있다. 이것을 이용하여 프로젝트 시작시에 개발되는 제품 품질에 대한 목표 요구사항을 기술하는 데 사용하거나 개발되는 소프트웨어의 품질을 측정하는 기준으로 사용할 수 있다. 6개의 품질특성에 대해 각 특성이 의미하는 품질의 관점에 대해 살펴보자.
기능성(functionality)
간단하게 말하면 소프트웨어를 통해 제공되는 기능이 개발 전 의도한 대로 정확하게 동작하는지 여부다. 흔히 버그(bug)라고 하는 것이 기능성 측면의 오류다. 우리가 일반적으로 품질이라고 할 때 생각할 수 있는 측면으로 기능성 측면의 오류가 적을 때 가장 좋은 품질의 소프트웨어다. 이는 소프트웨어 품질에 가장 큰 영향을 미치며, 소프트웨어 품질을 분류할 때 크게 두 분류로 기능성과 비기능성으로 나누기도 한다.
기능성의 하위 특성으로는 원하는 기능이 일치하게 제공되는지 여부의 적합성과, 기능의 정밀성을 나타내는 정확성, 시스템간 상호동작 여부를 나타내는 상호운영성, 보안성 등이 있다.
신뢰성(reliability)
특정 환경 아래에서 소프트웨어가 쓰일 때, 소프트웨어가 제공 기능을 계속해서 일정 수준 유지할 수 있는지 여부를 말한다. 가령 사용자의 오조작으로 소프트웨어가 문제를 일으켜 멈춘다면 소프트웨어는 더 이상 이전에 제공하던 기능을 계속 제공할 수 없다. 이러한 상황이 자주 생기는 소프트웨어는 좋은 품질의 소프트웨어라고 할 수 없다. 이러한 문제 상황에서 시스템이 얼마나 잘 버텨서(robust) 내고장성(fault-tolerance)을 유지하는지 여부 등이 신뢰성을 파악하는 하나의 세부 특성이 된다.
신뢰성의 하위 특성으로는 내재된 오류로 인해 문제가 생긴 상황에서 소프트웨어가 얼마나 안전한지 여부를 나타내는 성숙성, 사용자의 오조작 또는 잘못된 값에 소프트웨어가 얼마나 버틸 수 있는지 여부를 나타내는 오류허용성, 고장 발생 후 복구시 고장 발생 전 상황과 얼마나 동일하게 돌아갈 수 있는지 여부를 나타내는 회복성 등이 있다.
사용성(usability)
말 그대로 소프트웨어가 얼마나 사용하기 편한 기능을 제공하는지를 말한다. 가령 한 소프트웨어에서 사용하는 특정 용어가 일관되게 쓰이지 않는 경우 등이 사용성 관점의 문제라 할 수 있다. 즉 "프린트"와 "출력"은 같은 의미를 사용자에게 전달하고자 하지만 일관된 용어를 사용하지 않으면 분명 사용자는 혼란을 느낄 것이다. 팝업창의 "확인"과 "OK"도 마찬가지다. 또한 회원가입을 위해 사용자가 많은 정보를 입력해야 할 때 인터페이스에서 각 필드에 어떠한 값을 입력해야 하는지 혼란스러운 경우, 이를테면 주민번호에 "-"를 넣어야 하는지 여부를 고민할 수 있는 경우에 라벨(label)을 통해 "123456-1234567"이라는 입력 예문을 제공하는 소프트웨어와 제공하지 않는 소프트웨어는 그 사용성에서 차이가 있다고 할 수 있다.
이러한 예처럼 사용자가 소프트웨어 사용에 혼란을 느끼지 않고 편하게 이용할 수 있는 소프트웨어가 좋은 품질의 소프트웨어라고 할 수 있다. 사용의 편이성이라는 것이 정성적(qualitative)인 부분이 커 정량화(quantitative)해 측정하기 쉽지 않다. 하지만 몇몇 구체적인 사례를 항목으로 정리해 체크리스트로 작성해 사용성을 측정할 수 있다.
사용성의 하위 특성으로는 인터페이스가 일관적이고 입출력 값의 예시가 명확해 사용자가 정확하게 소프트웨어의 기능을 이해하고 사용할 수 있는지 여부에 대한 이해가능성, 얼마나 쉽게 기능 사용법을 익힐 수 있는지 여부의 학습가능성, 기능을 사용할 때 그 조작 방법의 일정한 패턴을 제공해 얼마나 쉽게 운영할 수 있는지 여부의 운영성, 사용자 선호에 따라 인터페이스를 조정할 수 있는지 등의 사용자 선호 만족에 대한 선호도 등이 있다.
효율성(efficiency)
우리가 흔히 말하는 소프트웨어의 성능이다. 소프트웨어가 얼마나 빠르게 정보를 처리하는지, 정보를 처리할 때 CPU나 메모리를 어느 정도 사용하는지에 대한 특성이다. 동일한 컴퓨터에서 자료가 빠르게 처리되어 사용자가 결과를 얻으려고 기다리는 시간이 적은 소프트웨어가 좋은 품질의 소프트웨어며, CPU나 메모리 사용량이 적은 소프트웨어가 좋은 소프트웨어다.
효율성의 하위 특성으로는 특정 환경에서 기능을 수행할 때 시간을 기준으로 빠른 반응 시간, 짧은 처리 시간 등의 제공 여부에 대한 시간 효율성과 컴퓨터 자원을 얼마나 적절하게 사용하였는지의 여부에 대한 자원 효율성 등이 있다.
유지 보수성(maintainability)
소프트웨어는 (일반적인 경우라면) 시장에 출시되어 누군가에 의해 운영된다. 소프트웨어 운영 중에는 버그를 고치거나 성능을 향상시키려고 소프트웨어를 수정하고 패치하는 경우가 생긴다. 유지 보수성이란 이러한 경우에 소프트웨어가 얼마나 쉽게 변경되며, 변경 후 문제를 일으키지 않고 안정적으로 운영되는지 등을 말한다. 운영 중 쉽게 소프트웨어를 고칠 수 있고, 변경 후에도 안정적으로 운영되는 소프트웨어가 유지 보수성 측면에서 좋은 품질의 소프트웨어다.
유지 보수성의 하위 특성으로는 운영 중 소프트웨어 문제가 있는 (그래서 변경해야 하는) 부분에 대해 정보를 파악할 수 있도록 하는 기능 제공 여부에 대한 분석성, 소프트웨어 변경을 쉽게 가능하도록 하는지 여부에 대한 변경성, 변경 후 얼마나 안정적으로 운영되는지 여부에 대한 안정성, 빌트인(built-in) 테스트 도구 등의 제공으로 변경된 부분의 테스트를 쉽게 할 수 있는지 여부에 대한 시험가능성 등이 있다.
이식성(portability)
소프트웨어는 특정 환경에서 운영된다. 특정한 환경으로 이식은 사용을 위해 필수 과정이다. 소프트웨어가 정상적으로 운영될 것으로 기대되는 환경에 제대로 설치되는지, 동일한 운영환경의 다른 소프트웨어와 상호 간섭 없이 잘 운영되는지 여부에 대한 능력이 이식성이다. 기대되는 환경에 설치되어 정상으로 운영되고, 다른 소프트웨어와 간섭이 없는 소프트웨어가 이식성 측면에서 좋은 품질의 소프트웨어다.
이식성의 하위 특성으로는 지원하는 운영체제, 데이터베이스, 미들웨어 등 소프트웨어 운영환경 또는 지원하는 CPU, 그래픽카드 환경에서 정상으로 동작하는지 여부에 대한 적응성, 설치시 편의성 제공 여부에 대한 설치 가능성, 동일 운영환경에서 다른 운영 소프트웨어와 간섭이나 충돌 없이 서로 잘 운영되는지 여부에 대한 공존성, 소프트웨어 버전 변경시 이전 소프트웨어와의 기능 및 사용 데이터 등의 차이 정도 여부에 대한 대체성 등이 있다.
개발자에게 도움이 되는 몇 가지 소프트웨어 품질특성에 대한 고찰
여러 차례 번역되어온 기존 번역문, 그리고 (필자가 참여했던) 국내의 표준들과는 다른 관점으로 이해하기 쉽도록 최대한 노력해 이야기를 풀어 보았다. 그러나 역시 지루하고 쉽게 이해가 되지 않았을 수 있겠다. 재미있고 쉽게 이해가 된다면 원론이겠는가?
이제부터 원론을 바탕으로 개발자들이 실제 프로그래밍할 때 소프트웨어 품질을 높이는 데 도움이 될만한 몇 가지 구체적인 소프트웨어 품질 특성 항목을 구체적인 사례와 함께 살펴 보겠다. 먼저 다음의 더하기 함수를 보자.
<![CDATA[
z sum(x, y) {
z = x + y
}
]]>
|
다음과 같이 테스트해 보았다.
(3, 5)를 입력했더니 8이 반환되었다. 그럼 이 코드는 오류를 갖지 않은 코드인가? 다음 값으로 다시 테스트해 보자.
(0, 32768)를 입력한 결과 32768이 아닌, -32768가 반환되었다. 오류다. 그렇다면 어떤 관점의 오류인가? 다음 코드를 보자.
<![CDATA[
short sum(short x, short y) {
z = x + y
return z
}
]]>
|
이 간단한 코드를 통해 몇 가지 오류의 경우를 생각해 보자.
기능성의 정확성
다음의 두가지 상황이 있을 수 있다.
첫째. 처음 프로그램의 사용자 요구 분석시에 16384 > x, y 조건을 만족하는 x, y(32767~-32768 이내의 결과가 예상되는 숫자)만 입력으로 받을 목적이 명시되었다면, 이 코드는 기능적 오류를 가지고 있지 않다는 것이다.
둘째. 만약 프로그램의 사용자 요구 분석시 100,000 단위의 합을 처리하고자 했다면, 이 코드는 기능성의 정확성에 오류가 있다.
이렇듯 사용자 요구 사항에 따라 동일한 코드라도 오류일 수도, 아닐 수도 있다. 그러므로 개발자는 사용자의 요구사항을 명확히 숙지하고 그 요구사항을 만족시키도록 프로그램을 구현해야 한다.
신뢰성의 오류허용성
사용자의 요구사항이 16384 > x, y 조건 x, y의 합의 처리였다고 가정하자. 이 경우 기능성에는 오류가 없지만 소프트웨어의 신뢰성의 문제를 지적할 수 있다. 이유는 처리 가능한 범위 이외의 값이 들어왔을 때 어떠한 예외처리도 준비하지 못했기 때문이다. 때로는 이러한 예외상황이 소프트웨어를 멈추게 할 수 있다. 위의 코드의 신뢰성을 높이려면 다음과 같은 예외적으로 발생할 수 있는 상황에 대한 처리 부분이 고려되어야 한다.
<![CDATA[
short sum(short x, short y) {
// if를 이용한 입력값 검사
// 또는 try catch 예외처리
if(x > 16384 & y > 16384)
return 오류
z = x + y
return z
}
]]>
|
사용성의 이해가능성
만약 위 함수가 GUI를 갖는 경우를 생각해 보자. 다음 코드는 텍스트필드를 통해 더하기 함수로 보내질 두 값을 입력받는다.
<![CDATA[
{
textfield x, y, z
result = sum(x.getValue(), y.getValue())
z.setValue(result);
}
]]>
|
이 코드는 기능적인 문제와는 무관하게 사용성의 이해가능성에 문제가 있다고 할 수 있다. 라벨을 통해 입력하는 값에 대한 정보를 제공해야 사용자는 입력값을 넣을 때 실수를 하지 않는다.
<![CDATA[
{
textfield x, y, z
label a, b
a = "x : 16384 보다 작은 값을 넣으시오"
b = "y : 16384 보다 작은 값을 넣으시오"
result = sum(x.getValue(), y.getValue())
z.setValue(result);
}
]]>
|
즉 다음과 같이 라벨을 통해 입력값의 정보를 전달하도록 코드를 바꿔야 사용성 측면에서도 품질 좋은 코드라 할 수 있다.
후기
필자가 처음 개발 일을 하던 시절에는 개발에 대한 모든 관심이 온통 빠른 개발 방법(예: XP, 애자일 방법론)에만 집중되어 있었다. 그 이후 품질론을 처음 접했을 때 적지 않은 충격을 받았다. 정해진 데드라인을 맞추기 위한 빠른 개발도 중요하지만, 빠른 개발이라는 의미 속에는 그 소프트웨어가 잘 만들어진 소프트웨어여야 한다는 전제가 담겨 있는 것을 새롭게 느꼈기 때문이었다(또한 그 잘 만들어졌다는 평가의 관점이 사용자의 관점이라는 것도). 이후 많은 개발자 후배들에게 기회가 될 때마다 소프트웨어 품질 교육을 받을 것을 권하고 있다. 지금 이 글 또한 테스터보다는 많은 개발자가 읽었으면 하는 바램이다.
그리고 기회가 된다면 꼭 소프트웨어 품질론을 체계적으로 익힐 것을 부탁한다. 품질을 모르는 개발자는 한정된 품질에 대한 관점으로 인해 좋은 품질의 소프트웨어를 개발하기 어려우며, 테스터를 포함한 QA 담당자들과 품질에 대해 원활한 커뮤니케이션이 어려울 수 있다. 더구나 제품을 생산하는 과정에서 개발과 테스트는 한배 안의 운명 공동체이기 때문에 프로젝트 매니저를 희망하는 개발자라면 소프트웨어 품질론은 더욱 필수적인 이수 과정이라 하겠다.
좀처럼 접하기 어려운 품질 관련 국제 세미나가 10월 초에 한국에서 열린다. 이번 ASTA(Asian Software Testing Alliances) 행사에는 전세계 25개국 소프트웨어 테스팅 전문가들이 참석하는 아시아 최초의 세계적인 규모의 행사다. 지금까지 한 번도 소프트웨어 품질에 관한 국제적인 전문가가 한국뿐만 아니라 아시아에서 한자리에 모인 적이 없다. 그런 면에서 이번 ASTA 행사는 국내에서는 소프트웨어 분야의 품질의 중요성을 일깨우고, 대외적으로는 대한민국이 소프트웨어 품질 분야에서 아시아를 선도하고 있다는 이미지를 정립하는 데 큰 도움을 주는 행사가 되리라 생각한다. 다음 번 한국 세미나는 4년 후에나 가능하다는 행사 관계자 말을 들었다. 아무튼 쉽게 오지 않는 좋은 기회를 품질에 관심이 많은 개발자가 활용했으면 하는 바람이다.
다음 컬럼에서는 개발자와 테스터의 커뮤니케이션 방법과 커뮤니케이션 및 테스트의 효율성을 높일 수 있는 솔루션 등에 대해 살펴 보겠다.
주
1 원론[原論]: [명사] 근본이 되는 이론. 또는 그런 이론을 기술한 책.
2 개론[槪論]: [명사] 내용을 대강 추려서 서술함. 또는 그런 것.
3 정창신 외, 소프트웨어 제품 품질에 관한 국제표준화, TTA저널 85호
4 ISO, ISO/IEC 9126-1: Information Technology - Software Quality Characteristics and Metrics - Part1: Quality characteristics and subcharacteristics, 1997
5 TTA, TTAS.KO-11.0049: 패키지 소프트웨어 품질 평가 항목, 2005
 [지난 developerWorks Column 보기]
|
