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

이 문서는 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. 테스트 문서화하기

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

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

소프트웨어 개발 시 타협점

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

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%의 제품들이 출시날자를 맞추기 위해 중요한 기능을 포기한채  릴리즈 한다. 점점 개발과 테스트에 대한 짧은 기간이 주어진다

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

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 파일

첨부문서 참고