ISTQB/ SW 테스팅 ) 3장 - 정적 기법

3.1.1 리뷰의 이점과 목적

▶ 정적기법
 - SW를 실행하지 않고 테스팅 하는 기법
 - 동적 테스팅과 달리 장애보다는 장애의 원인(결함)을 발견
▶ 리뷰
 - 코드를 포함하여 SW개발 및 테스트 산출물을 검토하고 테스팅 하는 방법.
 - 동적 테스팅 전에 수행 --> 초기 결함의 수정은 비용 절감
 - 대상
   >> 요구사항 명세, 설계 명세, 코드, 테스트 계획, 테스트 명세, 테스트 케이스, 테스트 스크립트, 사용자 가이드, 웹페이지 등 모든 SW개발 및 테스트 산출물.
- 리뷰의 이점
   >> 조기 결함 발견 및 수정
   >> 개발 생산성 향상
   >> 개발 기간 단축
   >> 테스팅 비용 감소 및 시간 단축
   >> 개발 생명 주기 전체에 걸친 비용 감소
   >> 결함 감소(품질 향상)
   >> 커뮤니케이션 향상
 - 리뷰를 통해 발견하기 쉬운 결함
   >> 표준 위반, 요구사항 결함, 개발 설계 결함, 불충분한 유지보수성, 부정확한 인터페이스 명세.
 

3.1.2 리뷰와 테스팅

▶ 최근 테스팅
 - 결함 예방 활동 강조
 - 조기 테스트 설계 -- > 초기에 결함을 줄임
   >> 시스템 명세(요구사항 문서, 설계 기준서)에 대한 테스트 케이스 생성
   >> 요구사항 분석서를 통한 테스트 케이스 -- > 시스템 또는 인수 테스팅에 사용
 - 프로젝트 초기 모든 테스트 케이스 생성은 부적절
 - BUT, 리스크가 높거나 중요한 기능에 한해 테스트 케이스를 도출 하면서 문서를 테스트 -- > 조기 발현 중요.
 

3.2 리뷰 프로세스

▶ 리뷰 목적
 - 결함 발견, 이해도 증진, 합의에 의한 결정과 이를 위한 토론
 - 체계적인 리뷰를 통해 고품질 SW 개발과 비용 절감은 물론 개발 기간 단축의 효과
 - 페이건 스펙션
   >> 초기에 많은 인력, 코딩 단계 부터 인력이 줄게 됨, 품질 비용이 감소하고 개발 기간 단축.
 

3.2.1 공식적 리뷰의 단계

▶ 정적 테스트 활동의 중요성이 높아지고 있음
▶ 정적 테스트 프로세스
 - 정적 테스트 준비 단계
 - 리뷰 / 분석 단계
 - 후속 처리 확인 단계
   >> 비공식적인 리뷰도 일반적인 프로세스를 준수하는 것이 좋음
▶ 공식적 리뷰의 절차
 - 계획 활동 -- > 시작 -- > 개별 준비 -- > 리뷰 미팅 -- > 재작업 -- > 후속 처리 확인

단계	실행 주체	세부 활동
1. 계획	Manager (관리자)	- 리뷰 기준 정의 - 인원 선택 - 역할 분담 - 매우 공식적인 리뷰에는 시작/ 종료 기준 정의 - 리뷰 범위 선정 - 시작 기준 준수 체크(매우 공식적인 리뷰일 경우)
2. 시작(Kick -off)	Moderator(중재자) Reviewer(검토자) Author(저자)	- 문서 배포 - 목적/ 절차/ 문서에 대한 설명
3. 개별 준비	Reviewer(검토자)	- 문서를 리뷰하며 리뷰 미팅을 준비 - 잠재 결함 체크, 회의에서 제시할 질문과 의견(Comment)준비
4. 리뷰 미팅 (시험 / 평가 /결과 기록)	Moderator(중재자) Reviewer(검토자) Author(저자) Scribe(기록자)	- 검사/ 평가/ 결과 기록 - 토론하고 기록함 - 결과를 문서화하거나 상세 회의록 작성(매우 공식적인 리뷰인 경우) - 결함 기록 -> 결함 수정 여부 결정( 결함의 해결 방안은 토론하지 않는 것이 원칙)
5. 재 작업(Rework)	Author(저자)	- 결함 수정 - 결함 상태 업데이트
6. 후속 조치(Follow up)	Moderator(중재자)	- 결함 수정 여부 확인 - 메트릭 수집 - 리뷰 완료 기준 체크(매우 공식적인 리뷰인 경우)

 

3.2.2 역할과 책임

▶ 역할과 책임
 - 관리자(Manager)
   >>리뷰 진행 결정, 프로젝트 일정에 리뷰 시간 할당, 리뷰의 목적 달성 여부 확인하고 승인
 - 중재자(Moderator)
   >> 리뷰 회의 리드(리뷰 계획, 미팅 진행, 미팅 후속 조치 추적 관리 등)
   >> 다양한 관점을 중재하는 자로 리뷰의 성패를 좌우
 - 저자(Author)
   >> 리뷰 대상 문서(산출물)의 작성자 또는 책임자
 - 검토자(Reviewer) - 테스트 전문가 참여
   >> 리뷰 대상 제품에서 인시턴트를 발견하고 기술할 사람(검사자 또는 인스펙터) - 기술적 또는 비즈니스 배경을 갖춘자
   >> 리뷰어는 다양한 관점과 역할을 대표하도록 선택되어야 함
 - 기록자(Scribe or recorder)
   >> 리뷰 미팅에서 발견된 모든 이슈, 문제점, 미해결점 등을 기록하고 문서화함
▶ 체크리스트 활용
 - 효과적 /효율적인 리뷰를 위해 사용자, 유지보수 담당자, 테스터, 시스템 운영자 등 다양한 관점의 체크리스트 또는 문서 유형별 체크리스트 이용 및 개발 권고
▶ 테스트 케이스 -- > 시간과 노력 많이 필요
 - 변경된 요구사항과 설계 반영을 위해 지속적으로 업데이트 필요  (초반에 다 만들지 않아. 계속해서 업데이트)
 

3.2.3 리뷰의 유형

항목	비공식 리뷰(Informal Review)	기술적 리뷰(Technical Review)
공식 절차 여부	No	동료와 기술 전문가가 참여, 문서화되고 정의된 결함 발견 절차 정의
주요 목적	저비용으로 문서/ 코드 검토	기술적 문서 해결. 토론, 의사 결정, 대안 평가, 결함 발견, 명세서 또는 표준과의 적합성 검토
참여자	(선택적) 동료 or 기술 선임자가 설계와 코드 리뷰	동료 또는 기술 전문가. 중재자(Moderator)
문서화 여부	(선택적) 문서화	문서화
효과	리뷰어에 따라 효과가 다름	일관되고 정량적인 효과(성공적인 경우)
사전 준비	-	사전 준비 필요
미팅 주도 및 활용 도구(문서)	-	Moderator(중재자)가 주도. (선택적) 체크리스트, 리뷰 리포트, 인시던트 리스트. 경영층 참여 유도.

▶ 리뷰에 리스크 분석을 연계한 사례

 
▶ 워크쓰루(Walkthrough) -- > 이해 향상과 결함 발견
 - 저자(Author: 산출물 작성자)에 의한 진행 및 제어
 - 성격 : 시나리오 사용, 예행 연습(Dry runs), 동료 그룹 검토
 - 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있는(Open - ended) 세션
 - (선택적) 미팅 전 준비 과정 거침 -- > 역할 지정(검토자, 기록자 등), 리뷰 리포트 준비, 인시던트(조사가 요구되는 이벤트) 목록 준비
 - 실무에서는 비공식적 또는 공식적일 수 있음.
 - 주요 목적 : 학습, 시스템에 대한 이해 향상, 결함 발
▶ 인스펙션(Inspection) --> 결함 발견
 - 저자가 아닌 중재자가 주도적으로 진행 및 제어
 - 주로 동료 검사
 - 역할이 정의되어 있음
 - 메트릭(측정 척도와 방법)을 수집하고 활용함
 - 체크리스트와 규칙을 기반으로 시작과 종료 조건이 있는 정식 프로세스 존재
 - 미팅 전 준비 과정 필요
 - 인스펙션 리포트와 발견 사항(인시턴트(조사가 요구되는 이벤트)) 리스트 산출
 - 정식적인 후속 처리 확인(Follow -up) 프로세스 존재
 - (선택적) 리뷰 프로세스 개선 활동 수행
▶ 인스펙션 대상
 - 모든 개발 산출물과 테스트 산출물
 - 리스크 분석 결과를 활용하여 장애 발생 가능성이 높고 발생한 장애로 인한 영향이 심각할 수 있는 부분을 중심으로 진행
   >> 비즈니스와 연관성이 높거나, 복잡도, 변경율, 결함률이 높은 부분이 이에 해당.
 - 리스크 기반 테스트 전략 -- > 리뷰 강도 조절
▶ 워크쓰루 vs. 인스펙션 
 - 사업적 리스크가 높은 영역 - 워크쓰루
 - 기술적 리스크가 높은 영역 - 인스펙션이나 기술적 리뷰
 

3.2.4 리뷰의 성공 요소

심리적 관점	- 사람 관련 이슈와 심리적인 측면을 고려해야 함.    >> 코드 또는 문서의 저자가 리뷰를 통해 긍정적인 경험을 해야 지속적인 효과 기대 가능. - 리뷰는 신뢰가 바탕이 돼야 함.    >> 리뷰 결과를 리뷰 참여자(리뷰어, 저자 등) 를 평가하는 용도로 사용하지 않음.
조직 및 체계적 관점	- 명확한 리뷰 목적 정의 - 리뷰 목적에 적합한 인력 선택 - 지속적인 학습 및 프로세션 개선 - 경영층의 적극적인 지원(리뷰에 충분한 리소스 할당) - 결함 발견은 언제나 환영하는 분위기이고 결함을 객관적으로 표현해야 함.
기술적 관점	- 적절한 리뷰 기법 적용.    >> SW 산출물과 리뷰어(검토자) 수준과 성향(타입) 고려. - 효과적/ 효율적인 결함 발견을 위해 체크리스트 활용(적절한 역할 분담 필요) - 리뷰 기법에 대한 교육(훈련) 필요.(특히, 인스펙션의 경우) - 테스터의 리뷰 참여    >> 프로젝트 초기에 참여해 제품에 대한 이해를 높임.

 

3.3 도구에 의한 정적 분석

- 정적 분석 특징
   >> 정적 분석은 동적 테스팅으로 찾기 힘든 결함을 발견
   >> 리뷰와 마찬가지로 정적분석은 장애보다는 결함을 발견함 > 코드를 돌리기 전에 문제점을 찾아내자!!
   >> 도구의 도움을 받아 수행
   >> 정적 분석 도구는 프로그램 코드를 분석하는 것은 물론, HTML이나 XML과 같이 생성된 결과물도 분석
 - 정적 분석의 가치
   >> 테스트 실행 전 조기 결함 발견
   >> 의심스러운 코드와 설계에 대한 조기 경보(프로그램 복잡도- 메트릭)
   >> 동적 테스팅으로 발견하기 어려운 결함 발견
   >> SW 모델상의 의존도와 불일치성 발견
   >> 코드와 설계의 유지보수성 향상
   >> 결함 예방 가능
 - 정적 분석을 통해 발견될 수 있는 결함
   >> 정의되지 않은 값으로 변수 참조
   >> 모듈과 컴포넌트 간의 일관되지 않은 인터페이스
   >> 사용되지 않는 변수
   >> 사용되지 않는 코드
   >> 코딩 표준 위반
   >> 보안 취약성
   >> 코드와 소프트웨어 모델의 구문 규칙 위반
 - 정적 분석 도구
   >> 기 정의된 규칙이나 코딩표준을 준수하는지 확인하는 용도로 컴포넌트 테스팅과 통합 테스팅 동안에 주로 개발자에 의해 사용.
   >> SW 모델링하는 동안 설계자에 의해 사용.