사진으로 보는 소나무 가족의 행복한 이야기

테스트설계의 관점과 테스트기법

테스트설계의 기본을 이해하기 위하여 필요한 중요관점은 다음과 같다.
① 보다 적은 테스트케이스로
② 보다 많은 버그를 찾을 수 있도록 하여
③ 테스트대상을 빠짐없이 실행한다.
이들을 충족하는 테스트설계를 하기 위하여 테스트기법을 활용할 필요가 있다.
여기서는 몇 가지 기본적인 테스트기법과 모델베이스 테스트기법의 개념을 소개한다. 테스트기법에 대하여 상세한 것을 알고 싶으면, Boris Beizer의 “Software Testing Techniques” 의 참조를 권한다.

“보다 적은 테스트케이스”로 테스트하기 위해 필요한 요점은 기본적으로 “동등클래스(Equivalence class)” 를 들 수 있다. 동등클래스는 테스트에 사용되는 입력 값이 같은 결과를 갖는 경우, 그 입력 값을 “동등” 하다고 부르는 데서 연유했다. 예를 들면, 한자리의 정수(整數) 2개를 합산하는 프로그램이 있다고 하자. “1+1” “1+2”…처럼 모든 정수의 패턴을 빠짐없이 테스트하려고 한다면, 9×9 =81 패턴의 테스트를 생각할 수 있다.
이 경우, 한자리 숫자와 한자리 숫자를 합하여 정수가 결과로서 나오게 되는 것뿐임으로, “1+1=2”가 나왔다면 논리적으로 “2+2”, “3+5”와 또 다른 것도 바른 결과가 나올 것이다. 즉 이 합산처리는 같은 결과를 갖는다고 할 수 있을 것이다. 이와 같이 모든 입력이 같은 결과를 갖는 경우, 그 중 대표 몇 개를 뽑아서 테스트한다면 81회나 테스트하지 않아도 된다고 생각할 수 있다. 이 같은 발상을 기초로 하여 같은 성질을 갖는 값을 모아서 취급 함으로서 보다 적은 테스트케이스로 테스트할 수 있게 되는 것이다.

“보다 많은 버그를 찾기” 위한 기본적인 기법으로는 “경계 테스트(Boundary Test)”를 들 수 있다. 위의 동등클래스중에서 대표를 뽑을 때 가장자리, 즉 경계 값을 뽑기 때문에 이렇게 부르게 되었다. 왜 경계 값을 대상으로 한 테스트로 많은 버그를 찾을 수 있는지 생각해 보자. 그 이유는 의외로 간단하다. 경계 값의 정의는 요건분석에서 프로그래밍에 이르기까지 어느 단계에서도 착각하거나 틀리기 쉽기 때문이다. 예를 들면, 부등호인 “>” 와 “=>” 를 잘못 정의하여 틀리는 경우는 쉽게 발견되는 것들이다. 만일, 어떤 숫자”이상”으로 되어 있는 것을 개발자가 “미만”으로 생각하여 코딩 했다면, 경계 테스트에서 간단히 버그로 발견되었을 것이다.
“부등호의 틀림”이란 단순한 착오정도는 테스트대상으로 생각하지 않았을 경우가 있었다면, 그런 테스트를 하지 않음으로서 생기는 결과는 후에 뼈아픈 상황을 불러올 수도 있다. 이런 불행을 예방하기 위한 테스트가 경계 테스트이다.

그러면 모델베이스(Model-based) 테스트설계에 대해 생각해 보자. “테스트대상을 빠짐없이 실행” 하기 위한 기법으로는 테스트대상의 요건(Specification)을 모두 나열하여 테스트누락을 방지하기 위한 “리스트 커버” 나 테스트요소를 행(行)과 열(列)의 표로 표현하여 같은 효과를 내려는 “매트릭스 커버” 가 있다. 또 단순한 방법으로는 표현하기 어려운 요건, 즉 모델화된 요건을 테스트하기 위해 사용되는 것이 모델을 베이스로 한 테스트기법이다. 설계서 등으로 테스트설계 전에 모델이 존재하고 있는 경우도 있고, 테스트를 설계하는 엔지니어가 설계서 등을 보고 테스트를 위해 모델링하는 하는 경우도 있을 것이다.

여기에 많이 사용되는 대표적인 기법으로 상태천이 테스트(State-transition Test)를 들 수 있다. 이것은 소프트웨어의 동작을 UML(Unified Modeling Language)에서의 상태 챠트(State charts)와 같은 모델로 표현하여 그 노드(Node)와 링크(Link)를 모두 대상으로 하여 테스트하는 것이다.
휴대전화의 예를 들어보자. 휴대전화는 수신대기 상태인 때에 전화가 걸려오면 착신상태가 되고 착신음이 울린다. “착신중에 착신음이 울림” 이란 상태(노드)는 “전화가 걸림” 이란 이벤트(링크)에 의해 인도된다. 그러나 통화중이라면 “전화가 걸림” 이란 이벤트(Event)가 있어도 착신음이 안나고 캐치상태가 된다.
이와 같이 같은 이벤트라도 앞의 상태에 따라 다음에 “천이(遷移)” 되는 상태가 달라진다. 따라서 “앞의 상태와 이벤트” 별로 인도되는 상태가 바른 결과가 되는지를 모두 테스트하지 않으면 안 된다. 모델을 사용하여 이를 빠짐없이 실행하려는 것이 “상태천이 테스트” 이다. 모델베이스 테스트에 대해서는 Microsoft사 Harry Robinson운영의 Web사이트(www.geocities.com / model_based_testing )를 참조하기 바란다.

그런데 사람이 일일이 테스트하는 것은 시간의 제약으로 무리한 경우가 있다. 실제로 상태천이 표(State-transition Table)에 따라 테스트를 설계하면 테스트항목이 수천이나 수만개가 되기도 한다. 그래서 테스트실행을 자동화하여 대량의 테스트케이스를 소화하거나 테스트케이스의 수를 논리적으로 줄이는 방법{직교표(直交表)가 이에 해당}을 취하기도 한다.
상태천이모델인 경우, 모델화 함으로서 이벤트와 액션 상태가 논리적으로 명확하게 된다. 또 논리적으로 정의되어 명백해짐으로 테스트케이스를 자동 생성할 수 있게 된다. 이에 입력데이터와 기대출력결과가 있으면 테스트의 자동실행도 가능하게 된다.(시판의 테스트 툴에도 이런 기능의 제품이 있다.)

다음으로 테스트케이스의 수를 줄이는 방법인데, “보다 많은 버그를 찾을 수 있는” 테스트케이스를 선택하여 우선적으로 실시하는 방법을 생각해 보자. 이를 위해서는 모델중에서 버그가 나올 것 같은 곳을 찾을 필요가 있다. “변칙 경로(Path)”라 불려지는 불규칙적인 패턴을 찾는 방법도 있다.
불규칙적인 패턴이란 바르게 처리되지 않고 오류로 되어 있을 때의 패턴(예외처리) 등을 말한다.
버그의 경향을 분석하여 어떤 잘못을 하기 쉬운가를 찾는 방법도 있다. 이것은 실제의 버그발생경향이 프로젝트에 따라 여러 가지라는 것에 기초를 두고 있다. 버그를 분석해 보면 특정부분(기능이나 모듈)에 버그가 집중되어 있는 경우가 많다. 그 원인은 여러 가지 있겠지만, 개발담당자가 자주 교체되었거나, 검토가 부족한 상태에서 코딩에 들어갔거나, 개발자 개인의 자질에 따른 경우 등인데 결국은 인적요인, 외적/내적요인 등으로 나누어진다.
버그의 발생원인에 경향이 있다면, 이를 분석해 보면 그 특정부분을 찾아낼 수 있다. 결국 버그가 많은 테스트대상의 약점을 집중적으로 테스트함으로서 효율적으로 버그를 찾아낼 수 있게 되는 것이다.

테스트케이스의 자동생성이나 자동실행을 하거나, 하지않거나 간에 모델베이스로 테스트설계를 한다는 것은 합리적으로 망라성(網羅性)을 확보하기 위한 필수적인 테크닉이라 할 수 있다. 예를 들면, 시스템테스트에서 행하여지는 업무흐름이나 이용자수순에 따른 테스트에서는 업무흐름을 Flow-chart 또는 UML에서의 Use case diagram이나 Activity diagram으로 표현하여 모델화한다. 모델화된 요건을 테스트하기 위해서는 그에 따른 테스트기법이 필요하게 된다.
이에는 제어경로(Control-path)테스트를 들 수 있다. 이는 프로그램의 동작경로를 흐름으로 표현한 것을 모두 실행하기 위한 테스트, 즉 코드를 모델화하여 테스트를 실행하는 것이라 할 수 있다.

모델베이스의 테스트기법을 이용하려면 테스트를 설계하는 엔지니어자신이 요건이나 설계서에 있는 모델을 이해하거나, 모델이 없다면 거기서 테스트에 필요한 모델을 도출하는 능력이 필요하게 된다. 빈약한 모델을 기초로 테스트를 설계하면 빈약한 테스트케이스밖에 나오지 않게 될 것이기 때문이다.
한편, 모델베이스 테스트설계에도 한계가 있다. 특히 성능이나 안전 등의 비 기능요건은 모델에서 표현되지 않아 대상이 되지 않는다. 따라서 사람이 아니면 안 되는 고도의 검증은 여기서도 남게 된다. 모델베이스로 테스트를 설계하여 테스트하는 엔지니어는 이제까지 보다 더 많은 모델링 기술이 요구될 것이다.

[주]STEN과 같은 역할을 하는 일본의 TEF(Testing Engineer’s Forum, www.swtest.jp)에서도 소프트웨어테스트 심포지움이 열리고 있고, 이 실행위원회에는 대학을 비롯하여 컴퓨터메이커, 관련기업 등에서 참가하고 있다. 위 글은 그 실행위원들의 토론모임에서 나온 화제(2004.12.3)를 공개(www.atmarkit.co.jp)한 것 중에서 골라 소개하는 것이다. 테스트설계의 관점을 이해하는데 도움이 될 것으로 생각된다. 
 
김증모

시스템 공학의 개요
소프트웨어 공학의 생명주기(life cycle)
소프트웨어 확인 및 검증(V&V : Verification and Validation)
형상관리(CM : Configuration Management)개요
형상관리의 내용
형상관리의 기능 및 과정
참고문헌

원전소포트웨어 확인 및 검증

 

충남대 정보통신공학부

V&V 개요(확인 및 검증 개요)
소프트웨어 생명주기와 V&V
V&V 문서
형상관리

Maincolumn --> //Bottom Menu -->날로 경쟁이 심화되는 IT 분야에서 우리는 소프트웨어의 경쟁력이 바로 IT 비즈니스의 경쟁력으로 인식되는 시대에 살고 있다.

하루라도 더 빨리 조금이라도 더 나은 제품을 개발하기 위해 정신없이 쫓기는 개발 일정과 복잡한 기술 사이에서 프로젝트는 자칫 길을 잃고 표류할 수 있다. 소프트웨어 형상관리는 모두가 정신없는 와중에 묵묵히 그 중심에 앉아 기준을 잡아주는 조타수와 같은 존재다.

소프트웨어 형상 관리(Software Configuration Management, SCM)는 최근 몇 년 사이에 소프트웨어 품질의 관점에서 아주 중요하게 다뤄지고 있는 분야이다. 특히 프로젝트의 규모가 커짐에 따라, 혹은 프로젝트에서 품질의 요소가 아주 중요한 위치를 차지하고 있는가에 따라 소프트웨어 형상 관리는 그 중요성이 더욱 부각되고 있다.

미국 카네기 멜론 대학의 SEI 연구소에서 개발한 CMM(Capability Maturity Model)과 같은 품질 프레임워크에서는 특정 성숙도 레벨로 진입하기 위해서 반드시 수행해야 할 활동으로 보고 있다.

하지만 현실은 몇몇 대규모 프로젝트나 공공 프로젝트와 같은 엄격한 품질 기준을 적용하는 곳 이외에는 본격적으로 형상 관리 활동을 하는 프로젝트는 사실 별로 많지 않다. 심지어는 소스코드에 대한 버전 관리를 소프트웨어 형상 관리와 같은 의미로 알고 있는 개발자들도 상당수 있다. 버전 관리는 형상 관리의 일부분으로 같은 수준이 아니다.

소프트웨어의 가장 큰 특징은 변경이고, 이 변경으로 인해 소프트웨어라는 이름에 걸맞지 않게 개발과 유지보수를 아주 어렵게 만들어 버린다. 물론 변경이라는 소프트웨어의 큰 특성을 무시할 순 없다. 무시할 수 없기에 수많은 사람들이 이 '변경'이라는 난코스를 슬기롭게 헤쳐나갈 수 있도록 수많은 연구를 해 왔다. 그 중에 하나의 해결책이 바로 소프트웨어 형상 관리이다. 지금부터 소프트웨어 형상 관리에 대해 알아보자.

어느 개발팀의 이야기
약 3개월 기한으로 시작한 프로젝트는 2개월 하고도 반이나 지났지만 도통 끝이 보이지 않는다. 프로젝트 관리자이자 아키텍트를 맡고 있는 고 과장은 하루하루가 마음 졸임의 연속이다. 처음 시작할 때만 해도 비교적 작은 규모의 시스템이었기 때문에 3개월 정도면 무난하리라 생각했다. 그래서 별다른 관리 체계도 만들지 않고 인원도 4명이라 그저 얼굴보고 이야기하면서 개발하면 되리라 생각했다.

하지만 프로젝트가 점점 수렁에 빠져드는 듯한 느낌을 받기 시작한 것은 약 1개월 정도가 지나서였다. 갑자기 어느 팀원이 건강상의 이유로 회사를 퇴사해 버리고 그가 맡은 업무는 전부 중지되어 버렸다. 부랴부랴 사람을 수소문해서 채워놨지만 제대로 된 문서 하나 만들어 놓지 않았기 때문에 몇 명 되지도 않는 팀에서 한 명을 뽑아 신입 팀원의 교육을 3일간 맡아야 했다.

이런 일이 있은 후에 부랴부랴 고 과장은 당장 필요한 요구사항에 관한 산출물과 설계 산출물을 작성하기 시작했다. 물론 이런 산출물의 작성 기간은 프로젝트 기간에 들어있지 않았기 때문에 프로젝트 지연을 막고자 거의 1주일간을 밤샘 작업을 해야만 했다.

문서작업 후 어느 정도 프로젝트가 잘 굴러가나 싶었는데 더 심각한 문제는 약 2개월 정도가 지난 다음에 나타났다. 주요 기능과 프레임워크를 개발하고 난 뒤 고객에게 시연해야 하는 시기가 되어 바쁘게 준비를 하고 있었다. 그런데 팀에 마가 끼었는지 한 팀원의 컴퓨터가 바이러스에 감염되어 그 안에 있던 모든 소스코드와 각종 스크립트가 한 순간에 날아가 버렸다.

산출물을 한군데 관리하지 않고 문서 종류만 중앙 파일 서버에 관리한 채 각자의 소스코드는 개별 PC에 저장해 놓고 개발하는 형태로 진행했던 것이 화근이었다. 그때까지만 해도 각자의 소스코드를 파일 서버에 올리는 것은 각 개발자의 부지런함에 맡겨놓고 있던 실정이었다. 바이러스에 감염되어 소스코드를 전부 잃어버린 개발자는 그 중에서 가장 부지런하지 않던 사람이었다.

그나마 파일 서버에 올려놨던 가장 최근의 소스코드를 받아 새로 만드느라 또다시 철야 근무를 하며 며칠을 보냈고 고객의 신뢰는 점점 없어지고 있었다. 충격을 심하게 받은 개발팀은 CVS(Concurrent Versions System)라는 오픈소스 버전 관리 도구를 파일 서버에 설치하고 모든 문서와 소스코드, 스크립트를 CVS에 등록했다. 프로젝트가 거의 끝나가는 시점에 개발 도구와 CVS를 연동하여 본격적인 개발 환경을 그제서야 만들었다.

이제는 갖출 것은 다 갖췄다고 생각한 개발자들은 남은 한달 바짝 해서 구겨진 프로젝트를 그나마 본궤도에 올리려고 그야말로 화장실 가는 시간도 없이 열심히 일을 했다. 하지만 운명은 그들을 그냥 놔두지 않았다. 프로젝트가 거의 종료되어 갈 시점에 팀을 절망하게 만드는 상황이 발생하기 시작했다.

규모는 작지만 영어와 중국어를 지원해야 하고 국내에서도 여러 곳에서 운영되어야 하는 요구사항이 있었다. 개발이 거의 완료되었다는 소식을 들은 고객은 본격적으로 영업을 하기 시작했고, 미국과 중국을 비롯해 국내 여러 곳에 시스템을 배포해야 한다는 요청을 했다. 시스템이 고객사로 인도되기 시작하면서부터 다양한 요구사항들이 쇄도하고 개발팀은 그 요구사항에 맞춰 그때그때 소스코드를 수정해 나가기 시작했다.

그런데 문제는 시간이 지남에 따라 각 고객사별로 소프트웨어의 버전이 차이가 나면서 어떤 고객사의 요구사항이 어떤 버전인지 도저히 알 수 없는 지경에 이르게 되었다. 소스코드가 점점 누더기로 변해 갔고 이전에는 없었던 버그가 하나 둘씩 나타나기 시작했다. 그저 매일같이 소스코드 한 줄 한 줄 따라가며 끔찍한 디버깅 작업을 끝도 없이 해야 했다.

만약 형상 관리의 분기와 병합, 베이스라인, 베이스라인 프로모션(baseline promotion), 변경 추적과 형상 감사와 같은 개념을 알고 활용했다면 변경에 대한 요청에 체계적으로 대응하여 매일같이 새롭게 등장하는 버그와 씨름하지 않았어도 됐을지 모른다.

지금까지 형상 관리를 하지 않고 별다른 문제없이 개발을 끝냈다면 분명 운이 좋은 경우라 할 수 있지만 아마 이런 경우를 한두 번씩 겪었으리라 생각된다. 만약 고과장의 팀이 프로젝트를 시작하면서 간단하게나마 소프트웨어 개발 프로세스를 정립하고 프로젝트 상황에 맞게 형상 관리 계획을 세웠으면 어떠했을까? 아마 이런 어이없는 일이 일어날 확률은 많이 줄어들었을 것이다.

결론적으로 형상 관리는 소프트웨어 개발을 확실하게 도와준다. 부가적으로 수행해야 할 활동이 늘어나긴 하지만 분명 그 이상의 효과를 볼 수 있다.

뭔가 만드는 곳은 변경을 관리한다
소프트웨어를 개발하는 일과 자동차를 만드는 일은 다르지만 수많은 부분으로 구성되고 많은 사람들이 참여하여 만든다는 본질은 유사하리라 생각된다.

자동차 한 대는 최소 구성단위로 완전히 분해할 때 2만개의 부품으로 구성되고 거기에 부품 번호를 부여한다. 하나의 단가를 구성해 관리하는 엔드 아이템(end item) 단위로 보면 수천여 개의 부품이 들어간다고 한다. 자동차 회사에서는 이렇게 많은 부품을 관리하기 위해 각 부품을 부분별로 구분하고 각 부품간의 관계를 정의한다. 이를 보통 BOM(Bill of Material)이라고 하여 산업공학에서는 커다란 연구 분야로 꼽는다.

자동차 회사에서 이렇게 수많은 부품으로 구성되는 자동차를 개발하기 위해서는 아주 철저한 개발 프로세스를 적용한다. 자동차의 초기 컨셉이 정해지고 나면 그것에 디자인과 각 부분별 설계가 진행되고 모델고정 시점이 되면 프로토타입 차, 시작 차와 같이 실제로 자동차를 만들어 테스트를 실시한다.

자동차 각 부분에 대한 부품설계 및 디자인을 진행하는 와중에도 지속적인 설계 변경이 일어나게 된다. 자동차 회사 역시 설계 변경을 관리하기 위해 엄격한 형상 관리(물론 자동차 회사에서는 형상 관리라는 말은 쓰지 않는다)를 적용하고 있다.

하나의 변경이 발생하기 위해서는 ECO(Engineering Change Order)를 발행하고, 변경에 따른 영향도 분석은 관련 부서의 협력을 통해 얻어내어 최종 결정을 한다. 자동차 회사에서는 이와 같은 변경 프로세스를 아주 철저히 지키며 그 누구도 귀찮다거나 쓸데없는 일 때문에 개발 기간이 늘어난다고 생각하지 않는다.

오히려 프로세스가 없다면 제대로 된 자동차 설계가 되지 않을 것으로 생각한다. 비단 자동차 회사뿐만 아니라 무엇인가 만드는 곳에서는 변경을 아주 중요하게 생각하고 철저히 관리한다.

이제 소프트웨어 개발 현장으로 넘어와 보자. 이상하게도 소프트웨어를 개발하는 곳은 변경이라는 것을 그리 중요한 요소로 생각하지 않는다. 소프트웨어 개발 과정도 초기 컨셉이 결정되면 요구사항 파악부터 분석/설계과정을 거처 구현/테스트를 통해 소프트웨어를 릴리즈하고 유지보수 단계로 접어든다.

요구사항에서부터 최종 릴리즈까지 진행하면서 소프트웨어는 수많은 변경을 겪는다. 수시로 바뀌는 요구사항 때문에 설계를 변경해야 하고 소스코드를 뜯어 고쳐야 한다. 또한 요구사항을 잘못 이해하는 바람에 변경이 발생하고, 소프트웨어의 결함 때문에 변경을 해야 한다.

하나의 변경은 그에 수반된 여러 부분의 변경을 파생시킨다. 또한 하나의 변경으로 인해 다른 부분의 안정성도 보장받지 못할 수 있다. 따라서 변경에 대한 영향을 파악해야 하고 변경을 받아들이기 위해서는 얼마 만큼의 노력이 필요한지 알아야 한다.

그럼에도 불구하고 왜 변경에 대해 관리하지 않는 것일까? 소프트웨어 개발 시에 변경 관리가 용이하지 않은 가장 큰 이유는 '변경이 쉽다'라는 것이다. 적어도 자동차를 만드는 것보다는 쉬울 수 있다. 변경이 쉽기 때문에 너무 빈번하게 일어나고 자연스럽게 생각한다. 사소한 변경이든 중대한 변경이든 변경은 통제 대상에 놓여야 한다. 특히 형상 관리 대상으로 결정된 산출물은 엄격히 관리되어야 한다.

바꾸려는 사람과 안 바꾸려는 사람
프로젝트 현장에서 변경에 대한 시각은 이해관계에 따라 서로 다르다. 개발한 소프트웨어를 사용해야 하는 사람들은 개발 완료 시점이 다 되어 갈수록 아이디어가 샘솟기 때문에 자신의 아이디어를 어떻게든 반영하려고 노력한다. 반면 소프트웨어를 개발하는 사람들은 초기에 결정했던 고객의 요구사항을 어떻게든 바꾸지 않고 끝까지 끌고 가려고 노력한다.

변경의 정당성을 주장하는 고객의 논리는 지금 이 변경을 적용하지 않으면 결국 쓸모없는 소프트웨어가 된다는 것이다. 바꿔 말하면 변경하지 않을 경우 안 쓰겠다는 거의 반 협박성의 주장이다. 대가를 받고 소프트웨어를 개발하는 입장에서 들을 때는 검수해 주지 않겠다는 생존의 위협을 느끼게 하는 대목이다.

검수받지 못하면 잔금을 받을 수 없다. 반면 개발하는 사람들은 지금 변경하면 다른 부분에 영향이 많기 때문에 혹은 아키텍처가 흔들리기 때문에 시스템의 안정성을 보장할 수 없다고 한다. 여력만 있다면 바꿔주겠지만 현재 남은 기간으로는 도저히 반영할 수 없는 상황이라고 반론을 편다.

이때 변경 통제가 어느 정도 효과를 발휘할 수 있다. 변경 통제라는 것은 앞에서도 잠깐 언급했지만 소프트웨어 개발 기간 동안 발생하는 주요 변경사항을 평가 및 승인하여 변경사항이 소프트웨어의 각 부분에 어떤 영향을 주는지 알아내어 해당 이해관계자에게 어떤 영향을 주는지 알리는 것을 의미한다.

만약 고객의 변경이 불필요한 것이라면 관련 당사자를 의사결정에 참여시켜 조목조목 따져봄으로써 변경에 대한 영향을 가시화해 볼 수 있게 되므로 고객의 주장대로 정말 못 쓸 정도의 소프트웨어가 개발되는 것인지 반대로 개발팀의 주장대로 아키텍처가 흔들릴 정도로 엄청난 변경을 가하게 되어 안정성을 해치게 되는지, 남은 기간에 도저히 적용할 수 없는 수준의 변경인지 판단할 여력이 생긴다. 만약 소위 막가파 식으로 밀어붙이는 것만 아니라면 서로 얼굴 붉히지 않고 합리적인 수준에서 협의할 수 있는 근거가 만들어 질 수 있다.

형상 관리는 무엇인가?
지금까지 여러 가지 형상 관리와 관련된 사항들, 왜 형상 관리가 필요한지, 다른 분야에서는 형상 관리 같은 것을 하는지, 사람들의 관점은 어떤지 이야기했다. 이제 본격적으로 형상 관리에 대해 알아보자.

형상 관리는 1960년대에 등장하여 1970년대에 미 국방부의 밀리터리 스탠더드(Military Standard)의 일부로 만들어졌다. 이후 지속적으로 발전하다가 1990년대 들어 컴퓨팅 환경이 복잡해지고 품질기준이 엄격해지면서 본격적으로 적용되기 시작했다. 형상관리에 관하여 많은 정의가 존재하지만 가장 많이 보는 2가지를 살펴보자.


이와 같은 정의에서와 같이 대부분의 정의에서 형상 관리라 함은 크게 4가지로 나눈다.


형상 관리의 대상인 형상 항목을 생각해보면 형상 관리는 특성상 소프트웨어의 모든 부분에 영향을 주고 영향을 받는다. 단순히 바이너리 형태의 파일이나 소스코드에만 범위에 해당하는 것이 아니라 문서형식의 산출물, 각종 스크립트, 소프트웨어를 개발 이력 등이 해당한다. 또한 소프트웨어를 개발하는 사람들과 조직, 소프트웨어 개발 프로세스, 소프트웨어가 탑재된 하드웨어 및 네트워크 등도 해당된다.

형상 관리에서 말하는 형상(configuration)은 그 의미를 광의적으로 해석했을 때 사실 소프트웨어 그 자체이다. 소프트웨어는 PC에서 실행되는 작은 규모도 있고 네트워크와 연결되어 복수 개의 서버에서 운영되는 크고 복잡한 규모의 것도 있다. 따라서 엄밀히 따지면 소프트웨어를 구성하는 모든 것으로 볼 수 있으며 소프트웨어를 만드는 사람과 회사, 소프트웨어를 탑재하는 하드웨어 및 각종 컨피규레이션(configuration), 소프트웨어 그 자체, 소프트웨어 개발 프로세스, 형상 관리를 하기 위한 형상 관리 도구와 개발 도구 등이 해당한다.

형상 항목의 상태 변경에 따른 형상 관리
사실 형상 관리의 가장 큰 목적은 변경에 의해 점차적으로 변해가는 소프트웨어의 형상을 관리함에 있다. 형상 항목의 변경은 특정 상태를 거쳐 이뤄지는데 그 흐름을 그림으로 표시하면 <그림 1>과 같다.

형상 항목의 라이프 사이클은 크게 6단계의 상태로 볼 수 있는데 개발 초기에 개발 중이라는 상태에 위치하게 된다. 일단 개발이 어느 정도 완료되면 단위 테스트(unit test)를 준비하고 테스트를 통과하면 시스템 테스트 준비상태로 변하게 된다.

시스템 테스트(system test)도 아무런 이상 없이 통과하면 수락 테스트(acceptance test) 준비상태로 되고 이후 모든 결함(defect)을 제거하면 베이스라인(baseline)을 확정하고 제품을 릴리즈하게 된다. 이때 각 테스트 상태에서 결함이 발견되면 그 전 상태로 돌아가고 발견한 모든 결함을 제거할 때까지 과정을 반복하게 된다.

<그림 1> 형상 관리의 라이프 사이클 (Pankaj Jalote, CMM in Practice, 2000)

앞에서 언급한 형상 관리의 정의에 따라 <그림 1>의 형상 관리 품목의 라이프 사이클을 살펴보면 우선 식별한 형상 항목을 최초로 작성하고 각 테스트를 거치면서 형상 항목을 변경하거나 수정한다. 단위 테스트의 경우 단위 프로그램의 결함 여부를 찾아내는 것이므로 주로 수정의 경우에 해당된다고 할 수 있다.

이 때 개발자가 작성한 프로그램의 경우 결함에 의해 수정되어 버전 통제를 받게 된다. 만약 단위 테스트 결과로 형상 항목의 구성에 포함되어 있다면 프로그램과 해당 단위 테스트의 결과는 서로 관계를 맺고 변경 요청에 의한 변경 통제 프로세스를 따라 진행될 것이다.

단위 테스트를 통과한 단위 프로그램들은 의미 있는 집합으로 묶여 시스템 테스트의 대상이 된다. 이때도 역시 결함이 발견되면 변경 통제 프로세스에 따라 진행한다. 수락 테스트는 주로 소프트웨어의 요구사항과 직접적으로 연관되어 있으므로 변경 통제 절차가 강화되고 요구사항과 변경과의 추적(trace)을 관리해야 한다. 베이스라인 확정 상태는 수락 테스트까지 마친 상태에서 프로젝트 진행 상태의 기준이 되는 아주 중요한 지표가 된다. 한번 확정한 베이스라인은 뒤로 바꿀 수 없다.

프로세스 관점에서 형상 관리 활동
지금까지 형상 항목의 상태에 따른 라이프 사이클을 중심으로 봤다면 이제 프로세스 관점에서 형상 관리 활동을 중심으로 살펴보자. ‘오류! 참조 원본을 찾을 수 없습니다’는 형상 관리 활동을 전반적으로 나타낸 것으로 Anne Mette Jonassen Hass의 『Configuration management principles and practice(2002)』에서 나오는 원래의 그림은 원문자와 곡선 화살표가 없는데 이는 더 용이한 설명을 위해 필자가 첨부한 것이다.

<그림 2> 형상 관리 활동의 개요(Anne Mette Jonassen Hass, Configuration management principles and practice, 2002)

<그림 2>에서 굵은 선으로 둘러싸인 부분이 형상 관리의 범위이다. 여기에는 형상식별(Identification)과 통제 상에 놓여 있는 저장소(controlled storage), 변경 관리(change control), 상태 보고(status reporting)가 형상 관리의 활동이다. 여기서 형상 감사(audit) 부분은 각종 테스트와 검사에 관계된 활동으로 순수 형상 관리의 활동으로 보기 보다는 품질보증(quality assurance)의 일환으로 보는 관점이 있어 형상 관리의 정의에는 포함되나 그림 상으로는 굵은 선 박스의 외부에 위치시켰다.

그림 상으로 드럼통 모양은 데이터베이스 표식으로 저장소 데이터베이스, 변경 관리 데이터베이스, 메타 데이터베이스가 있다. 이들은 형상 관리를 위한 프로젝트 데이터베이스로 형상 항목의 그 자체를 저장하고(controlled storage), 변경에 관한 이력과 각종 정보를 저장하며(change control), 형상 항목에 대한 이름, 작성자, 생성 날짜와 다른 형상 항목과의 관계를 저장(metadatabase)한다.

그림에서 각 번호는 형상관리 활동을 나타낸 것이다. ①은 형상 관리 계획(configuration management plan)에 따른 형상 식별 활동이다. 우선 프로젝트에서는 프로젝트 계획의 일환으로 작성한 형상 관리 계획을 근거로 형상항목을 식별하여 메타 데이터 베이스에 입력한다. 이때 형상 항목을 유일하게 식별할 수 있도록 형상 항목의 이름, 작성자(author), 생성일, 문서인 경우 문서번호, 다른 형상 항목과의 관계 등을 저장하고 이때부터는 변경 관리의 대상이 된다.

②는 아직 형상 관리 범위 안으로 들어오지 못한 형상 항목의 생성 과정을 나타낸다. 프로덕션(production)은 현재 변경 중인 상태의 항목을 의미한다. 이때까지는 변경 통제의 대상에 포함되지 않는다. ③은 감사를 거쳐 변경할 수 없는 상태의 형상 항목을 구분된 장소에 두는 활동을 의미한다. 이때 보통 테스트를 거치는데 변경 중인 형상 항목과 더 이상의 변경이 없는 항목의 구분을 위해 존재한다. 이 분에서도 역시 변경 통제의 대상에 두지 않는다.

④에서는 ③을 거쳐 나온 항목을 비로소 변경 통제의 대상에 등록하는 활동이다. 이때 누가 왜 무엇을 언제 바꾸었는지 변경관리 데이터베이스에 기록된다. ⑤는 변경 통제 하에 있는 항목의 상태를 리포팅(status reporting)하는 활동이다.

지금까지 형상 관리의 정의와 형상 관리의 대상이 되는 항목의 상태 변화와 형상 관리 활동을 중심으로 살펴보았다. 주로 형상 관리 자체만을 갖고 설명했으므로 피상적이고 따분하겠지만 우선 이런 것이구나 하는 수준으로 접근했으면 한다.

CMM과 형상 관리
여기서 CMM은 정확히 말하자면 SW-CMM으로 소프트웨어 개발 역량을 평가하기 위한 성숙도 모델이다. 여기에는 실제 실행 지침과 소프트웨어 프로세스 개선, 소프트웨어 프로세스 평가를 수행하는 개별 작업자의 요구를 반영한다. 또한 문서화되고 공개적으로 사용 가능하다. CMM의 태동을 주도한 미 국방부의 연구에 따르면 소프트웨어 개발 프로젝트의 성공과 실패를 결정짓는 주요 원인은 기술이라기보다는 관리의 문제라는 결론을 내렸다.

따라서 소프트웨어 개발 조직의 성숙도에 따라 소프트웨어의 품질은 많은 차이를 보인다. 그 이유로는 미성숙한 개발 조직의 경우 소프트웨어의 품질의 좋고 나쁨을 판단하는 객관적인 기준이 없고, 소프트웨어 프로세스가 품질에 어떻게 영향을 미치는지에 대한 이해가 없으며, 정형화된 테스트나 검토와 같은 품질 보증 활동은 이런 저런 이유로 축소되거나 생략된다. 개발팀은 사소한 문제로도 우왕좌왕하고 개인의 역량에 의지하여 해결하려고 한다. 따라서 고객은 최종 인도 이전에는 그들이 사용할 소프트웨어가 어떻게 작동하는지 알 수 없게 된다.

하지만 개발 역량이 성숙한 조직은 프로세스를 적극 활용하여 개발팀이 그들이 맡은 임무에 따라 일사 분란하게 움직이도록 훈련이 되어 있다. CMM은 개발 역량이 성숙한지 아닌지를 평가하기 위해 5단계의 레벨을 두고 있다. 각 레벨의 특징은 <표 1>과 같다.

<표 1> 소프트웨어 프로세스 성숙도의 5레벨

이 5레벨에서 우리가 지금 이야기하고 있는 소프트웨어 형상 관리는 어느 레벨의 인증을 위한 핵심 프로세스에 해당할까? 높은 레벨일 듯 싶지만 겨우 레벨 2이다. 이 정도면 이제 겨우 조직적으로 개발 좀 한다는 소리를 듣는 단계의 시작이다.
CMM에서는 레벨 2에서 소프트웨어 요구사항관리와 함께 형상 관리가 핵심 프로세스 영역(KPA : Key Process Area)으로 되어 있다. 성숙도 레벨에 따른 핵심 프로세스 영역은 <그림 3>과 같다.

<그림 3> 성숙도 레벨에 따른 핵심 프로세스 영역

반복 레벨의 인증을 받기 위해서라도 이것저것 관리해야 할 것이 태산이다. 그 중 CMM이 인정할만한 소프트웨어 형상관리는 어떤 수준인지 살펴보자.

CMM의 형상 관리 가이드
CMU/SEI에서 작성한 『The Capability Maturity Model: Guide for Improving the Software Process, 1st Edition(1994)』을 토대로 CMM이 레벨 2 수준의 형상 관리를 위해서는 목표에 따른 어떠한 수행능력(Ability to Perform)이 있어야 하는지 살펴보자.

[1] 프로젝트 소프트웨어 기준선을 관리할 수 있는 권한을 가진 위원회(즉, 형상통제위원회, SCCB : Software Configuration Control Board)가 존재하거나 없다면 설립한다.


[2] 프로젝트를 위한 SCM의 조정과 구현에 책임을 가진 그룹(즉, SCM 그룹)이 존재한다.


[3] SCM 활동 수행을 위해 적절한 자원과 자금이 지원된다.


[4] SCM 그룹의 구성원들은 SCM 활동을 수행하기 위한 목표, 절차, 방법 등에 대해 교육을 받는다.


[5] 소프트웨어 엔지니어링 그룹과 다른 소프트웨어 관련 그룹의 구성원들은 SCM 활동을 수행하는 데 필요한 교육을 받는다.


이와 같이 총 5가지의 수행능력을 바탕으로 형상 관리 활동을 실시해야 한다. 어떻게 보면 그야말로 딱딱한 법전 같은 가이드지만 결국 요약하면 프로세스 상에서 권한과 책임을 줘 결정하고 승인할 역할을 만든다. 또한 결정에 따라 형상 관리를 수행할 조직을 만들고, 수행할 사람들에게 교육을 제공해야 한다는 것이다.

너무나 상식적이고 당연한 형상관리
『소프트웨어 공학의 사실과 오해』를 저술한 로버트 L. 글래스는 개발자의 능력에 따라 생산성이 28배까지 차이 난다는 사실을 이야기한바 있다. 어마어마한 수치임에 틀림없다. 실제로 누구나 아는 사실이겠지만 어려운 난관에 부딪히면 초보개발자 100명이 달라붙어도 해결하지 못할 문제를 고급 개발자는 점심시간에 자장면 먹어가며 한 손으로 타이핑 몇 번 만에 해결할 수 있다. 이것은 사실을 넘어서 부인할 수 없는 진실이다.

하지만 조직적으로 소프트웨어를 개발할 때는 어려운 문제만 있는 것이 아니라 해결 가능한 평이한 문제들이 절대 다수를 차지하고 이것들은 서로 관계를 갖고 복잡도를 증가시킨다. 또 끊임없이 변한다.

이렇게 복잡하면서 지속적으로 변하는 소프트웨어라는 괴물을 어떻게 다루는가가 형상 관리의 주된 목적이다. 형상 관리는 반드시 되어야 한다. 그 과정도 너무나 상식적이고 당연하다.@

출처 : 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.

이 문서는 Success, Process, Product, Property 이 네개의 모델을 어떻게 통합하여 성공적인 소프트웨어 개발을 수행할 수 있는지 설명해 줍니다. USC/CSE의 그 유명한 배리 보엠 교수가 MBASE의 연구를 리딩하고 있습니다. 모델기반의 소프트웨어 개발이 궁금하신 분들이라면 꼭 한번 살펴 보세요. 내용이 약간 방대... ㅠ.ㅠ

 

영문 DOC

1. 객체 지향 테스트

2. 웹 기반 소프트웨어 테스트

3. 임베디드 소프트웨어 테스트

4. 테스트 자동화 - 응용 분야

5. 테스트 사례

6. 테스트 표준

 

2005년 11월 교육 자료

1. 테스트 개념

2. 테스트 프로세스

3. 테스트 기법

4. 공식 기술 검토

5. 테스트 종류

7. 테스트 관리

8. 테스트 케이스 설계

 

2005년 11월 교육 자료

테스트 용어 해설

검증(Validation)
소프트웨어가 명시된 요구를 만족하는지 평가하는 과정.

검토(Verification)
소프트웨어 개발 작업의 산출물이 정해진 규칙, 절차, 표준에 맞는지 정확성, 일치성을 평가하는 과정.

결함(Defect)
소프트웨어 개발자에 의하여 만들어진 오류의 표출.
원시코드 또는 문서에서 발견된 소프트웨어 개발자에 의하여 저질러진 오류.

결함분석
지속적인 품질 향상을 위하여 결함을 자료로 사용하는 분석. 결함을 카테고리 별로 구별하고 원인을 찾아내어 프로세스 향상 노력에 도움이 되게 한다.

결함 빈도(Defect Density)
단위 프로그램 길이(보통 1000라인) 당 결함의 수

경계값 분석
데이터 범위의 경계선에 놓여있는 값을 선택하여 테스트 데이터로 선택하는 방법. 경계값은 최대, 최소, 경계안쪽/바깥쪽, 정상적 대표값, 오류값으로 구성된다.

경로분석
프로그램 안에 있는 불완전한 경로 또는 실행 불가능 한 코드를 찾아내기 위하여 모든 경로를 파악하는 분석 방법.

경로 커버리지 테스트
프로그램에 존재하는 모든 경로를 한 번 이상 수행하는 테스트 방법. 프로그램의 경로는 유한 클래스의 집합으로 그루핑될 수 있으면 클래스 당 하나의 경로만을 테스트 한다.

공식 리뷰
분석, 설계, 코딩 등 여러 가지 작업 단계가 완료된 후 고객(formal review)과 함께 수행하는 기술적인 검토.

구조적 커버리지(Structural Coverage)
대규모 시스템의 테스트 완료를 위하여 모든 모듈이 적어도 한번씩 수행되어야 하는 검증 기준.

기능 테스트
워시 프로그램을 자세히 조사하지 않고 명시된 기능적 요구를 기초로 테스트하는 방법.

기술 검토
기술 문서의 내용을 검토하는 기술측면의 회의.

테이터 흐름 분석
원시코드에 표현된 데이터(변수)의 정의와 사용에 대한 패턴을 모아 그래프로 분석하는 기법. 원시코드가 수행되는 도중에 특정 위치에서 데이터의 가해진 제약조건을 결정하는 데 도움이 된다.

동등 클래스 분할
여러 가지 입력 조건들의 대표값을 파악하여 테스트 하는 기법.

동료검토(Peer Review)
소프트웨어의 결함이나 수정이 필요한 부분을 찾기 위하여 개발 당사자가 아닌 동료가 조사 검토하는 작업.

동적 분석
선택한 테스트 데이터를 이용하여 프로그램을 수행하여 테스트하는 방법.

디버깅
테스트 또는 사용자의 불만 제기에 의하여 발견된 기능장애의 원일을 찾아내려는 작업.

랜덤 테스트(Ramdom Test)
프로그램에 가능한 모든 입력값 중에서 임의의 값을 택하여 시험하는 블랙박스 테스트 기법.

리그레션 테스트
시스템의 일부 또는 전체를 수정하는 동안 변경에 의한 영향이 문제를 일으키지 않는지 또는 변경한 시스템이 의도한 요구사항을 잘 만족하는지 발견하기 위하여 선택적으로 다시 테스트하는 기법.

메트릭
제품이 가지는 품질, 특성, 속성 등의 정도를 측정함.

문장 커버리지
테스트가 완료되기 위하여 각 문장이 적어도 한번씩 수행되어야 하는 검증 조건.

뮤테이션 테스트
테스트 데이터가 프로그램의 작은 오류에 얼마나 민감한지 보기 위하여 의도적으로 프로그램을 변경시켜 준비된 테스트 데이터를 실행시키는 기법.

베타 테스트
소프트웨어 제품의 고객이 도리 엔드 유저에 의하여 고객의 사이트에 설치하고 시험하는 테스트.

분기 커버리지 테스트
프로그램 안에 포함된 분기점의 참가 거짓 모든 가지(branch)를 적어도 한번씩 테스트하는 조건을 요구하는 테스트 방법.

블랙박스 테스트(Black Box Test)
프로그램의 내부구조나 데이터의 대한 지식이 없이 요구사항에 근거하여 수행하는 기능시험.

사이클로매틱 복잡도
프로그램 모듈을 통과하는 독립적인 수행 경로의 수.

상향식 테스트
하위층의 컴포넌트를 먼저 구현하고 이를 호출하기 위하여 테스트 드라이버를 사용 통합 테스트 유형.

실행 불가능 경로
조건 설정이 잘못되어 도저히 실행이 될 수 없는 프로그램의 문장.

스텁
하향식 통합 테스트할 때 아직 통합되지 않은 모듈을 호출할 때 그 모듈의 기능을 최소한으로 시뮬레이션한 모의 모듈.

시스템 테스트
시스템이 명시된 기능 및 성능을 발휘하는지 모든 시스템 구성요소를 통합한 후 시험하는 기술.

알파 테스트
개발자 사이트에서 사용자가 수행하는 소프트웨어 제품의 테스트.

오류
- 수행된 결과값이나 조건과 예상하였던, 이론에 의하여 올바른 값이나 조건과의 불일치
- 프로그래머에 의하여 생성된 실수로 프로그램의 결함으로 나타남.

오류기반 테스트
프로그래밍 스타일, 오류가 많이 발생하는 문법, 기타 프로그래밍 지식을 이용하여 많이 출현하는 결함을 예측하고 이를 발견하기 위한 테스트 데이터를 선택하는 방법.

워크스루(Walkthrough)
가상의 입력에 대하여 원시코드의 수행을 문장 하나씩 짚어보는 작업. 데이터 정의부분, 매뉴얼, 명세 등 프로그램이 아닌 부분도 검토 대상이 된다.

원인-효과 그래프
테스트 케이스를 만들기 위하여 원인과 그 효과의 관계를 체계적으로 나타내는 방법. 테스트 케이스의 완벽성과 모호성을 체크하는 데 도움이 된다.

인수 테스트
시스템이 인수조건을 만족하는지 결정하기 위한 공식 테스트. 이 결과를 기초로 고객이 시스템 개발을 인수할 것인지 결정한다.

인스트로멘트(Instrument)
소프트웨어 요구, 설계, 원시코드 등을 저작자 이외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법. 소프트웨어 품질을 높이는 한 가지 방법이며 결과물 자체의 품질 측면 뿐만 아니라 결과물을 만들어 내는 과정도 인스펙션의 대상이다.

정적 분석
원시코드나 개발 문서가 요구 및 표준 규격에 맞는지 수동인 방법으로 체크하는 기법.

단위 테스트
독립적으로 컴파일하고 링크될 수 있는 소프트웨어의 작은 단위를 테스트하는 작업. 유닛은 독립적인 기능이나 의도하는 설계 구조와 매칭되지 않을 수도 있다.

테스트
시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동 방법을 동원하여 검사하고 평가하는 일련의 과정.

테스트 계획
테스트 작업을 통제하고 관리하기 위하여 따라야 할 테스트 절차 또는 과정, 도구 등을 적은 문서.

테스트 드라이버
상향식 통합 테스트에서 아직 통합되지 않은 상위 컴포넌트들의 동작을 시뮬레이션하는 모의 모듈. 테스트 하니스의 일종.

테스트 베드
- 논리적 및 물리적으로 분리된 컴포넌트를 테스트하기 위하여 하드웨어, 인스트루먼트, 시뮬레이션, 소프트웨어 도구등을 통합한 환경
- 컴포넌트나 시스템 테스트를 수행하기 위하여 필요한 테스트 프로그램 슈트.

테스트 사이클
연속적인 테스트 슈트로 구성되어 있고 처음 테스트 환경 준비 단계부터 보고, 해체 단계까지의 완벽한 수행과정을 이룬다.

테스트 슈트
일정한 순서에 의하여 수행될 개별 테스트들의 집합, 또는 패키지. 슈트는 응용 분야나 우선순위, 내용에 연관된다.

테스트 스크립트
테스트 케이스를 수행하여 그 결과를 보고할 목적으로 명령어 또는 이벤트 중심의 스크립트 언어로 작성한 파일. 프로그램과 같이 테스트 스크립트는 수행 경로에 영향을 미칠 논리 조건들을 포함하고 있다. 채택된 자동화 방법에 따라 다르겠지만 상수와 실행 과정에 변경될 변수값을 포함한다. 자동화 접근 방법은 테스트 스크립트를 개발하는데 필요한 기술적 역량의 정도를 나타낸다.

테스트 절차
테스트를 수행할 때 따라야 할 순서. 최소의 훈련으로 테스트를 수행하게 하는 문서.

테스테 케이스
요구에 맞게 개발되었는지 확인하기 위하여 테스트 할 입력과 예상 결과를 정의한 것. 테스트 자동화를 도입하면 테스트 케이스는 테이터 레코드로 저장될 수 있고 테스트 스크립트로 정의할 수 있다.

테스트 하니스
소프트웨어 컴포넌트의 테스트를 가능하게 하거나 프로그램의 입력을 받아들이거나 빠진 컴포넌트의 기능의 대신하거나 실행 결과와 예쌍 결과를 비교하기 위하여 동원된 소프트웨어 도구.

통합
소프트웨어 컴포넌트들을 묶어 전체 시스템으로 묶는 작업.

통합 테스트
소프트웨어 컴포넌트들을 묶어 전체 시스템이 될 때까지 순서대로 통합하며 시험하는 기법.

하이브리드 테스트
모듈의 우선순위와 준비 스케줄을 고려하여 상향식 테스트와 하향식 테스트를 혼합한 통합 테스트 방법.

화이트 박스 테스트(White Box Test)
테스트 대상이 되는 원시코드를 자세히 관찰하면 테스트 한다는 의미로 글래스(glass)박스 또는 오픈(open)박스 테스트라고도 한다.

하향식 테스트
상위층의 컴포넌트를 먼저 테스트하고 아직 구현되지 않는 컴포넌트를 시뮬레이션 하는 모의 컴포넌트, 즉 스텁을 이용하여 통합하는 테스트 유형.

테스트 계획의 일반적인 전략과 목표에 대한 문서입니다.
테스트 계획은 진행 중인 프로세스입니다. 여기서, 테스트 기획자들은 다음과 같은 활동을 하게 됩니다:

• 분석적 도구를 이용해서 테스트 케이스를 개발한다: 테스트 기획자들은 다양한 종류의 도표를 이용해서 프로그램의 각 테스트 가능한 부분을 확인하고 각 부분에 대해 엄격한 테스트 케이스를 찾아낸다.


• 테스트 전략을 도입하고 적용한다: 어떤 순서로 프로그램의 테스트 영역을 탐색하고 테스트할 것인지, 언제 더 심화된 테스트를 진행할 것인지 결정한다.


• 테스트 관리를 위한 도구를 개발한다: 체크리스트, 매트릭스, 자동화 테스트, 그 외 자료를 사용하여 테스터가 특정한 순서에 따라 특정한 데이터를 가지고 특정한 순서로 테스트를 할 수 있도록 한다. 이런 간단한 도구들이 프로세스에 완전성과 설득력을 부여할 수 있다.


• 의사소통: 테스트 전략과 논리, 구체적인 테스트와 테스트 데이터 파일에 대한 이해를 도울 수 있는 테스트 계획 문서를 작성한다

아래의 문서들은 다음의 내용을 포함하고 있습니다.

1. 테스트 계획과 문서화의 중요성
2. 화이트박스와 블랙박스 테스트가 모두 중요한 이유
3. 테스트 문서 초기 개발 전략
4. 테스트 계획의 구성 요소: 리스트, 테이블, 아웃라인, 매트릭스
5. 테스트 문서화하기

개발 단계에 따른 각 팀별 업무

단계	개발팀	마케팅팀	문서화팀	테스트팀
제품 설계	* 요구사항 * 스펙 * 제안 * 계약 * 내부 디자인 * 외부 디자인	시장 조사: * 포커스 그룹 * 고객 설문 * 경쟁제품 분석	* 스펙 초안 작성을 도움	* 제품에 대한 학습 * 스펙, 설계, 제안에 대한 리뷰 * 테스트 지원 코드 요청 - 인쇄 자동화 - 메모리 측정기 - 단축키 - 화면 덤프 * 계약 적합성 테스트 작성 * 인수 안정성 분석 * 고객 데이터 분석 * UI 통일성 리뷰 * 테스트 구조 협상 * 장비 제공업체들과 관계 구축 * 경쟁 제품 분석 * 베타 테스터 물색
초기 기능 구현	* 코딩 * 유닛 테스팅			* 기초 테스트 * 작업, 자원, 시간, 예산에 대한 예측치 제공받음
Pre-Alpha	* 코딩 * 버그 수정 * 유닛 테스팅		* 문서화 계획 * 매뉴얼 계획 및 도움말 계획 리뷰	* 테스트 장비 주문 * 테스트 장비 대여 * 테스트 목표, 작업, 소요시간 및 자원, 예산 설정 * 테스트 계획 초안 * 테스트 리스크 파악 * 버그 찾기 * 최종 스펙 리뷰
Alpha	* 코딩 * 버그 수정 * 유닛 테스팅 * 설계 수정 * 디바이스 드라이버 * 샘플 아트		* 매뉴얼 및 도움말 초안	* 전체 영역 테스트 * 선택 영역에 대한 무작위 테스트 * 선택 영역에 대한 테스트 계획 및 수행 * 테스트 계획 리뷰 * 매뉴얼 테스트 * 버그 개수 예측 * 지원 장비에 대한 최종 리스트 받음 * 디바이스 테스트 시작 * 리그레션 테스트 추가 시작 * 필요한 자원 분석 및 요구 * 적합성 테스트 시작 * 자동화 테스트 시작
Pre-Beta	* 버그 수정			* 베타 수준의 안정성과 기능 완전성을 갖추고 있는지 확인
Beta	* 기능 완료 * 버그 수정 * UI 수정 * 설치 코드 * 디바이스 드라이버 * 샘플 아트 * 베타 테스트버전	* 포장 * 디스크 레이블 * 베타 사이트 지원 * 베타테스트판 배포	* 매뉴얼&도움말에 대한 리뷰 및 재작성 * 스크린샷 * 문제 해결 * 초안 색인	* 최종 테스트 계획 승인 받기 * 테스트 계획 수행 및 심화 * 마케팅 문서 검토 * 문서화 리뷰 * 수정된 버그 테스트 * 종합 디바이스 테스트 * 공식 테스트 결과 요약 보고 * 버그 중요도에 대한 회의 * UI 리뷰, UI freeze 준비 * 사내, 사외 베타 테스트 * 완성도 평가
UI freeze	* 버그 수정 * 속도 향상 * 설치 종료 * 환경설정 종료	* 영업 및 판매	* 도움말 수정 * 스크린샷 * 매뉴얼 레이아웃 및 인쇄	* 리그레션 테스트 * 테스트 계획 수행 * 죽는 문제, 데이터 오류, 메모리 할당 문제 테스트 * 보고된 버그 수정 촉구 * 확장 디바이스 테스트
Pre-Final	* 버그 수정	* 영업 및 판매	* 매뉴얼 보충 * 최종 도움말 수정	* 리그레션 테스트 * 이전 버전에 대한 종합 테스트 * 디바이스 테스트 한 번 더 * 수정된 버그 다시 테스트 * 기각된 버그 최종 보고 * 프로그램 신뢰성 평가
Final Test	* 버그 수정 * 데모 코드 * 소스 코드 보관	“		* 사용 안정성 평가 * 사용자 평가 예측 * 테스트 계획 및 버그 감사 * 마스터 만들기 * 바이러스 검사, 제작된 마스터 검사
Release	* 휴식	* 판매, 판매	* 휴식	* 필요하다면, 제작기간 중에도 테스트 * 제작된 제품 테스트

<embeded class="tatterImageFree" longdesc="https://t1.daumcdn.net/cfile/tistory/246BC043586C994C20/" src="/attach/8715/cfile10.uf@246BC043586C994C208421.hwp/>

소프트웨어 개발 프로젝트에서 프로젝트 매니저는 아래에 제시한 항목들을 고려해 타협점을 찾을 필요가 있습니다.

소프트웨어 개발 시 타협점

프로젝트 매니저의 임무는 주어진 시간과 예산 범위 내에서 고품질의 제품을 출시하는 것이다. 하지만 이것은 거의 불가능하다. 소프트웨어 개발 프로젝트는 대개 일정이 미뤄지고 예산을 초과한다. 성공적인 프로젝트 관리를 위해서는 아래의 항목들에 대해서 타협점을 찾을 필요가 있다.

1. 제품의 신뢰성
: 프로젝트 매니저는 언제든 테스트를 줄이고 많은 버그를 남겨둔 채 저비용으로 제품 출시를 감행할 수 있다. 테스트에는 끝이 없어서 모든 제품 출시 결정은 더 많은 테스트를 했다면 발견할 수 있었던 버그를 남겨둔 채 출시를 결정하는 것이다.
 
2. 기능의 개수와 심도
: 프로젝트 기간을 단축하는 방법은 제품을 단순화하는 것이다. 기능의 설계가 잘못되었거나 그 기술적 난이도가 저평가되었을 때 프로젝트 매니저는 해당 기능을 포기함으로써 시간을 단축할 수 있다. 하지만 그것이 중요한 기능일 경우 빼버린다면 고객 만족도에 악영향을 미칠 수 있다.

3. 추가 업무에 따른 비용
: 프로젝트 매니저는 추가 비용을 들여서 프로젝트를 단축시킬 수도 있다. 새로운 툴, 구체적인 문제에 답해줄 고급 컨설턴트, 또는 추가 인원에 비용을 투입할 수 있다. 인원을 추가하는 것이 일반적이지만 항상 성공적인 것은 아니다. 상사들이 새 직원을 지원하고 관리하는데 신경을 쓰다보면 업무효율이 떨어지게 된다. 프로젝트 종반으로 가면, 인원추가가 오히려 일정을 지연시킬 수가 있다. 예를 들어 프로젝트의 마지막 시점에 신입을 투입한다면 테스트 팀의 효율성을 떨어트릴 수 있다.
 
4. 출시일
: 만약 일정을 못 맞추고 있다면, 프로젝트 매니저는 언제든 일정을 연기할 수 있다. 하지만, 지연에 따른 프로젝트 비용이 커지게 된다.
* 지속되는 개발에 따른 직접 비용: 기본적인 인건비 총계, 설비 비용 등
* 기회 비용: 계약 위반 손실금, 성수기를 놓침에 따른 손실, 경쟁자가 먼저 출시함에 따른 손실
* 허비한 마케팅 비용: 광고와 기사가 나간 후 즉시 출시가 이뤄지지 않을 때, 광고비와 출시 전 홍보 노력이 물거품이 됨.
* 대안 기회 비용: 지연된 프로젝트에 투입된 인력은 다른 프로젝트에 투입될 수 없으므로, 다른 프로젝트 역시 지연될 수 있음.
* 매출 부재: 현재 시점에서 제품 매출이 필요한 경우.

테스트 계획에 포함되어야 항목  05.02.04 13:07 
 
테스트 계획은 테스트 공정을 이해하는데 도움을 준다. 모든 테스트 공정을 하나의 계획서에 기술하여도 좋지만(실제로 그렇게 작성하는 사람도 있다) 별도의 문서로 나누어 기술하여 각각 해당하는 섹션에 참조 포인트를 붙이는 것이 일반적이다. IEEE 표준규격에서 정의하고 있는 테스트 계획의 항목은 다음과 같다.

1.        테스트 계획ID
임의의 명칭 또는 번호를 부여한다. 모든 문서를 데이터베이스에서 관리할 때 편리하다

2.        서문
테스트 계획의 개요를 설명한다.(적절한 수단과 표준적인 문서의 설명을 포함한다)

3.        테스트 항목
테스트 항목은 소프트웨어의 어떤 측면(기능,모듈,특징, 기타)를 테스트 대상으로 할 것인지에 관하여 기술한다. 모든 내용을 열거하던지 아니면 모든 것이 기술되어 있는 관련 문서를 참조하도록 한다. 참조 가능한 사양서(요구사양서,설계서 등), 메뉴얼(사용자, 조작, 설치 메뉴얼 등)을 기술한다.

4.        테스트 대상 기능
테스트 설계 사양서와 상호 참조

5.        테스트 대상 외의 기능
테스트를 하지 않는 것은 어느 것이고 그 이유를 기술한다.

6.        테스트 방법
테스트 방법의 개요를 작성하는 담당자, 주요 내용, 기법, 사용툴, 테스트 완료조건

7.        합격,불합격 기준
합격,불 합격의 판정기준을 명확히 한다.

8.        테스트 중단 기준과 재개 요건
프로그램이 수정될 때까지 테스트를 중단하는 조건의 열거 및 테스트를 재개하는 조건을 명확히 한다.

9.        성과물
작성해야 할 테스트 문서를 모두 열거한다.

10.        테스트 작업
테스트의 준비와 실시에 필요한 모든 작업내용을 열거한다. 작업의 의존관계, 필요한 기술 또는 인력, 담당자, 부하의 정도, 완료시기

11.        환경
필요한 하드웨어, 소프트웨어, 테스트 툴, 설비 등을 기술한다.

12.        책임자
관리, 설계, 준비, 실행, 인증, 수정, 해결(결단) 환경의 수배 등의 책임자(그룹)을 명기한다.

13.        인원 및 교육
어느 정도의 레벨의 인력이 몇 명 필요한지 어떤 교육이 필요한지 등

14.        스케쥴
milestone에는 날짜를 표기한다. 각 리소스(사람, 기계, 툴, 설비)의 필요한 시기를
기록한다.

15.        Risk 와 Accident
테스트 계획에 있어서 리스크가 높은 것은 어느 것인지 스케쥴 지연의 원인이 되는 것은 무엇인지. 발생하였을 경우 대처방법은 어떻게 할 것인지 등 

16.        승인
테스트 계획의 승인자는 누구인지, 승인을 위해 결재란을 준비한다.

테스트 팀의 역활은 나쁜 뉴스를 발견해서 보고하는 것이다. 그것을 듣고 프로젝트의 중지를 경영진이 결단하는 경우도 있고 스케쥴을 조정하여 출하를 늦추는 경우도 있다.
프로젝트가 지연되면 작업이 늘어나는 것 뿐만 아니라 벤처 기업의 경우는 도산할 수도 있다. 테스트 관리는 매우 스트레스가 쌓이는 작업이다.

적은 월급에 젊은 부하 직원 관리에 골 머리를 썩힌다. 그런데도 거의 칭찬받는 경우가 없다.  회사가 특별히 테스트 팀을 설치하는 것은 품질을 개선하는 비용을 삭감하는 효과가 있기 때문이다.  테스트 팀이 좋은 역활를 하기위한 필요한 것을 열거해 보자.

-        능력
테스트를 담당은 테스트 기술에 정통하지 않으면 안된다. 그리고 건설적인 의견을 교환할 필요도 있다. 프로 의식을 공유하는 것이다. 테스트가 자신의 일이고 테스트에서는 누구에게도 지지않는 다는 의식이 중요하다.

-        공수 (테스트 기간)
테스트 담당자는 테스트를 위해 배치해야 만 한다. 테스트의 공수는 테스트를 완료하기 위해 확보는 것이지  프로그램밍과 문서 작업을 위한 것이 아니다. 프로그래머가 한가할 때 하는 테스트와는 틀린 것이다.

-        독립성
테스트 결과는 프로젝트 매니저가 아니고 테스트 팀의 매니저에게 보고 되어야 할 것이고 중요한 장해를 놓치거나 숨길 경우에는 엄하게 질책할 필요가 있다. 역으로 출하 직전에 대량의 버그, 치명적인 장해를 보고해 왔을 경우는 반드시 칭찬을 하자. 그렇게 하면 예를 들어 프로젝트 매니저가 버그를 잠시 숨기고 싶어도 테스트 담당은 자신의 역활을 철저히 할 수 있을 것이다.
 
실수를 범해서는 안된다. 테스트 관리는 인내를 필요로 하며 이동이 많은 역활이기도 하다 . 이유 로서 스트레스가 크기 때문에 다른 부문으로 옮기려고 하기 때문이다. 또 하나는 안됐지만 자신의 문제이다. 인간관계의 파탄을 초래 하거나 제품을 형편 없이 만들거나 같이 일해온 사람의 생활을 어렵게 많들어 버리기도 한다. 이러한 것은 바람직하지 못한 일이다. 원만한 인간관계를 유지하면서 직권의 남용도 부하의 혹사도 하지않고 품질의 개선에 크게 공헌하는 훌륭한 테스트 팀의 관리가 결코 불가능한 것이 아니다.  성실하며 프로의식, 윤리관, 인격을 손상하지 않도록 테스트 팀을 관리하지 않으면 안된다.

테스트 팀의 역활
테스트 팀은 4종류가 있다. 각각의 조직의 방침에 기초하여 서로다른 권한을 부여하고 있다.
-        품질관리 (QC： Quality Control) Type：표준과 규칙을 준수 시킨다.
-        품질보증 (QA： Quality Assurance) Type：품질을 어떠한 방법으로 보증한다.(적어도 보증하려고 한다)
-        테스트 기술 Type：프로젝트 매니저 (회사)에 버그의 발견과 보고라고 하는 특수기능을 제공한다.
-        개발 기술 Type：프로젝트 매니저에게 테스트를 하려고 하는 각양각색의 기술 서비스를 제공한다.  

품질관리 (QC： Quality Control) Type의 그룹
QC Type의 그룹은 커다란 권한을 갖고 있다. 표준데로 작업이 수행되어 지적한 장해가 수정될때 까지 제품의 출하를 거부할 수도 있다. 테스트 기능 타이프와 개발 기능 타이프의 그룹은 부러워할 수도 있지만 실제로 이러한 권한을 갖기 위해서는 큰 보상이 따른다.
소프트웨어의 QC그룹은 공장의 긴 생산 라인에서 토마토 통조림을 몇개 추출하여 검사를 하는 것이 아니다. 회사에 단 1라인 밖에 없는 생산라인을 수 일에서 수 주간  때로는 수 개월 정지 시키기 때문에 경영진은 QC그룹의 출하정지에  곧바로 따를 필요성이 있는지 또는 프로젝트 매니저의 간원을 받아드려 출하를 지시할 때도 있다.

                            「경영진이 진정한 품질관리 그룹이다」

테스트 팀의 역활은 경영진의 판단을 돕는데 있다. 테스트 팀은 남아 있는 불량의 심각함을 보고하는 것으로 출하의 가부 결정은 경영진이 판단 하는 것이다. 따라서 QC그룹이 갖고 있는 실질적 권한은 경영진이 숙고해 판단할때 까지 출하를 정지해 두는 권한이다. 그러나 그것을 개발측과 QC그룹이 인식하고 있는 것은 거의 없고 QC그룹에 의한 출하 정지의 판단을 경영진이 뒤집어 버리면 QC그룹의 입장이 난처해져 버린다.

또 QC그룹이 강한 권한을 갖은 것 처럼 보이기 때문에 개발측은 공포와 불신감을 갖게될 수도 있다.

결과적으로 프로젝트 매니저는 QC그룹에게「적절」하다고 압력을 행사한다. 그러나「적절」함은 잘 정의되어 있는 것이 아니다. 예를 들어 이러한 테스트는 적절한 것인지?

-  테스트의 각 사이클에서 새로운 테스트 케이스를 추가 하는 것
-  실제에는 결코 입력 안되는 극단적인 값으로 테스트 하는 것
-  일부러 이상한 데이타를 읽어 들이는 것
-  현장에서 바로 테스트 케이스를 작성하는 것
-  특수한 경우에만 발생하는 조그만 버그를 보고하던지 설계의 잘못을 지적하는 것
-  장해 레포트에 개선요망 사항을 기록하는 것
-  장해 레포트에 설계서의 잘못을 기록하는 것

-        사전에 명시되어 있는 테스트에 합격되지 않았다고 테스트를 거부하는 것
-        해결하는데 시간이 걸린다고, 그저 1개의 불량 때문에 테스트를 거부하는 것

프로젝트 매니저 중에는 제품과 자신이 불리하게 될경우 모든것을 부적절 하다고 판단하는 사람도 있다.그래서 QC부문의 책임자가 부적절하다고 판단하는 것이 부적절 하다고 거절하는 경우도 있다.

적절한지 어쩐지는 놓아두고 QC라는 직책을 수행하고 있는 한은 적절한지 어쩐지에 관해 장시간 의논해야 한다는 것을 각오해야 한다. 
필자의 인식으로는 QC 그룹는 미움받고 잠재적으로 적대관계에 있다고 인식된다. 또한 평가는 낮고 품질에 대하여  그렇게 공헌을 하지 못 한다고 생각하고 있다.
또 QC그룹이 갖고 있는 권한은 실제 매우 한정되어 있어 간단하게 뒤집어 버리고 만다.

품질보증 (QA： Quality Assurance) Type의 그룹
QA타이프 그룹은「품질보증」을 위한 그룹이다. 그러나 테스트 만으로 품질을 보증하는 것은 불가능 하다. 품질 나쁜 프로그램을 철저하게 테스트해 버그를 수정해도「충분히 테스트한 품질 나쁜 프로그램」에 지나지 않다.  사실은 QA그룹은 전 개발공정에 관여할 필요가 있다. 표준을 책정해, Review방법을 생각하고 설계 또는 개발을 개선하는 방법을 지적한다. 즉 QA그룹의 성과는 불량의 예방에 있다. 물론 테스트도 하지만 그것은 업무의 일부 일뿐이다.

실로 QA그룹은 엄청난 기술을 갖고 있지 않으면 안된다. 이런 점에 주의할 필요가 있다. 분석, 설계 , 실행, 프로젝트 관리, 문서 작성등 모든 일에 유능할 필요가 있다. 그렇치 않으면 신뢰 받기 어렵기 때문이다.

「품질보증」이라고 부르는 방법은 매우 위험하다.  만약 어떤 그룹이 품질을 보증 한다고 하면 다른 부문은 보증하지 않아도 괜찮은 것인지. 이 문제는 Juran(1989)으로 부터 제기된 것으로 독립된 QA그룹을 배치 한다는 생각은 제 2차세계대전 전에 생겨 났으나 안타깝게도 제대로 기능을 하지 못했다.  적어도 소프트웨어 개발조직에서 작업을 한 경험이 있다면 프로젝트 매니저의 불만을 들은 적이 있을 것이다.  「나의 일은 납기까지 제품을 완성 시키는 것이지 품질을 확보하는 것은 나의 일이 아니고 QA의 일이다 」 품질의 책임을 경영진 이외의 부문에 집약 시키면 실패한다.

회사전체, 특히 경영진이 품질에 책임을 갖지 않으면 안된다. 이것은 일본과의 경쟁에 의해서 얻은 교훈으로 (Deming 1982), TQM(통합적품질관리)의 기초가 되는 생각이다
실제에는 QA라고 불리는 그룹이 품질보증은 하지 않고 테스트 만을 하고 있는 경우가 많다.
혼돈하는 것도 무리는 아니지만 QA그룹의 역활은 테스트 만이 아니다 라는 것을 이해하면 할수록  테스트만 수행하는 QA그룹의 사람은 즉 테스트에만 제한되어 있다고 생각하게 되며 테스트 담당자 로서 완벽해도 타의 임무를 소화하지 못해 하고 싶은 열정을 잃게 된다.

테스트 기술 Type 그룹
프로젝트 매니저에게 테스트 기능을 제공하는 것이 테스트 기술 Type그룹이다. 주어진 역활은「프로그램 버그」를 발견하여 상세하게 설명하여 알려야 할 사람에게 확실하게 정보를 제공하는 것이다. 테스트 기술그룹에는 제품을 출하하는 권한도 출하를 정지하는 권한도 없다. 프로그램의 불량과 테스트 실시의 상황 등을 보고하면 경영진이 최종판단을 내리게 된다. 그룹에 따라서는 제품의 일부 만을 테스트 하는 경우도 있다. 특히 각 사이클의 테스트에서 전부를 테스트하는 경우는 없다. 또 회사의 방침으로 프로그램머가 테스트를 주로 담당하고 테스트 그룹은 보조 작업만을 하는 경우도 있을지 모른다. 테스트 기술그룹의 작업은 상세한 기능 일람의 작성과 순서를 기술하는 것으로 필요 하다면 테스트의 자동화를 수행한다.  테스트의 분석 , 설계, 설치, 실시, 기록의 모든 책임을 지는 역활이다. 프로 로서의 프라이드를 부하에게 갖도록 하자.

프로젝트 매니저 중에는 테스트기술의 제공 보다도 품질관리의 책임을 테스트 기술그룹에 희망하는 사람도 있다. 무리하게 QC타이프로 하려고도 한다. 테스트의 책임은 전부 테스트 팀에 있고 프로그램머는 화이트 박스 테스트 조차 필요 없다고 선언하는 경우도 있다. 테스트 팀이 발견 못한 버그는 수정하지 않아도 좋다고 말하며 버그를 발견 못한 것을 비난 하기도 한다. 이러한 태도는 품질에 대한 책임을 포기 하려고 한다고 이해할 필요가 있다. 품질을 강요하는 듯한 책략을 사용할 때에는 강하게 저항 하도록 하자. 이럴 경우는 분명히 난제에 봉착하게 된다.

다른 전부문과 대립하는 상황이 되기 쉬우니 상사에게 업무의 조율를 부탁하도록 한다.

「프로젝트 매니저야 말로 진정한 품질보증의 리더 이다. 테스트 기술그룹은 기술적인 정보를 제공하고 설명하는 것으로 품질에 관한 판단을 돕는데 있다. 」
이와 같은 정의는 테스트 기술그룹의 책임을 회피하는 것이 아니고 테스트의 실시며 문서의 작성 테스트 결과의 해석에 관해서  질 높은 작업을 신속하게 제공할 책임이 있기 때문이다. 품질에 관한 판단을 하지 않지만 테스트 기술그룹은 전문가 로서 도움이 된다 라는 현실을 부정할 것은 못된다. 또 품질에 관한 판단을 포기 했다고 해서 테스트 기술그룹의 권한을 실질적으로 전부 거둬 버리는 것도 아니다. 프로젝트 매니저와 의논하거나 경영진에 정보를 제공하는 권한이 아직 남아 있다. 이와 같은 권한을 잘 살리기 위해서는 데이타의 수집 능력과 표현 능력의 향상이 필요하게 된다. 생산라인의 정지며 새로운 순서의 제시 보다도 데이타를 기초로 해서 정확한 표현으로 설득하는 편이성과가 크다.
   

개발기술 Type 그룹
개발기술 타이프의 테스트 팀은 테스트 기술 타이프를 확장한 것으로 기술을 제공하지만 관리며 판단은 하지 않는다. 정치적인 교섭도 하지 않는다. 테스트의 전문기술을 더해 품질의 개선, 개발측의 지원, 개발자가 전문성을 배양할 수 있도록 품질 향상 기술의 제공이 개발 기술그룹의 역활이다.

개발기술 그룹에 있어서 테스트는 주 업무이고 어떠한 조직에 있어서도 요구되는 것이다.
-        디버그
-        고객에 대한 기술지원
-        메뉴얼 교정
-        메뉴얼의 기술적인 평가 (보통 테스트 담당자보다 훨씬 강한 권한으로 기술적 검증을 수행한다)
-        조작성 테스트
-        호환성 테스트
-        고객 만족도 조사

담당자에 따라 기술과 취향에 차이가 있어 이러한 작업이 캐리어의 발전에 도움이 되는 경우가 있는가 하면 지겨워 죽을 정도로 하기 싫어하는 작업으로 느끼는 경우도 있다. 테스트 이외의 일을 포함하여 무슨 작업을 하고 싶은지 질문하여 도움이 될 수 있도록 하자.

필자는 QC와 QA라고 하는 종래의 개념을 초월한 4타이프 그룹의 테스트 팀 개념을 강하게 추천하고자 한다. 특히 개발기술 타이프의 그룹의 발상은 마음에 들지만 충분히 시험한 것이 아니며 적용시에는 주의가 필요하다. 테스트 기술 타이프 그룹은 잘 운영 되지만 부하 직원의 케리어에 주의하지 않으면 필시 전직해 버릴 것이다.

테스트 팀은 하늘의 도움이 아니다.

테스트 팀이 없는 개발부문에서는 코드가 정확하게 동작하는 것을 자신이 보증하지 않으면 안된다. 그러나 테스트 팀이 있으면 긴장이 풀려 버그를 놓치게 된다. (결국 테스트 팀이 부담을 갖게 되는데 정말로 이래도 되는 것일까) 개발자 자신이 테스트 해서 정상인지 아닌지 신경써 주기를 테스트 팀에서는 바라고 있다. 확실하게 버그를 발견할 수 있고 비용을 낮출 수 있기 때문이다.
버그의 대부분은 프로그램머가 먼저 발견하기 때문이다 .  누구 보다도 코드를 이해하고 있고 버그가 있을만 한 곳을 잘 알고 있다. 테스트 팀은 프로그램머가 놓쳐버린 버그를 발견 하지만 프로그램머 도 물론 테스트에서는 놓쳐버린 버그를 발견할 수 있다.

프로그램머는 비교적 낮은 비용으로 버그를 발견한다. 문제의 발견이 빠르면 빠를수록 발견과 수정에 드는 비용이 감소한다. 그 이유를 열거해 보자.
-        문제를 파악하기 위해 몇번이고 테스트하여 재현할 필요가 없다. 버그가 있을만 한 부분을 직접 조사할 수 있고 더구나 발견되면 즉시 수정이 가능하다.
-        타인에게 불량을 설명할 필요가 없다.
-        설계서를 확인 하거나 장해 보고를 한다던지 수정 사항을 보고할 필요가 없다. 보고서를 작성할 시간에 버그를 수정하는데 힘을 쏟을 수 있다

애석하게도 프로그램머에 의한 테스트는 점점 줄고 있다.  개발측의 매니저는 테스트에 시간이 걸리는 것을 인식하고 있기 때문에 프로그램머에게 테스트를 생략 하도록 지시하여 개발이 빨리 완료 되었다고 하려고 한다. 자주 일어나는 일이지만 심한 경우는 프로그램머가 테스트를 거의 하지 않아 테스트 작업시 파닉크 상태에 빠지기도 한다.
테스트 팀을 조직할 때는 마음 속으로 준비해 두어야 할 사항이 있다. 종래의 사내표준에 따라 테스트 한다고 해도 대단한 작업이기 때문에 테스트 팀은 자신을 포함하여 최저 4명 이상으로 구성할 필요가 있다.

    
테스트 전문 아웃소씽
사내에서 전업무를 테스트 할 필요는 없다. 테스트 전문 기업에 메뉴얼과 프로그램을 위탁하면 프로그램이 문제없이 동작 할 때까지 몇번이고 열심히 테스트해 줄 것이다.
「소프트웨어 테스트에 관한 문헌을 읽어보면 제 3자가 독립적으로 테스트를 수행 해야만 제품의 신뢰성이 향상된다」라고 강한 신념이 묻어 있다는 것을 알 수가 있다.」
필자의 경험으로는 전문회사에의 테스트가 만능도 절대적인 것도 아니며 주의해야 할 문제를  나열해 보자.

-        생각만큼 독립적인 테스트가 가능한지
개발측과 거리를 두고 테스트 팀의 독립성을 보장 한다는 역활과 계약은 없다. 테스트중에 계약해지 당하고 싶지 않고, 다음 제품의 테스트 작업도 수주하고자 생각하고 있다.

그리고 개발측의 눈치를 보며 잘 보이려고 하여 버그를 발견하지 않으려고 할지도 모른다.

-        아웃소씽 업체의 표준이 사내표준 보다 질이 낮을수 있다.
특히 설계에 관해서는 언급하지 않는 경향과 설계서, 메뉴얼과 일치하면 버그라고 하지 않는 경향이 있다.  테스트를 아웃소씽 할 경우는 테스트 설계를 철저히 하는 역활의 배치도 필요하다.

-        테스트 전문 업체라고 해도 기술이 높지 않은 경우도 있다.
-        중요한 테스트를 놓치는 것은 사내도 아웃소씽 업체도 같다.
-        관리업무와 기술지원을 수행하지 않는 경우도 있다.
-        아웃소씽이 비용절감은 아니다.
-        제품 고유의 지식을 갖고 있지 않다.
-        보고된 장해를 사내에서 전부 재현해 둘것
-        관련된 장해를 찾아 볼것
-        GUI는 사내 첵크할 것

아웃소씽 업체의 테스트와 무관하게 테스트해 둘 것
-        테스트 대상 업무가 누락된 것은 없는지 확인할 것

테스트 스케쥴 작성 방법
테스트 팀의 매니저는 프로젝트의 스케쥴에 관한 책임을 일부 갖고 있다. 테스트 스케쥴은 상류 공정에 의존하기 때문에 작성의 어려운 점이 많고 개발이 늦어 지거나 예상 보다 버그가 많이 발생 하거나 또 유저 인터페이스의 변경 등으로 테스트 시간이 늘어나기도 한다. 정말로 어려운 국면에 처해 있지만 도망갈 수도 없고 변명도 할 수 없다.  
스케쥴 작성의 중요한 목적 4가지를 열거한다.

-        프로젝트 메니저에게 프로젝트의 진행 사황을 전달하기 위함
프로젝트 메니저는 테스트에 필요한 작업과 각각 어느 정도 시간이 걸리는지 알아 둘 필요가 있다.
-        일정을 앞당길 수 있는지 엄수해야 할 일정은 언제인지 판단을 할 수 있는 자료로 활용
-        무리한 작업으로 테스트 작업의  미스를 방지 
-        생산성을 최대로 높이기 위해
인간은 달성 가능한 스케쥴 이라면 어려워도 열심히 일을 한다.  달성 불가능한 스케쥴을 세워서는 안된다. 잔업, 휴일출근이 많으면 필요 최저한만 일을 하게 되어 버리며 일정을 늦추는 결과를 초래하며 제품의 개선 등의 제안을 하지 않게 된다.
   
테스트의 스케쥴이 정직하고 확실하게 작성되면 스케쥴 작성 목적은 전부 만족하게 된다.  

테스트 공수 산정 방법
1. 실적과 생산성 이용 방법
-  평균 테스트 사이클 횟수
       보통의 프로그램을 릴리스 가능한 품질까지 테스트 하는데 평균 8사이클의 테스트가 필요하다. 많을 경우는 12 사이클, 적을 때는 7사이클 이하의 큰 차이가 있다.
-  1회 사이클 테스트에 걸리는 시간
-  1일 보고되는 버그 수
-  테스트 1건당의 소요 시간
-  1시간당 Review 가능한 Page수
    물론 토큐멘트의 종류와Review의 목적에 따라 다르다.
-  1시간당 테스트 가능한 에라 메세지 수
     　 에라 처리의 테스트에는 어느정도 공수가 필요한지
    -  1시간당 실시 가능한 테스트 항목 수

2. 작업의 일람표 이용 방법
  필요한 테스트의 작업을 전부 열거하여 일람표를 작성한다. 특히 누락 항목이 없도록 주의할 것
-   간단하게 테스트할 수 없는 작업을 알 수 있다
    -   작업에 우선순위를 부여할 수 있다
    -   부분적으로 실시하여도 작업을 명확화 할 수 있다.
    -   자동화 하여 생산성을 올릴 수 있는 작업의 선별이 가능하다.
    -   주어진 일정으로 테스트를 완료할 수 없는 이유, 요원의 증원, 시간 , 자금 등 상세하게
        설득력 있는 문서 작성이 가능하다.

3. 프로젝트의 분류에 의한 방법
-   제품의 복잡성으로 판단한다.
    -   테스트 대상 프로그램의 신뢰성으로 판단.
        어떤 프로젝트 메니저와 어떤 프로그램머가 개발 했는지에 따라 신뢰성의 점수를 부여한다.
    -   공수 산정 테이블을 작성한다.
        제품의 복잡성과 신뢰성으로 테이블 작성

http://www.ncicom.co.kr/board/view.php?id=data&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=9

. Automated Testing?

1.1 automation testing 이 요구되는 분야

1.1.1 스케줄이나 인력에 비해 빠르고 적절한 테스트가 요구될때

1.1.2  1000  명의 가상유저가 필요한 작업등.

현재의 개발 프로세스는 점점 빠르고 점진적인 빌드관리를 통해, 사용자에게 노출하여, 사용자의 요구와 선호를 반영하는 반복적인 빌드로 나타난다.  이에 따라 소프트웨어에 대한 테스트 또한 매빌드마다 새로운 작업의 증가와 같이 반복적인  작업에 노출될수 있다. 이에 따라 오토매이션 스크립트는 각 빌드에대해 해당 소프트 웨어의 정확성과 안정성을 체크해주는 도구로 중요도가 높아지고 있다.

오토매이션 테스팅 툴의 시작은 레코딩과 캡쳐 이겠지만 점점 진화되면서, 그래피컬 사용자 인터페이스테스트, 퍼포먼스, 웹인터 페이스, 네트워크 작업, 메모리 릭 등의 작업에 적응될수 있다.

현재 90%의 개발자들의 shipday 에 맞춰 제품을 만들지 못하며, 91%의 제품들이 출시날자를 맞추기 위해 중요한 기능을 포기한채  릴리즈 한다. 점점 개발과 테스트에 대한 짧은 기간이 주어진다

 

 

... 자세한 것은 첨부 참조

원본 : Usability Engineering (by Jakob Nielsen)
마지막 10장은 별로 필요없는거 같아 정리안했었고요...
입문서로 괜찮을듯 하네요..
저작권은 불법번역이므로 공식적인 자료로는 쓰지 말아주세요

Enclosed the presentation given at SQMS on December 10th in Seoul.

I wanted to share this with you as in Korea these methodologies might not be as known, yet are very important to know.

If you have any questions or remarks, please let me know!

Patrick 

 

 

 

Rational Unified Process를 위해 만들어진 Test Plan인데 일반적으로 모든 경우에 적용될 수 있는 포멧(Template)인 것 같습니다.

보시고 필요하시면 활용하시길...

 

- 영문 html 및 수정한 DOC 파일

SW 개발과정에서 시험할 때 해야할 일과 하지 말아야할 일 리스트를 정리한 자료입니다.

허술한 부분이 없지는 않지만 나름대로 각각의 시험 단계별로 내용을 잘 정리해 두었습니다.
Test Engineer 들이 자신들이 시험하면서 느꼈던 해야할 일들과 하지말아야할 일들을 더하여 리스트를 발전시킨다면, 쓸모있는 자료가 되지 않을까 생각합니다.

 

- 영문 DOC 파일

SW 테스팅 교재 (시스템 테스팅 중심) - 영문 PDF