머가필요해

리뷰(Reviews)는 소프트웨어 작업 산출물(코드를 포함해서)을 테스트 하는 방법이며, 동적 테스트(dynamic test)에 실행 전에 수행 될 수 있다. 수명주기(life cycle) 초기 리뷰동안에 감지된 결함(defects)들은 테스트를 실행하는 동안에 감지된 결함들보다 제거하는 비용이 적게 든다.(e.g 요구사항에서 발견된 결점)

 

리뷰는 전적으로 인력을 요하는 액티비티이지만, 도구를 이용하는 것 역시 가능하다. 인력을 요구하는 주된 액티비티는 작업 산출물(work products)을 시험하고, 그에 대한 논평을 하는 것이다. 요구 사항문서, 디자인 명세, 테스트 케이스, 테스트 스크립트, 사용자 가이드 또는 웹 페이지를 포함한 모든 소프트웨어 작업 산출물은 리뷰의 대상이 될 수 있다.

 

리뷰의 해택은 초기의 결점 발견과 정정, 개발 생산성 향상, 개발 시간 축소, 테스팅 비용과 시간의 축소, 개발 비용 축소,  더 적은 결함과 커뮤니케이션의 증가를 포함한다. 예를 들어, 리뷰는 동적 테스팅에서 발견할 수 없는 요구사항의 빠진 부분을 발견 할 수 있다.

 

리뷰, 정적 분석과 동적 테스팅은 동일한 목적-결함을 찾는것-을 가진다. 이들은 상호보완적이다. 각기 다른 기법들은 여러가지 종류의 결함을 효과적이고 효율적으로 찾을 수 있다. 동적 테스팅과 대조하여, 리뷰는 실패(failures)보다 결함(defects)를 찾는다.

 

표준의 미준수(deviations from standards), 요구사항내의 결함(requirements defects), 설계상의 결함(design defects), 불충분한 유지보수성(insufficent maintainability)과 잘못된 인터페이스 명세(incorrect interface specifications)와 같은 전형적인 결함들은 동적 테스팅보다 리뷰에서 쉽게 발견된다. 

 

=============================================================================

 

리뷰 (Review)

 

▪ SW 중간 산출물을 테스팅하는 방법
    - 프로그램 코드, 요구사항 명세서, 설계 명세서
    - 테스트 계획서, 테스트 설계서, 테스트 케이스, 테스트 스크립트 사용자 지침서

 

▪ 소프트웨어 개발 생명 주기의 앞부분에서 수행하여 결함 제거 비용이 저럼

 

▪ 개발 생산성 향상, 개발 시간 단축, 테스트 비용과 시간 단축
    - 보다 적은 내재 결함 수와 향상된 의사 소통으로 위 사항을 가능케 한다.

 

▪ 테스팅 기법별로 다른 종류의 결함 발견 (상호보완적)
    - 리뷰 : 코드 또는 문서상의 결함 (failure는 발견하지 못함)
        표준과의 불일치성, 설계 결함, 유지보수의 불충분성, 인터페이스 명세 결함
    - 정적분석 : 코드의 복잡도, 구문 에러, Missing 파라미터, Dead 코드 등

 

Review의 필요성

 

▪ 테스팅 보다는 Review에서 결함을 발견하는 것이 더 효율적
   - 단위 테스트에서 시간당 2~4개 정도의 결함을 발견한다면
   - Code Review에서는 6~10개 정도의 결함을 발견

▪  단위 테스트 후의 결함제거에는 많은 비용이 필요
   - 통합 및 시스템 테스트에서 각각의 결함을 발견하고 수정하는 데 걸리는 시간은 10~40 M/H 정도
   - Inspection은 결함당 1시간 이내 소요

▪ 빠른 결함 제거 시 시간과 비용 절감 효과가 있다.
   - 개발 후반기 결함을 발견하고 수정하는 경우 더 많은 결함 비용 소모
   - 개발 완료 후 결함을 발견하고 수정하는 경우에는 보다 많은 결함 비용 소요

 

◆ Informal Review VS Technical Review

                   |  Informal Review                       |   Technical Review
--------------------------------------------------------------------------------
주요 목적     |    저비용 문서/코드 검토             |  기술적 문제 해결
                  |                                                |  토론, 의사결정, 대안 평가, 결함발견
                  |                                                | 명세서 또는 표준과의 적합성 체크
--------------------------------------------------------------------------------
참여자         | (선택적) Pair 프로그램밍 or         | 동료 또는 기술 전문가가 문서화되고
                   | 기술 선임자가 설계와 코드 리뷰   | 정의된 결함 발견 프로세스에 참여
--------------------------------------------------------------------------------
문서화 여부  | (선택적) 문서화                          |실무에서는 Informal 또는 formal
--------------------------------------------------------------------------------
효과            | 리뷰어에 따라 효과가 다양           | 실무에서는 Informal 또는 formal
--------------------------------------------------------------------------------
사전준비      |                                                  | 미팅 사전 준비 단계 거침
--------------------------------------------------------------------------------
미팅 주도 및 |                                                  | 이상적으로는 Moderator가 미팅 주도
활용 도구     |                                                  | (선택적) 체크리스트, 리뷰 리포트
(문서)          |                                                  | 인시던트 리스트, 경영층 참여 활동
--------------------------------------------------------------------------------

◆ 리뷰 성공 요소

 

▪ 각각의 리뷰가 명확하게 기정의된 목적이 있어야 함
▪ 적합한 인력이 선택되어야 함
▪ 결함 발견은 언제나 환영하는 분위기이고 결함은 객관적으로 표현되어야 함
▪ People issues와 심리적인 측면이 고려되어야 함
▪ 리뷰 기법이 적절히 적용되어야 함
▪ 효과적/효율적인 결함 발견을 위하여 필요시 체크리스트 활용 (역할 분담도 적절히 활용)
▪ 리뷰 기법에 대한 교육 훈련 제공 (특히, 인스펙션의 경우)
▪ 경영층이 리뷰 프로세스를 지원 (프로젝트에서 리뷰 기법 적용에 충분한 일정 할애)
▪ 학습과 프로세스 개션에 대한 강조

 

3.2 Review process

 

리뷰(Reviews)는 비형식적인 것에서 부터 매우 형식적인 것(i.e 잘 구조화되어 있고, 규칙적인)까지 다양하다. 리뷰 프로세스의 형식(formaility)은 개발 프로세스의 성숙도, 법적(legal) 요구사항과 규정(regulatory) 요구사항 또는 감사 추적(audit trail)에 대한 필요성과 관련이 있다.

 

리뷰를 수행하는 방법은 합의된 리뷰의 목적에 의존한다. (e.g 결함의 발견, 이해의 획득, 또는 여론에 의한 논의와 결정)

 

3.2.1 형식적 리뷰의 단계 (Phase of a formal review)

 

전형적인 형식 리뷰는 다음의 주요한 단계(Phase)를 갖는다.

 

• 계획(Planning) :

계획 단계에서는 인력을 선발하고, 각 개인에게 역할(role)을 할당하며 문서들의 어떤 부분들을 살펴 볼 것인가를 결정한다. 그리고, 점검(inspection)과 같이 좀더 형식적인 리뷰를 위해서 시작과 좋료 조건(entry and exit criteria)을 정의한다.

• 킥 오프(Kick-Off) :

Kick-Off 단계에서는 문서를 분배하고, 참가자들에게 리뷰 목적, 프로세스, 문서들에 대해 설명한다. 그리고, 좀더 형식을 필요로 하는 리뷰들을 위해서 시작 조건을 확인한다.

 

• 개별 준비(Individual preparation) :

개별 준비 단계에서는 참가자 개개인들 스스로가 리뷰 미팅 전에 잠재적인 결함, 질문과 코맨트들을 기록한다.

 

• 리뷰 미팅(Review meeting) :

(좀 더 형식적인 리뷰 타입을 위한) 문서화 된 기록 또는 상세한 기록과 더불어 논의와 로깅을 한다. 미팅 참석자들은 결함(defects)을 처리하기 위한 충고사항을 제시하거나 결함에 대한 결정을 하기 위하여 간단하게 결함을 기록할 수 있다.

 

• 재작업(Rework) :

발견된 결함을 고친다. 일반적으로 작성자(Author)에 의하여 행해진다.

 

• 추가작업(follow up) :

사후 점검 단계에서는 처리된 결점을 확인하고 측정 기준들을 수집한다. 또한 좀더 형식적인 리뷰들을 위해서 종료 조건에 대한 확인도 한다.

 

3.2.2 역할과 책임 (Roles and responsibilities) (K1)

 

• 관리자 (Manager) :

리뷰 실행에 대한 결정을 하고, 프로젝트 일정내에 리뷰 시간을 할당한다. 그리고 리뷰의 목표가 달성되었는가를 결정한다.

• 중재자 (Moderator) :

리뷰 계획, 미팅의 운영, 그리고 미팅 후 추가 사항을 포함하는 문서 혹은 문서 셋(document set)의 리뷰를 이끄는 사람을 말한다. 중재자는 다양한 관점들 사이를 중재할 수 있으며, 때때로 리뷰의 나머지 부분을 이끈다.

 

• 작성자(Author) :

 작가 혹은 리뷰된 문서에 대한 주된 책임을 가지고 있는 사람

 

• 리뷰어(Reviewer) :

특정 기술 혹은 비지니스 배경을 가지고 있는 개인 (Checker 또는 Inspector로 불려질 수 있다.)으로 필요한 준비후에 리뷰 동안에 제품에서 발견된 사항(e.g 결함)을 정의하고 묘사하는 사람. 리뷰어는 리뷰 프로세스에서 표현되는 다양한 관점과 역할을 선택할 수 있어야 하며, 모든 리뷰 미팅에 참가해야 한다.

 

• 필기자(또는 서기)(Scribe(or recorder)) :

모든 이슈사항, 문제 그리고 미팅 동안에 정의되어야 하는 문제점(-미정사항open points)을 문서화한다.

 

여러가지 관점에서 문서를 살펴보는 것과 체크 리스트(checklists)를 이용하는 것은 리뷰를 더욱 효과적이고 효율적으로 만들 수 있다. 예를 들어, 사용자, 유지 보수인력(maintainer), 테스터 또눈 운영자 같은 측면에 기반한 체크 리스트나 전형적인 요구사항 문제들에 대한 체크 리스트는 리뷰를 더욱 효과적이고 효율적으로 만들 수있다.

 

3.2.3 리뷰 타입 (K2)

 

하나의 문서는 하나 이상의 리뷰의 주제가 될 수 있다. 만약 한 종류 이상의 리뷰가 수행된다면, 순서는 매우 다양해 질 수 있다. 예를 들어 비형식적인 리뷰(informal review)를 테크니컬 리뷰(technical review)에 앞서 수행 할 수 있다. 또한 요구사항 명세에 대하여 수행되는 점검(Inspection)은 고객과 함께하는 walkthrough 전에 수행될 수 있다. 일반적인 리뷰 타입들의 주요한 특성, 옵션과 목적은 다음과 같다.

 

비형식 리뷰 (Informal Review)

  주요 특성
   • 형식적인 프로세스가 없다.
   • 쌍으로 하는 프로그래밍(Pair programming)이나 기술 리더가 디자인과 코드를 리뷰하는 것이 될 수 있다.
   • 조건적에 따라  문서화 될 수 있다.
   • 리뷰어에 의존하여 유용성이 변할 수 있다.
   • 주요 목적 : 임의의 혜택을 얻는 비용이 많이 들지 않는 방법

 

Walkthrough

  주요 특성
   • 작성자(Author)에 의해 주도되는 미팅
   • 시나리오들, 리허설(dry runs), 동료 그룹
   • 미 종결된 세션
   • 조건적인 리뷰어들의 선 미팅 준비(pre-meeting preparation), 리뷰 리포트, 발견 사항과 필기자(scribe)의  리스트
   • 실제로 상당히 비형식적인 것에서 부터 매우 형식적인 까지 다양하다.
   • 주요 목적 : 배우고, 이해하고, 결점을 찾는다.

 

기술 리뷰 (Technical Review)

  주요 특성
   • 문서화 되고, 동료와 기술적인 전문가를 포함하는 결함 탐지(defect-detection)을 위한 정의된 프로세스
   • 관리자의 참가없이 동료가 리뷰를 함으로써 수행될 수 있다.
   • 이상적으로는 훈련된 조정자(작성자가 아닌)에 의하여 주도된다.
   • 선 미팅 준비 (pre-meeting preparation)
   • 때때로 체크 리스트, 리뷰 리포트, 발견 사항의 리스트를 사용하고 관리자가 참여한다.
   • 실제로 상당히 비형식적인 것에서 부터 매우 형식적인 까지 다양하다.
   • 주요 목적 : 논의, 결정, 대안 사항의 평가, 결함(defect)의 발견, 기술적인 문제 해결, 명세와 표준의 준수 확인

 

점검 (Inspection)

   주요 특성
   • 훈련된 조정자(moderator)에 의하여 주도된다.
   • 동료에 의한 평가가 일반적이다.
   • 정의된 역할
   • 특성(metrics)을 포함한다.
   • 항목(entry)과 종료 특성(exit criteria)을 가진 규칙(rules)과 체크 리스트(checklists)에 기반한 형식적인 프로세스
   • 선 미팅 준비 (pre-meeting preparation)
   • 점검 보고서(Inspection report), 발견사항 리스트(list of findings)
   • 형식적인 사후 처리 프로세스 (formal follow-up process)
   • 때때로, 프로세스 향상과 리더(reader)가 필요하다.
   • 주요 목적 : 결함의 발견

 

3.2.4 리뷰의 성공 요소 (K2)

 

리뷰의 성공 요소는 다음을 포함한다.

 

  • 각각의 리뷰는 명확하게 미리 정의된 목표를 갖는다.
  • 리뷰 목적에 맞는 적절한 인력이 포함되어야 한다.
  • 결함의 발견은 환영되어야 하며, 객관적으로 표현되어야 한다.
  • 사람들의 이슈사항과 심리학적인 측면을 다룬다.(e.g 작성자에게 긍정적인 경험으로 만든다.)
  • 리뷰 기법이 적용되며, 리뷰 기법은 소프트웨어 작업 산출물과 리뷰어의  레벨과 종류에 적합해야 한다.
  • 만약 결함 확인의 효과를 증가시키는데 적당하다면, 체크 리스트와 역할이 사용된다.
  • 리뷰 기술에 대한 훈련을 받는다. 특히 점검(Inspection)과 같은 매우 형식적인 기법에 대해서는
  • 관리자가 옳바른 리뷰 프로세스를 지원한다. (e.g 프로젝트 리뷰 액티비티에 대한 적당한 시간을 짜 넣으므로써)
  • 학습과 프로세스 향상에 대하여 강조한다.

 

◆ 리뷰(Review)

 

▪ SW 중간 산출물을 테스팅 하는 방법
   - 프로그램 코드, 요구사항 명세서, 설계 명세서
   - 테스트 계획서, 테스트 설계서, 테스트 케이스, 테스트 스크립트, 사용자 지침서
▪ 소프트웨어 개발 생명주기의 앞부분에서 수행하여 결함제거가 저렴
▪ 개발 생산성 향상, 개발 시간 단축, 테스팅 비용과 시간 단축
   - 보다 적은 내재 결함 수와 향상된 의사소통으로 위 사항을 가능케 함
▪ 테스팅 기법별로 다른 종류의 결함 발견(상호보완적)
   - 리뷰 : 코드 또는 문서상의 결함 발견 (Failure는 발견 못함)
               표준과의 불일치성, 설계 결함, 유지보수의 불충분성, 인터페이스 명세 결함
   - 정적분석 : 코드의 복잡도, 구문에러, Missing 파라미터, Dead 코드 등

 

◆ 리뷰(Review)의 필요성

 

▪ 테스팅 보다는 Review에서 결함을 발견하는 것이 더 효율적이다.
▪ 단위 테스트 후의 결함 제거에는 많은 비용이 필요하다.

 

◆ 리뷰(Review) 프로세스
  
▪ Formal 리뷰 구성 요소
   - 높은 수준의 개발 프로세스 성숙도
   - 법적 또는 제도적 요구사항이 있을 때
   - 감사를 받고자 할 때
▪ 리뷰의 다양한 목적(목적에 따라 리뷰 방식이 다름)
   -결함 발견, 이해도 증진, 토론과 의견일치에 의한 결정

 

◆ 리뷰(Review) 프로세스 단계

 

▪ 1. 계획활동
   - 역할 분담, 시작/종료 기준 정의, 검토할 문서 설정
▪ 2. 시작(Kick-off)
   - 문서 배포,목표/리뷰 프로세스/문서에 대한 설명, 시작 기준(조건) 확인
▪ 3. 개별준비
   - 잠재 결함을 체크, 회의에서 제기할 질문가 코멘트 준비
▪ 4. 리뷰미팅
   - 토론하고 기록함 (보다 formal한 경우 상세 회의록 작성)
   - 단순한 결함 체크-> 결함 대처안 제안 -> 결함 (처리)여부를 결정
     (Inspection에서는 하지 말라고 하는 것 )
▪ 5. 재작업(rework)
   - 발견한 결함 수정 (typically by the author)
▪ 6. Follow-up
   - 발견된 결함이 처리되었는지 확인, 매트릭 수집 & 확인, 리뷰 종료 기준 체크

 

◆ Fagan Inspection Process (7단계)

 

▪ 1. Planning
     - Inspection 할 산출물이 entry criteria를 만족함을 확인
     - Inspector 역할 할당 (Moderator, Authoer, Reader, Tester)
     - 다음 4단계에 대한 일정 확보
     - 2.4.5 단계를 위한 회의실 확보
▪ 2. Overview
     - Inspection 팀이 preparation 단계를 잘 실행할 수 있도록 배경 설명, context, rationale에 대한 교육 실시
▪ 3. Preparation
     - 각자 Inspection 할 산출물의 습득
     - 각자 맞겨진 역할을 수행할 수 있도록 준비
     - Defect로 단정 짓지 말고 Inspection 회의 시 질문 사항 기록
▪ 4. Inspection meeting
     - Find Defect (defect 해결책 또는 개선책을 거론하지 말 것)
▪ 5. Process Improvement
     - 향후 defect 발견을 향상 시킬 수 있도록 1~4 단계 검토
     - Systemmatic defect 식별과 Recommended fixes
▪ 6. Rework
     - 모든 발견된 defects 수정 및 조사항목 보완
▪ 7. Follow-up
    - 모든 보완 사항과 해결책이 적합한가를 검증 (20% defects의 근본 원인이 bad fixes)

 

◆ Inspector 역할

 

▪ Moderator
   - 7단계의 Fagan Inspection Process 실행 동안 Inspection 팀을 Lead하며 본인도 Inspector의 역할 담당, 팀의 synergy를 자극하며 phantom inspector 효과를 이끌어 냄
   - 자격 요건 : Fagan defect-free process를 잘 이해하며, Inspection 할 산출물을 작성할 수 있을 정도의 기술능력을 보유하고, 여러 사람과 협력하여 일을 추진할 수 있는사람
▪ Author
   - Inspection 할 산출물의 작성자이며 동시에 적극적으로 Inspector 역할 담당
   - 현재 상태에서 가능한 모든 defect를 발견하는 것이 가장 중요한 사람(방어태세 지양)
▪ Reader(Reviewer)
   - 보편적으로 본인의 업무가 inspection할 산출물에 크게 의존될 사람이 reader로 선정됨
   - Inspection 회의 시 본인이 다음 단계 업무를 수행할 수 있는 정도의 관점과 이해력을 가지고 본인이 이해한 대로 각 statement를 설명함
▪ Tester
   - 어떻게 시험할 것인가에 관점을 두어서 inspection 회의 시 질문

 

◆ Inspection의 주요 특징

 

▪ 주요 목적 : 결함 발견
▪ 저자가 아닌 훈련된 Moderator에 의한 진행 및 제어
▪ 주로 동료 검사
▪ 역할이 정의되어 있음
▪ 매트릭을 수집하고 활용함
▪ 체크리스트와 규칙을 기반으로 하는 정식 프로세스
▪ 미팅 전 준비 과정 거침
▪ 인스펙션 리포트와 발견사항 리스트 산출
▪ 정식적인 결함 수정 확인
▪ 프로세스 개선(선택적)

 

◆ Walkthrough의 주요 특징

 

▪ 주요 목적 : 결함 발견, 학습, 시스템에 대한 이해 향상
▪ 저자에 의한 진행 및 제어
▪ 시나리오, dry run, 동료 그룹
▪ Open-ended 세션
▪ (선택적) 미팅 전 준비과정 거침(리뷰어, 리뷰 리포트, 인시던트 리스트, 서기 지정)
▪ 실무에서는 Informal 또는 Formal 하게 할 수 있음

 

1.1.2 소프트웨어 결함의 원인(K2)

 

인간은 문서내에서, 시스템이나 소프트웨어에서, 코드내에서 결함을 생성하는 에러(실수)를 만들수 있다. 만약 코드내의 결함이 실행되면, 시스템은 의도한 동작을 하지 못하고(또는 해서는 않되는 동작을 하고), 이는 실패의 원인이 된다. 소프트웨어, 시스템 혹은 문서상의 결함들은 실패의 원인이 될 수 있지만 모든 결함들이 실패(failures)의 원인이 되는 것은 아니다.

 

결함(Defects)은 인간이 오류에 빠지기 쉽고, 시간의 압박이나 복잡한 코드, 하부 구조의 복잡성, 기술의 변경, 그리고/또는 많은 시스템들의 상호작용 때문에 생긴다.

 

실패(Failures)는 환경적인 조건이 원인이 될 수 있다. 발열, 자기장, 전기장, 그리고 오염은 펌웨어(firmware)내의 결점(faults)의 원인이 될 수 있으며, 하드웨어 조건의 변경은 소프트웨어가 동작하는데 영향을 줄 수 있다.

 

1.1.3 소프트웨어 개발, 유지, 운용에 있어서 테스팅의 역할

 

만약 발견될 결함들이 시스템이 운영을 위해 릴리즈되기 전에 고쳐진다면, 시스템과 문서에 대한 엄격한 테스팅은 운영 환경내에서 발생하는 문제들의 위험을 줄이는데 도움이 될 수 있으며, 소프트웨어 시스템의 품질에도 도움을 준다.

 

소프트웨어 테스팅은 계약상(법적) 요구조건들, 또는 산업에 특화된 표준들을 만족시키기 위하여 요구될 수 있다.

 

1.1.4 테스팅과 품질

 

테스팅 발견된 결함으로 소프트웨어의 기능적/ 비기능적 요구사항과 특성들 - (신뢰성(reliability), 사용성(usability), 효율성(efficiency), 그리고 유지보수성(maintainability)) - 을 만족시키는 것에 대한 소프트웨어의 품질을 측정하는 것이 가능하다.

 

비기능적인 테스팅에 대한 더 많은 내용을 위해서는 2장을 보면 된다. 소프트웨어 특성에 대한 더 많은 정보를 원한다면 'Software Engineering - Software Product Quality'(ISO 9126)을 보라.

 

만약 발견된 결함이 없거나 그 수가 적다면, 테스팅은 소프트웨어 품질에 대한 확신을 줄 수 있다. 적절하게 설계된 테스트를 통과하는 것은 시스템이 가지는 위험(Risk)의 전반적인 수준을 낮춘다. 테스팅이 결함을 발견하고, 이러한 결함들이 수정될 때, 소프트웨어의 품질은 높아진다.

 

학습자들은 이전 프로젝트에서 배워야 한다. 다른 프로젝트들에서 발견된 결함의 근본 원인을 이해함으로써, 이러한 결함들이 다시 발생하는 것을 방지하고 프로세스가 향상 될 수 있으며, 결과적으로는 향후 시스템의 품질이 향상되게 된다. 테스팅은 품질 보증 활동(Quality assurance activities)의 하나로써 통합되어야 한다.

 

1.1.5 얼마만큼의 테스팅이 적당한가?

 

얼마만큼의 테스팅이 적당한가를 결정하는 것은 기술적인 산출물과 업무적인 산출물, 프로젝트 위험, 그리고 시간과 비용 같은 프로젝트 제약사항을 포함한 위험 수준을 고려해야만 한다 (위험에 대해서는 5장에서 더 논의된다.)

 

테스팅은 다음 개발 단계나 고객에 양도를 위하여, 테스트 되는 시스템이나 소프트웨어의 릴리즈에 관한 확실한 결정을 내릴 수 있도록, 이해당사자(stakeholders)에게 충분한 정보를 제공해야 한다.

===========================================================================

◆ 테스팅이란

 => 시스템에서 결함을 찾는 것이다.
 => 결함 발견 및 수정 (때때로 예방까지)
 => 테스트는 실제 수행하는 하나하나의 실체이다.
 => 주로 결함 발견 (Defect Dectection -QC) 메커니즘을 의미하지만,

      결함 예방 (Defect Prevention -QA)과 조화를 이뤄야 한다.
 => Test case를 만들어 실행하는 것 뿐 아니라
      테스팅 전략 수립과 계획/ 설계/ 결함 수정과 도구의 사용등 포괄적인 의미이다.

▪  IEEE의 정의  

"소프트웨어의 테스트는 수동이나 자동으로 시스템을 시험 작동시키고 평가하는 작업으로 명시된 요구를 잘 만족하는지, 즉 예상된 결과와 실제 결과와의 차이를 인식하기 위한 목적을 가진다."  

===========================================================================