[ISTQB] PART 03. 정적 기법

1. 정적 기법과 테스트 프로세스

1.1 리뷰의 이점과 목적

정적 기법

• 소프트웨어를 실행하지 않고 테스팅하는 기법
• 장애 자체 보다는 장애의 원인(결함)을 발견

 

정적 기법 종류

• 리뷰
• 정적 분석

 

리뷰

• 코드를 포함하여 소프트웨어 개발 및 테스트 산출물을 검토하고 테스팅 하는 방법
• 동적 테스팅에서 발견하기 어려운 개발 산출물의 누락과 같은 결함 발견 용이

 

리뷰의 이점

• 조기 결함 발견 및 수정
• 개발 생산성 향상
• 개발 기간 단축
• 테스팅 비용 감소 및 시간 단축
• 개발 수명주기 전체에 걸친 비용 감소
• 결함 감소(품질 향상)
• 커뮤니케이션 향상

 

리뷰를 통해 발견하기 쉬운 결함의 종류

• 표준 위반
• 요구사항 결함
• 개발 설계 결함
• 불충분한 유지보수성
• 부정확한 인터페이스 명세

 

1.2 리뷰와 테스팅

조기 테스트 설계

• 잘못 설계된 문서와 같이 결함이 있는 문서로 인해 요구사항과 어긋난 방향으로 제품을 개발할 수 있음. 나중에 이를 바로 잡기 위해서는 다량의 재작업이 발생, 상당한 노력과 비용을 부가적으로 투입해야 함
• 조기 테스트 설계를 통해 코딩을 시작하기 전에 요구사항 문서와 설계 기준서 등에서 테스트 케이스를 만들 수 있으며, 이 과정에서 개발 문서상의 결함을 발견할 수 있음
• 코딩 전에 시스템과 관련된 문서를 먼저 테스트하여 시스템에 유입될 수 있는 결함을 미리 예방
• 개발 프로젝트가 잘못된 방향으로 진행될 가능성을 코딩작업 전에 최소화
• 시스템 명세는 자주 변경될 소지가 있으니, 모든 테스트 케이스를 생성하기 보단 리스크가 높거나 중요한 기능에 한해서 테스트 케이스를 도출하면서 문서를 테스트

 

2. 리뷰 프로세스

리뷰의 성과

• 일반적인 개발의 경우, 개발 초기에 요구사항 정의/분석 및 설계 인력이 소수 투입되다가 코딩이 시작되면서 투입 인력 수요가 급증
• 인스펙션을 도입할 경우, 코딩 전까지는 소요 인력이 인스펙션이 없을 때보다 2배정도 필요, 초기 프로젝트 비용이 증가하지만, 성공적인 인스펙션 결과 코딩 단계에서의 재작업과 투입 인력이 줄게 되어 품질 비용이 감소하고 개발 기간을 단축할 수 있음

인스펙션의 효과 - 페이건(Fagan) 인스펙션

 

2.1 공식적 리뷰의 단계

정적 테스트 프로세스

1. 정적 테스트 준비 단계
2. 리뷰/분석 단계
3. 후석 처리 확인 단계

 

공식적 리뷰의 절차(* 비공식적인 리뷰의 경우, 절차 생략 가능하나 기본적인 절차는 따르는 것이 바람직)

1. 계획 활동
   • 참가인원을 선정하고 역할을 할당
   • 공식적인 리뷰에서는 시작 및 종료 기준을 정의
   • 어떤 부분의 문서 및 코드를 리뷰할지 정함
2. 시작(Kick-off)
   • 문서를 배포
   • 리뷰의 목표, 절차 및 문서를 참석자에게 설명
   • 공식적인 리뷰에서는 시작 기준을 점검
3. 개별 준비
   • 미팅 전에 참석자 별로 사전 리뷰 활동을 통해 잠재적인 결함이나 회의에서 제기할 질문과 의견을 기록
4. 리뷰 미팅
   • 개별 준비 내용을 토의하고 이에 대한 결과를 문서로 기록
   • 공식적인 리뷰에서는 상세 회의록 작성
   • 미팅 참석자들은 간단하게 결함을 기록하고, 결함 처리 방안을 제안하고, 결함 여부에 대해서 결정을 내림
5. 재작업(Rework)
   • 발견된 결함을 대상 문서의 저자가 수정
6. 후속 처리 확인(Follow-up)
   • 발견된 결함이 조치(처리)되었는지를 확인
   • 공식적인 리뷰에서는 관련 측정치(메트릭)를 수집하고 리뷰 종료 기준을 점검

 

2.2 역할과 책임

• 관리자
  • 리뷰의 실행여부 결정
  • 프로젝트 일정에 리뷰 시간을 할당
  • 리뷰의 목적 달성 여부를 확인하고 승인
• 중재자
  • 문서의 리뷰를 리드
  • 리뷰를 계획, 미팅을 진행, 미팅 후속 조치의 처리 여부 등을 추적하고 관리
  • 참석자들의 다양한 관점을 중재
  • 리뷰 중재자 교육을 받도록 함
• 저자
  • 리뷰 대상 문서의 작성자 또는 책임자
• 검토자
  • 기술적 또는 비지니스적 배경을 갖춘 사람
  • 필요한 준비 단계를 거친 후, 리뷰 대상에서 인시던트를 발견하고 기술하는 사람
• 기록자
  • 리뷰 미팅에서 발견된 모든 이슈, 문제점, 미해결점 등을 기록하고 문서화

 

2.3 리뷰의 유형

비공식적 리뷰

• 공식적인 절차가 없음
• 페어 프로그래밍에 의한 리뷰이거나 기술 선임자가 설계와 코드를 리뷰하는 것일 수 있음
• 선택적으로 문서화
• 리뷰하는 사람에 따라 성과가 좌우됨
• 주요 목적 : 저렴한 방법으로 일정 수준의 성과 달성

 

기술적 리뷰

• 동료와 기술 전문가가 참여하는, 결함 발견을 위한 문서화되고 정의된 프로세스가 존재함
• 관리자 개입 X 동료 검토 형태
• 미팅전 사전 준비 단계 필요
• 공식적인 경우 문서화 필수
• 주요 목적 : 기술적 문제 해결, 토론, 의사결정, 대안 평가, 결함 발견, 명세서 또는 표준과의 적합성 검토

 

워크쓰루

• 저자에 의한 진행 및 제어
• 성격 : 시나리오 사용, 예행 연습, 동료 그룹 검토
• 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있는 세션
• 주요 목적 : 학습, 시스템에 대한 이해 향상, 결함 발견

 

인스펙션

• 저자가 아닌 훈련된 중재자에 의한 진행 및 제어
• 역할이 정의되어 있음
• 메트릭을 수집하고 활용
• 체크리스트와 규칙을 기반으로 시작과 종료 조건이 있는 정식 프로세스 존재
• 미팅 전 준비 과정 필요
• 인스펙션 리포트와 발견사항(인시던트) 리스트 산출
• 정식적인 후속 처리 확인 프로세스 존재
• 주요 목적 : 결함 발견

 

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

• 사업적 리스크가 높은 영역에서는 요구사항과 관련된 사용자 및 고객과 의사 소통해야 하므로, 친숙하고 시간 및 인원수 등에 제한이 없는 "워크쓰루"가 효과적
• 제품의 기술적인 리스크가 높은 영역에서는 기술적 문제 해결이 중요한 목적인 "기술적 리뷰"나 "인스펙션"이 적절

 

2.4 리뷰의 성공요소

• 각각의 리뷰 활동에는 명확한 목적이 있어야 함
• 리뮤 목적에 적합한 인력이 선택되어야 함
• 결함 발견은 언제나 환경하는 분위기, 결함은 객관적으로 표현되어야 함
• 코드 또는 문서의 저자가 리뷰를 통해 긍정적인 경험을 해야 지속적인 효과를 기대할 수 있음
• 개발 산출물과 검토자의 수준과 타입을 고려해 리뷰 기법을 적절히 적용
• 필요 시 체크리스트 및 역할 분담 활용
• 리뷰 기법에 대한 교육 훈련 제공(특히, 인스펙션과 같이 공식적인 기법에서는 교육 훈련 제공이 필수적)
• 관리자가 적극적으로 리뷰 프로세스를 지원해야 함
• 학습과 프로세스 개선에 대한 강조
• 리뷰 경험과 효과를 내재화하여 지속적으로 적용하는 것이 필요

 

3. 도구에 의한 정적 분석

정적 분석

• 정적 분석은 동적 테스팅으로 찾기 힘든 결함을 발견
• 리뷰와 마찬가지로 정적 분석은 장애보다는 결함을 발견
• 도구의 도움을 받아 수행
• 정적 분석 도구는 프로그램 코드를 분석하는 것은 물론, HTML이나 XML과 같이 생성된 결과물도 분석

 

정적 분석의 가치

• 테스트 실행 전에 조기 결함 발견
• 메트릭을 계산하여 코드와 설계의 의심스로운 부분에 대한 조기 경보
• 동적 테스팅으로는 발견하기 어려운 결함 발견
• 소프트웨어 모델상의 의존도와 불일치성 발견
• 코드와 설계의 유지보수성 향상
• 결함 예방 가능

 

정적 분석 도구를 통해 발견되는 결함

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

* 정적 분석 도구는 기 정의된 규칙이나 코딩 표준을 준수하는지 확인하는 용도로 컴포넌트 테스팅, 통합 테스팅 동안에 주로 개발자에 의해 사용됨, 소프트웨어 모델링하는 동안에는 설계자에 의해 사용됨

 

 

---

📚 참고 문헌 : 개발자도 알아야할 소프트웨어 테스팅 실무