실라버스 제 3 장. 정적 테스팅

3.1 정적 테스팅 기초

 

* 정적 테스팅
　- 작업 산출물을 수동으로 검사(예 : 리뷰)
　- 코드나 다른 작업 산출물을 도구를 기반으로 평가(예 : 정적 분석)
　☞ 모두 테스트 중인 코드 or 작업 산출물을 실제로 실행하지 않고 평가

 

3.1.1 정적 테스팅으로 검토할 수 있는 작업 산출물 (K1)

 

* 정적 테스팅(리뷰 or 정적 분석)으로 검사할 수 있는 작업 산출물
　① 명세(비즈니스 요구사항, 기능 요구사항, 보안 요구사항)
　② 에픽(epic), 사용자 스토리, 인수 기준
　③ 아키텍처 및 설계 명세
　④ 코드
　⑤ 테스트웨어(테스트 계획, TC, 테스트 프로시저, 자동화 스크립트)
　⑥ 사용자 가이드
　⑦ 웹 페이지
　⑧ 계약, 프로젝트 계획, 일정, 예산 기획
　⑨ 형상(configuration) 및 인프라(infrastructure) 셋업
　⑩ 모델 기반 테스팅에 사용되는 모델(액티비티 다이어그램)

 

* 정적 분석
　- 적절한 정적 분석 도구가 존재하는 공식 구조를 사용하는 작업 산출물(코드 or 모델)에 효율적으로 적용할 수 있음
　- 자연어로 작성된 작업 산출물(요구사항)을 평가하는 도구로 적용할 수 있음(예 : 맞춤법, 문법 및 가독성 검사)

 

3.1.2 정적 테스팅의 효과 (K2)

 

* 정적 테스팅의 효과
　① 동적 테스트 실행 전에 보다 효율적으로 결함을 발견하고 수정
　② 동적 테스팅으로 발견이 쉽지 않은 결함 식별
　③ 요구사항 불일치, 애매 모호함, 모순, 누락, 부정확, 중복 등을 식별해서 설계 or 코딩의 결함 예방 
　④ 개발 생산성 향상 (예 : 설계 개선, 향상된 코드 유지보수성)
　⑤ 개발 비용 및 기간 단축
　⑥ 테스팅 비용 및 기간 단축
　⑦ 수명주기 후반 or 출시 후 운영 과정에서 발견되는 장애 감소로 SW 수명주기 전반에 걸친 총 품질 비용 감소
　⑧ 리뷰에 참여하는 침원 간의 의사소통 개선

 

3.1.3 정적 테스팅과 동적 테스팅의 차이 (K2)

 

* 정적 테스팅, 동적 테스팅

　- 공통 목적 (1.1.1절) : 작업 산출물의 품질을 평가, 가능한 빨리 결함을 식별하는 것

　- 발견하는 유형의 결함이 서로 달라 상호 보완적임

 

* 정적 테스팅
　- 작업 산출물에서 직접 결함을 발견 
　- 훨씬 적은 노력으로 결함을 발견
　　(결함이 존재하는 경로가 드물게 실행 or
　　접근 어려워 이런 경로에 도달하는 동적 테스트를 구축하고 실행하는 것이 쉽지 않음)
　- 작업 산출물의 일관성, 내부 품질을 향상하기 위해 사용
　- 대부분의 유지보수성 결함은 정적 테스팅으로만 발견할 수 있음
　(예 : 잘못된 모듈화, 낮은 컴포넌트 재사용성, 새로운 결함을 발생시키지 않고는 분석하거나 수정하기 어려운 코드 등)

 

* 동적 테스팅
　- 외부에 보이는 동작에 초점을 맞춤

 

* 정적 테스팅의 일반적인 결함 유형
　(동적 테스팅과 비교해서 발견하기 쉽고 비용도 적게 들어감. 동적 테스팅에서도 발견할 수 있음)
　① 요구사항 결함 (예 : 불일치, 모호함, 모순, 누락, 부정확, 중복 등)
　② 설계 결함 (예 : 비효율적인 알고리즘 or DB 구조, 높은 결합도, 낮은 응집도 등)
　③ 코딩 결함 (예 : 정의되지 않은 값이 있는 변수, 선언했으나 사용하지 않는 변수, 도달할 수 없는 코드, 중복 코드 등)
　④ 표준과의 차이 (예 : 코딩 표준 미준수 등)
　⑤ 잘못된 인터페이스 명세 (예 : 호출하는 시스템과 호출되는 시스템이 서로 다른 측정 단위 사용)
　⑥ 보안 취약점 (예 : 버퍼 오버플로우에 대한 취약성)
　⑦ 테스트 베이스 추적성 or 불충분한 커버리지 or 부정확성 (예 : 특정 인수 조건에 대한 테스트 누락)

 

3.2 리뷰 프로세스

 

* 리뷰 유형
　- 공식 리뷰
　　· 팀 참여, 문서화된 리뷰 결과, 문서화된 리뷰 진행 절차 등등
　- 비공식 리뷰
　　· 정의된 프로세스를 따르지 않고,
　　· 리뷰 결과를 공식적으로 문서화하여 제공하지 않음   

 

3.2.1 작업 산출물 리뷰 프로세스

 

1. 계획
　① 리뷰 목적, 리뷰할 문서가 전체인지 특정 부분인지, 평가할 품질 특성 등을 포함하는 범위의 정의
　② 노력과 기간 추정
　③ 리뷰 유형에 따라 결정되는 역할, 활동, 체크리스트와 같은 리뷰 특성의 식별
　④ 리뷰에 참석할 인원을 선정하고 역할 할당
　⑤ 인스펙션과 같은 보다 공식적인 리뷰의 경우에는 시작 및 종료 조건 정의
　⑥ (공식적인 리뷰 유형의 경우) 시작 조건이 충족되는지 확인

 

2. 리뷰 착수 = 시작 미팅

　① (물리적 or 전자적 수단에 의한) 작업 산출물과 이슈 기록(issue log) 양식, 체크리스트,
　　관련된 작업 산출물과 같은 기타 자료 배포
　② 참가자에게 범위, 목적, 프로세스, 역할 작업 산출물을 설명
　③ 참가자가 리뷰에 대해 가질 수 있는 여러 질문에 답변

 

3. 개별 리뷰(or 개별 준비)
　① 작업 산출물 전체 or 부분 리뷰
　② 잠재 결함, 권고사항, 질문 기록

 

4. 이슈 논의 및 분석 = 리뷰 미팅
　① 식별한 잠재 결함 전달 (예 : 리뷰 회의 중 전달)
　② 잠재 결함 분석 및 담당자 및 상태 할당
　③ 품질 특성 평가 및 문서화
　④ 종료 조건을 기준으로 리뷰 결과를 평가하여 리뷰 결과 결정
　　(예 : 거부(reject), 주요 수정 필요, 약간의 수정 후 수락 등)

 

5. 수정 및 보고
　① 작업 산출물에 대한 수정을 요하는 잠재 결함에 대한 결함 보고서 작성
　② 리뷰한 작업 산출물에서 발견한 결함 수정 (일반적으로 저자가 수정)
　③ 결함 정보를 적절한 사람이나 팀과 공유
　　(리뷰한 작업 산출물과 연관된 다른 작업 산출물이 있는 경우)
　④ 필요한 경우 주석 작성자의 동의를 포함해 (공식적인 리뷰 유형인 경우) 업데이트된 결함 상태 기록 
　⑤ 메트릭 수집 (공식적인 리뷰 유형인 경우)
　⑥ 종료 조건의 충족여부 확인 (공식적인 리뷰 유형인 경우)
　⑦ 종료 조건이 충족되면 해당 작업 산출물 인수

 

3.2.2 공식 리뷰에서의 역할과 책임 (K1)

 

1. 저자 (Author)

　① 리뷰 대상 작업 산출물 작성
　② 리뷰 대상 작업 산출물 결함 수정 (필요한 경우)

 

2. 관리자 (Management)

　① 리뷰 계획 담당
　② 리뷰 실행 결정
　③ 인력, 예산, 시간 할당
　④ 진행 비용 대비 효과 모니터링
　⑤ 결과가 만족스럽지 않은 경우 제어 결정 실행

 

3. 촉진자 (Facilitator, 종종 중재자(moderator)로 부름)

　① 리뷰 회의 진행 시 효과적 회의 진행 보장
　② 필요한 경우 다양한 관점들에 대한 중재
　③ 많은 경우 리뷰의 성공 여부에 결정적인 역할을 하는 사람

 

4. 리뷰 리더 (Review leader)
　① 전반적으로 리뷰에 대한 책임을 지는 사람
　② 참여자를 결정하고 언제 어디서 진행할지 결정

 

5. 검토자 (Reviewers)

　① 해당 주제에 대한 전문가, 프로젝트 참여 인원, 작업 산출물에 관심이 있는 이해관계자 or
　　특정 기술 or 비즈니스 배경을 가진 사람 등 
　② 리뷰 대상 작업 산출물의 잠재적 결함 식별
　③ 다양한 관점을 대표할 수 있음
　　(예 : 테스터, 개발자, 사용자, 운영자, 비즈니스 분석가, 사용성 전문가 등)

 

6. 서기(Scribe, or 기록자( Recorder))

　① 개별 리뷰 활동에서 발견한 잠재 결함 수집
　② 리뷰 회의가 진행되는 경우 새로운 잠재 결함, 쟁점, 결정 사항 기록

 

- 리뷰 유형에 따라 1사람이 2개 이상의 역할을 수행할 수 있음
- 각 역할과 관련된 활동 역시 리뷰 유형에 따라 달라질 수 있음

- 리뷰 프로세스를 지원하는 도구
(특히, 결함, 쟁점 및 의사 결정의 기록을 지원하는 도구로 인해) 서기가 필요하지 않은 경우가 많음

 

3.2.3 리뷰 유형 (Review Types) (K2)

 

1. 비공식 리뷰 (Informal review)
(예 : 버디 체크 (buddy check), 페어링 (pairing), 짝 리뷰 (pair review))

　① 주요 목적 : 잠재적 결함 발견
　② 기타 목적 : 새로운 아이디어나 해결책 도출, 소소한 문제의 빠른 해결
　③ 공식 (문서화된) 프로세스를 기반으로 하지 않음
　④ 리뷰 회의를 진행하지 않을 수 있음
　⑤ 저자의 동료 (버디 체크) or 다른 사람이 수행할 수 있음
　⑥ 결과는 문서로 기록할 수 있음
　⑦ 검토자에 따라 성과가 달라짐
　⑧ 체크리스트 사용 여부는 상황에 맞게 판단
　⑨ 애자일 개발에서 매우 일반적으로 사용됨

 

2. 워크쓰루 (Walkthrough)

　① 주요 목적 : 결함 발견 (비즈니스, 운용과 관련), SW 제품 개선, 다른 구현 방법 고려, 표준이나 규정 준수 평가
　② 기타 목적 : 다양한 기술이나 스타일에 대한 아이디어 교환, 참여자 교육, 합의 도출
　③ 리뷰 회의 전 개별 준비는 필요에 따라 수행
　④ 리뷰 회의는 일반적으로 작업 산출물의 저자가 주도 (중재자 X)
　⑤ 서기 참여 필수 
　⑥ 체크리스트 사용 여부는 상황에 맞게 판단 
　⑦ 시나리오, 드라이 런(dry run), 시뮬레이션의 형태로 수행할 수 있음 
　⑧ 잠재 결함 로그와 리뷰 보고서 작성 
　⑨ 실무에서는 비공식적인 형식 ~ 매우 공식적인 형식까지 다양할 수 있음

 

3. 기술 리뷰 (Technical review)

　① 주요 목적 : 합의 도출, 잠재적 결함 발견 (기술, 구현과 관련)
　② 기타 목적 : 작업 산출물의 품질 평가 및 자신감 획득, 새로운 아이디어 도출,
　　저자가 미래의 작업 산출물을 개선하도록 지원하고 동기를 부여, 다른 구현 방법 고려
　③ 검토자 = 저자의 기술 동료 + 동일 분야 or 다른 분야의 기술 전문가여야 함
　④ 리뷰 회의 전 개별 준비 필요
　⑤ 리뷰 회의는 선택 사항, 이상적으로는 훈련된 촉진자(일반적으로 저자가 아닌)가 주도
　⑥ 서기는 반드시 있어야 하며, 이상적으로 저자가 아닌 사람이 수행
　⑦ 체크리스트 사용 여부는 상황에 맞게 판단 
　⑧ 잠재 결함 로그와 리뷰 보고서 작성

 

4. 인스펙션 (Inspection)
　① 주요 목적 : 잠재적 결함 발견, 작업 산출물의 품질 평가 및 자신감 획득,
　　저자 학습과 근본 원인 분석을 통한 유사 결함의 발생 예방
　② 기타 목적 : 저자가 앞으로의 작업 산출물과 SW 개발 프로세스를 개선하고 합의를 이끌어 내도록 동기를 부여
　③ 규칙 및 체크리스트를 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행
　④ 명확하게 정의된 역할 참여,
　　낭독자(리뷰 회의 중 작업 산출물을 종종 자신의 말로 의역하고 소리 내어 읽는 사람)의 참여 가능
　⑤ 리뷰 회의 전 개별 준비 필요
　⑥ 검토자 : 저자의 동료 or 작업 산출물과 연관된 분야의 전문가
　⑦ 명시된 시작 및 종료 조건을 사용
　⑧ 서기 참여 필수
　⑨ 리뷰 회의는 훈련받은 촉진자(저자가 아닌 사람)가 주도
　⑩ 저자는 리뷰 리더, 글을 읽는 사람 or 서기가 될 수 없음
　⑪ 잠재적인 결함 로그 및 리뷰 보고서 작성
　⑫ 인스펙션 프로세스 포함 전체 SW 개발 프로세스를 개선하기 위해 메트릭을 수집하고 사용

 

3.2.4 리뷰 기법 적용 (Applying Review Techniques) (K3)

 

1. 애드혹 (Ad hoc)

　- 검토자에게 리뷰 수행 방법에 대한 안내가 거의 or 전혀 제공되지 않음
　- 검토자는 대부분의 경우 작업 산출물을 순차적으로 읽으면서 이슈를 식별하고 기록함
　- 특별한 준비 없이 일반적으로 사용되는 기법
　- 검토자의 능력에 크게 의존, 여러 검토자가 동일한 문제를 보고할 수 있음

 

2. 체크리스트 기반 (Checklist based)

　- 체계적인 기법 -> 체계적인 커버리지를 갖는다.
　- 검토자는 리뷰 시작 시점에 배포된(예 : 촉진자에 의해) 체크리스트를 기반으로 이슈를 식별함
　- 리뷰 대상 작업 산출물 유형별로 작성해야 함
　- 이전 리뷰에서 누락된 이슈 유형을 다루기 위해 주기적으로 개선할 필요가 있음 
　- 검토자는 체크리스트를 단순히 실행 + 체크리스트로 식별할 수 없는 결함도 찾기 위해 특별히 주의르 기울여야만 함

3. 시나리오 및 드라이 런 (Scenarios and dry runs)

　- 시나리도 기반 리뷰
　　· 검토자는 작업 산출물을 어떻게 검토할지에 대한 구조화된 지침을 제공받음
　　· (작업 산출물이 유스케이스와 같은 적절한 형식으로 문서화된 경우)
　　작업 산출물의 예상되는 용도를 기반으로 작업 산출물에 대해 "드라이런"을 수행할 수 있도록 검토자를 지원함
　　☞ 검토자에게 특정 결함 유형을 식별하는 방법에 대한 좀 더 나은 지침을 제공
　- 다른 결함 유형(예 : 누락된 기능)을 발견하기 위해 검토자는 기록된 시나리오에만 너무 얽매이지 않아야 함

 

4. 관점 기반 (Perspective-based)

　- 검토자가 개별 리뷰 중 다양한 이해관계자(최종 사용자, 영업 설계자, 테스터, 운영자 등)의 관점을 사용하게 됨
　- 서로 다른 이해관계자 관점을 사용하면, 검토자 간에 중복되는 이슈가 줄어들고 개별리뷰가 좀 더 깊이 있게 진행 됨

　- 검토자가 리뷰 대상 작업 산출물로부터 이해관계자의 관점을 기반으로 하는 산출물을 작성해야 함

　(예 : 테스터가 필요한 모든 정보가 존재하는지 확인하기 위해
　요구사항 명세에 대한 관점 기반 읽기를 수행하면서 인수 테스트 초안을 작성을 시도할 수 있음)

 

5. 역할 기반 (Role-based)
　- 검토자가 작업 산출물을 개별 이해관계자 역할의 관점에서 평가하는 기법

　- 일반적인 역할 : 특정 최종 사용자 유형(경험 많은, 적은 / 노인, 아동 등),
　조직 내 특정 역할(사용자 / 시스템 관리자, 성능 테스터 등)

 

3.2.5 리뷰의 성공 요소 (K2)

 

1. 조직 차원의 성공 요인
　① 각 리뷰는 명확한 목적이 있어야 함. 목적은 리뷰 계획 시 정의, 측정 가능한 종료 조건으로 사용됨
　② 목적을 달성하기에 적합하고, SW 작업 산출물 및 참여자 유형 수준에 맞는 리뷰 유형을 적용해야 함
　③ 체크리스트 기반 및 역할 기반 리뷰와 같이 사용하는 모든 리뷰 기법은 
　　리뷰 대상 작업 산출물의 결함을 효과적으로 식별하기에 적합해야 함
　④ 규모가 큰 문서는 작은 단위로 작성하고 리뷰를 수행해
　　저자에게 결함에 대한 피드백을 조기에, 빈번하게 제공함으로써 품질 관리를 수행함
　⑤ 참여작는 충분한 준비 시간을 갖음
　⑥ 충분한 여유를 가지고 리뷰 일정을 수립함
　⑦ 경영진은 리뷰 프로세스를 지원함 (예 : 프로젝트 일정에 리뷰 활동을 위한 충분한 시간을 배정)
　⑧ 리뷰는 기업의 품질 및 테스트 정책에 통합됨

 

2. 사람과 관련된 성공 요인

　① 리뷰 목적 달성을 위해 적절한 사람들이 참여함
　　(예 : 문서를 기반으로 작업을 시작해야 하는 서로 다른 기술 세트 or 관점을 가진 사람들)
　② 테스터는 리뷰에 기여하는 중요한 검토자로 간주됨.
　　작업 산출물의 학습을 통해 좀 더 효과적인 테스트를 준비, 조기에 테스트 준비를 할 수 있게 됨
　③ 참여자는 세부사항에 충분한 시간과 주의를 기울여야 함
　④ 작은 단위로 리뷰를 진행해 개별 리뷰나 리뷰 회의(개최된다면) 중에 검토자가 집중력을 잃지 않도록 해야 함
　⑤ 식별된 결함은 승인, 평가하고, 객관적으로 처리해야 함
　⑥ 리뷰 회의를 잘 관리해 참여자가 리뷰에 참여한 시간이 가치 있다고 인식하게 해야 함
　⑦ 리뷰는 모든 참여자가 서로 신뢰하는 분위기에서 진행해야 함. 리뷰 결과를 가지고 참여자들을 평가해서는 안 됨
　⑧ 참여자는 지루함, 분노 or 다른 참여자에 대한 적대감을 나타낼 수 있는 신체 언어 및 행동을 피해야 함
　⑨ 적절한 교육을 제공함
　　(특히 인스펙션과 같은 공식적인 리뷰 유형에는 더 필요함)
　⑩ 학습 및 프로세스 개선에 대한 조직 문화를 촉진해야 함

 

No	용어	설명	유의어	연관 항목
1	애드혹 리뷰 (ad hoc review)	공식 프로세스 없이 독립된 검토자에 의해 비공식으로 실행되는 리뷰 기법
2	체크리스트 기반 리뷰 (checklist-based review)	질문 목록이나 확인해야 하는 특성을 기반으로 수행하는 리뷰 기법
3	동적 테스팅 (dynamic testing)	컴포넌트나 시스템의 소프트웨어 실행을 기반으로 하는 테스팅
4	공식 리뷰 (formal review)	공식 산출물로 정의된 프로세스를 따르는 리뷰 유형
5	비공식 리뷰 (informal review)	공식(문서화된) 절차 없이 진행되는 리뷰의 유형
6	인스펙션 (inspection)	작업 산출물의 이슈를 식별하기 위한 공식리뷰 유형. 리뷰 프로세스와 소프트웨어 개발 프로 세스를 개선하는데 필요한 정보를 제공
7	관점 기반 읽기 (perspective-based reading)	검토자가 여러 관점에서 작업 산출물을 평가하는 리뷰 기법	관점 기반 리뷰 (perspective-based reviewing)
8	리뷰 (review)	이슈를 발견하고 개선 방법을 제공하기 위해 한 명 이상이 작업 산출물 또는 프로세스를 평가하는 정적 테스팅의 한 유형
9	역할 기반 리뷰 (role-based review)	리뷰어가 다른 이해관계자의 역할 관점에서 작업 산출물을 평가하는 리뷰 기법
10	시나리오 기반 리뷰 (scenario-based review)	특정 시나리오를 지원하는 작업 산출물의 능력을 판단해가면서 진행하는 리뷰 기법
11	정적 분석 (static analysis)	형식이나 구조, 내용, 문서를 기반으로, 컴포넌트나 시스템을 실행하지 않으면서 평가하는 프로세스
12	정적 테스팅 (static testing)	코드를 실행하지 않은 상태로 작업 산출물을 테스팅하는 것
13	기술적 리뷰 (technical review)	기술 자격을 갖춘 인원으로 구성된 팀에 의해 수행되는 공식적인 리뷰의 한 유형.  작업 산출물이 의도한 용도에 적합한지 적합성을 확인하고 명세 및 표준과의 불일치를 식별
14	워크스루 (walkthrough)	작성자가 작업 산출물에 대한 리뷰를 주도하고, 참가자들은 발생 가능 이슈에 대한 질문과 의견을 제시하는 리뷰 유형	구조적 워크스루 (structured walkthrough)	동료 검토 (peer review)

 

Sample A

---

Sample B

---

Sample C