ISTQB Syllabus 2005 통합정리 (3. Review)

원문 : http://blog.naver.com/josephy74/70018639453
문제가 될 경우 바로 연락주세요. 바로 삭제하겠습니다.

3.1 Reviews and the test process (K2)

 

정적 테스팅 기법(Static testing techniques)은 테스트되는 소프트웨어를 실행하지않는다.; 정적 테스팅 기법은 매뉴얼 리뷰 또는 자동화된 정적 분석 기법들이다.

 

리뷰(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 하게 할 수 있음

 

3.3 Static analysis  by tools (K2)

 

정적 분석(Static analysis)의 목적은 소프트웨어 소스 코드나 소프트웨어 모델에서 결함(defects)을 발견하는 것이다. 정적 분석은 도구에 의하여, 시험되어지는 소프트웨어의 실제적인 실행없이 수행된다. 동적 테스팅(dynamic testing)은 소프트웨어 코드를 실행시킨다. 정적 분석은 테스팅에서 발견하기 어려운 결함들의 위치를 알아낸다. 리뷰와 더불어, 정적 분석은 실패(failure)보다는 결함(defects)를 찾는다. 정적 분석 도구는 프로그램 코드를 분석(e.g 컨트롤 플로우와 데이터 플로우)하며, HTML과 XML과 같은 결과물을 생성한다.

 

정적 분석의 가치는 다음과 같다.

 

• 테스트 실행 이전 결점의 조기 감지
• 높은 복잡성(complexity) 측정과 같은 특성(metrics) 계산에 의한 코드 또는 설계의 의심스러운 측면에 대한 초기 경고
• 동적 테스팅에 의하여 쉽게 발견되지 않는 결함의 정의
• 링크와 같은 소프트웨어 모델에서의 의존성과 불일치성 감지
• 코드와 디자인의 유지보수성(maintainability) 향상
• 개발에서 배워진 교훈이 있다면, 결함의 방지

 

정적 분석 도구에 의하여 발견되는 전형적인 결점들은 다음을 포함한다.

 

• 정의 되지 않은 값을 가진 변수의 참조
• 모듈과 컴포넌트 사이의 일관적이지 않은 인터페이스
• 사용되지 않는 변수
• 실행할 수 없는(죽은) 코드
• 프로그래밍 표준 위반 사항
• 보안 취약성들
• 코드와 소프트웨어 모델의 구문 위반사항(syntax violations)

 

컴포넌트 테스팅과 통합 테스팅 하는 동안이나 그 이전에, 그리고 디자이너가 소프트웨어 모델링을 하는 동안에, 정적 분석 도구들은 일반적으로 (미리 정의된 규칙 혹은 프로그래밍 표준에 대한 확인을 위하여) 개발자에 의하여 사용된다. 정적 분석 도구는 가장 효과적인 도구의 사용을 위하여 제대로 관리되는 것이 필요한 많은 수의 경고 메시지를 만들어 낼 것이다.

 

컴파일러들은 특성의 계산(calculation of metrics)을 포함한 일부 정적 분석 기능을 지원할 수 있다.

 

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

What is NOT relevant to the static analysis?

 

1. Find defects in software source code and software models
2. Performed withtout actually executing the software being examined
3. Locates defects that are hard to find in testing
4. Finds failures rather than defects

 

◆ 정적 분석의 가치

 

▪ 테스트 수행전 결함 발견
▪ 의심스러운 코드와 설계에 대한 조기 경보 (프로그램 복잡도 등의 매트릭을 계산해서...)
▪ 동적 테스팅에서 발견하기 어려운 결함 발견
▪ 소프트웨어 모델에서의 의존성과 불일치성 발견
▪ 코드와 설계의 유지보수성 향상
▪ 결함 예방 (if lessons are learned in development)

 

◆ 정적 분석을 통해 발견되는 결함

 

▪ 정의되지 않은 값으로 변수 참조
▪ 모듈과 컴포넌트 간에 일관되지 않은 인터페이스
▪ 사용되지 않는 변수
▪ 사용되지 않는 코드 (Dead Code)
▪ 코딩 표준 위반
▪ 보안 취약성
▪ 코드와 소프트웨어 모델의 syntax 위반