정적 기법

3.1.1 리뷰의 이점과 목적(Benefits and Objectives of Review)

- 수동적(Manual) 기법과 정적 분석이 있다.

- 개발 수명주기 초기에 리뷰를 통해 발견하는 수정 비용은 동적 테스팅을 통해 나중에 발견하는 결함의 수정 비용에 비해 비교적 낮다.

- 리뷰의 이점
1) 개발 수명주기 전체에 걸친 비용 감소
2) 결함 감소(품질 향상)
3) 커뮤니케이션 향상

- 정적 기법은 동적 테스팅과 달리 장애(Failures) 자체 보다는 장애의 원인(결함)을 발견한다.

- 동적 테스팅보다 리뷰를 통해 발견하기 쉬운 결함의 종류는 다음과 같다
1) 표준 위반
2) 요구사항 결함
3) 개발 설계(Design) 결함
4) 불충분한 유지보수성(Insufficient maintainablity)
5) 부정확한 인터페이스 명세

 

3.1.2 리뷰와 테스팅(Review and Testing)

- 요구사항 분석서를 통해 생성한 테스트 케이스는 시스템 또는 인수 테스팅 수행 시 활용할 수 있다.

3.2. 리뷰 프로세스

3.2.1. 공식 리뷰의 단계(Phase of a formal review)

- 계획 활동과 개별 준비, 후속 처리 확인은 리뷰 미팅을 진행하면서 강제화하여도 좋은 절차이다

- 공식적인 리뷰의 절차는
계획활동 > 시작(Kick-off) > 개별 준비 > 리뷰 미팅 > 재작업(Rework) > 후속 추적(Follow up)으로 진행된다.

1) 계획활동 : 역할 분담, 시작 및 종료 기준 정의, 검토할 문서와 범위 설정 

2) 시작(Kick-off) : 문서 배포, 목표/절차/문서에 대한 설명, 시작 기준(조건) 확인

3) 개별 준비 : 잠재 결함을 체크, 회의에서 제기할 질문과 의견(Comment) 준비

4) 리뷰 미팅 : 토론하고 기록함(보다 공식적(Formal)인 경우 상세 회의록 작성), 결함 기록 -> 결함 처리 방안 제안 -> 결함 여부 결정(결함 해결책에 대해서는 논의하지 않는 것이 원칙) 

5) 재작업(Rework) : 발견한 결함 수정(일반적으로 저자(Author)에 의해)

6) 후속 추적(Follow up) : 발견된 결함이 처리됐는지 확인, 메트릭 수집 & 확인, 리뷰 종료 기준 확인 

 

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

공식적 리뷰 : 관리자, 중재자, 저자, 검토자(인스펙터), 기록자

- 테스트 전문가는 일반적으로 검토자로서 리뷰에 참여하게 된다.

- 관리자(Manager)
1) 리뷰를 수행할지 결정하고 시간을 할당하며 목적 달성 여부를 확인한다.

2) 공식 리뷰에서 리뷰 미팅에는 참여하지 않는다. 

- 작성자(Author)

1) 리뷰 대상 문서를 작성하고 모든 변경사항을 업데이트한다.

- 기록자(Scribe)

1) 리뷰 미팅에서 발견된 모든 이슈, 문제점, 미해결점 등을 문서화한다.

- 검토자(Reviewer)

1) 해당 분야의 기술적 또는 비즈니스적 배경을 갖춘 사람이다.

2) 리뷰 대상에서 인시던트를 발견하고 기술한다. 

- 중재자(Moderator)

1) 문서의 리뷰를 리드한다.

2) 리뷰를 계획하고 미팅을 진행한다.

3) 리뷰어(검토자)의 다양한 관점과 의견을 조율한다.

4) 후속조치 처리 여부를 추적하고 관리한다. 

 

3.2.3. 리뷰의 유형(Type of review)

하나의 문서는 여러 형태로 리뷰 될 수 있는데, 일반적인 리뷰 유형의 주요 특징과 목적은 아래와 같다.

- 비공식적 리뷰(Informal review)

1) 공식적인 절차가 없음

2) 선택적으로 문서화될 수 있음

3) 페어(Pair) 프로그래밍에 의한 리뷰이거나 기술 선임자가 설계와 코드를 리뷰하는 것일 수 있음

4) 리뷰하는 사람에 따라 성과가 좌우됨

5) 주요 목적 : 저렴한 방법으로 일정 수준의 성과 달성

- 기술적 리뷰(Technical review)
주요 목적 : 기술적 문제 해결에 초점

1) 동료와 기술 전문가가 참여하는, 결함 발견을 위한 문서화되고 정의된 프로세스가 존재함

2) 관리자 개입이 없는 동료 검토 형태로 수행할 수 있음

3) 이상적으로는 저자가 아닌 중재자(Moderator)가 미팅을 주도함.

4) 미팅전 사전 준비 단계 필요

5) (선택적) 체크리스트, 리뷰 리포트, 발견한 인시던트 리스트, 관리자 참여 활용

6) 실무에서는 공식적 또는 비공식적일 수 있음.

7) 공식적인 경우 문서화 필수

8) (성공적으로 진행되는 경우) 검토자에 관계없이 일관되고 정량적인 효과 도출 가능

9) 인스펙션과 주요 목적이 다르며 설계 및 소스코드를 리뷰 하는데 적합하다.

10) 하위레벨 테스트에 집중하지는 않는다. (문제 풀이 시 참고)

- 워크쓰루(Walkthrough)

1) 저자(작성자)에 의한 진행 및 제어

2) 성격 : 시나리오 사용, 예행 연습(Dry runs), 동료 그룹 검토

3) 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있는(Open-ended) 세션

4) (선택적) 미팅 전 준비 과정 거침. 예를 들어, 미팅 전에 검토자를 지정하고, 리뷰 리포트를 준비하고, 발견한 인시던트 리스트를 준비하고, 기록자를 지정함

5) 실무에서는 비공식적 또는 공식적일 수 있음

6) 사업적 리스크가 높은 영역에서는 요구사항과 관련된 사용자 및 고객들과 의아소통을 해야 하므로 이들에게 친숙하고 시간 및 인원수 등에 제한이 없는 워크쓰루가 효과적이다. (문제 풀이 시 참고) 

7) 주요 목적 : 학습, 시스템에 대한 이해 향상, 결함 발견

- 인스펙션(Inspection)

1) 저자가 아닌 훈련된 중재자(Moderator)에 의한 진행 및 제어

2) 주로 동료 검사

3) 역할이 정의되어 있음

4) 메트릭을 수집하고 활용함

5) 체크리스트와 규칙을 기반으로 시작과 종료 조건이 있는 정식 프로세스 존재

6) 미팅 전 준비 과정 필요

7) 인스펙션 리포트와 발견사항(인시던트) 리스트 산출

8) 정식적인 후속 처리 확인(Follow-up) 프로세스 존재

9) (선택적) 리뷰 프로세스 개선 활동 수행

10) 주요 목적 : 결함 발견

- 리뷰는 "리스크 기반 테스트 전략"과 다른 시각에서 연계할 수 있다. 사업적 리스크가 높은 영역에서는 요구사항과 관련된 사용자 및 고객과 의사 소통해야 하므로, 이들에게 친숙하고 시간 및 인원수 등에 제한이 없는 워크쓰루가 효과적이다. 

- 비공식적 리뷰는 기술적 리뷰 이전에 수행될 수 있고, 인스펙션은 고객과의 워크쓰루(Workthrough) 이전에 요구사항 명세를 가지고 수행될 수 있다. 

 

3.2.4. 리뷰의 성공요소

- 리뷰가 성공적이기 위해서는 기본적으로 수행하고자 하는 리뷰 대상 및 목적에 부합하는 리뷰 형식을 선택하고, 리뷰 참여자들의 역할과 책임을 명확하게 한 후, 리뷰 프로세스에 준하여 리뷰를 진행해야 한다. 

- 소프트웨어 개발 산출물과 검토자의 수준과 타입을 고려하여 리뷰 기법을 적절히 적용해야 함. 

- 효과적이고 효율적인 결함 발견을 위해 필요 시 체크리스트 및 역할 분담 활용(이때 체크리스트는 요구사항 정의서, 분석서 및 설계서, 코드 등의 개발 산출물 각각에 대해 작성하고 유지 관리하는 것이 권장됨)

- 리뷰 기법에 대한 교육 훈련 제공. 특히, 인스펙션과 같이 보다 공식적인 기법에 대해서는 교육 훈련 제공이 필수적임(이 경우 중재자(Moderator)는 별도의 교육을 반드시 이수해야 함) 

 

3.3. 도구에 의한 정적 분석(Static analysis by tools)

- 정적 분석의 목적은 소프트웨어의 소스코드와 모델에서 결함을 발견하는 것이다.

- 정적 분석의 특징은 아래와 같다 
1) 정적 분석은 동적 테스팅으로 찾기 힘든 결함을 발견함
2) 리뷰와 마찬가지로 정적 분석은 장애(Failures) 보다는 결함(Defects)을 발견함

3) 도구의 도움을 받아 수행함

4) 정적 분석 도구는 프로그램 코드를 분석(제어 흐름이나 데이터 흐름 분석 등)하는 것은 물론, HTML이나 XML과 같이 생성된 결과물도 분석함

- 정적 분석의 가치
1) 테스트 실행 전에 조기 결함 발견

2) 높은 복잡도(Complexity) 측정치와 같은 메트릭을 계산하여 코드와 설계의 의심스러운 부분에 대한 조기 경보

3) 동적 테스팅으로는 발견하기 어려운 결함 발견

4) 소프트웨어 모델상의 의존도와 불일치성(Dependencies and inconsistencies) 발견

5) 코드와 설계의 유지보수성(Maintainability) 향상

6) 결함 예방 가능

- 정적 분석 도구를 통해 발견되는 전형적인 결함은 아래와 같다

1) 정의되지 않은 값으로 변수 참조

2) 모듈과 컴포넌트 간에 일관되지 않은 인터페이스

3) 사용되지 않는 변수

4) 사용되지 않는 코드(Dead code)

5) 코딩 표준 위반

6) 보안 취약성

7) 코드와 소프트웨어 모델의 구문 규칙(Syntax) 위반

- 컴포넌트 테스팅과 통합 테스팅 동안에 주로 개발자에 의해 사용되고, 소프트웨어 모델링하는 동안에는 설계자에 의해 사용된다.