3.1 정적 기법과 테스트 프로세스
동적 기법(Dynamic testing) : 실제 구현된 SW를 실행하여 테스팅
정적 기법(Static testing) : SW가 구현되기 전에 요구사항 정의서, 설계서, 코드 등의 개발 산출물을 테스팅 (리뷰/인스펙션)
리뷰 : 코드를 포함한 개발 및 테스트 산출물을 검토하고 테스팅하는 방법
- 개발 수명주기 초기에 리뷰를 통해 발견하는 결함의 수정 비용은 나중에 발견하는 비용에 비해 낮다
- 장점 : 조기 결함 발견/개발 생산성 향상/기간 단축/테스팅 비용 감소/수명주기 전체의 비용 감소/결함 감소/커뮤니케이션 향상
- 동적 테스팅에서 발견하기 어려운 개발 산출물의 누락과 같은 결함을 발견할 수 있다.
ex) 표준 위반/요구사항 결함/개발 설계 결함/불충분한 유지보수성/부정확한 인터페이스 명세
정적 테스트 프로세스
- 정적 테스트 준비단계 -> 리뷰/분석 단계 -> 후속 처리 확인 단계
3.2 리뷰 프로세스
리뷰는 잘 구조화된 공식적인 것부터 매우 비공식적인 것까지 다양한 형태를 갖는다.
공식적 리뷰의 절차
- 계획 활동 : 참가인원을 선정하고 역할 할당, 시작 및 종료 기준의 정의, 코드 리뷰 범위 등을 결정
- 시작 : 문서 배포, 시작 기준 점검
- 개별 준비 : 참석자들이 사전 리뷰 활동을 통해 잠재적 결함이나 회의에서 제기할 코멘트를 준비
- 리뷰 미팅 : 개별 준비 내용을 토대로 토의하고 이를 기록, 결함 처리 방안을 제안하고 결함 여부에 대한 결정을 내린다.
- 재작업 : 발견된 결함을 문서의 저자가 수정
- 후속 처리 확인 : 발견된 결함이 잘 수정되었는지 확인, 관련 측정치(메트릭)을 수집하고 리뷰 종료 기준 점검
공식적 리뷰에서의 역할
- 관리자 : 리뷰의 실행여부 결정, 리뷰 일정 및 목적 달성 여부를 확인
- 중재자 : 문서의 리뷰를 리드함. 리뷰를 계획, 미팅 진행, 후속 조치의 처리 여부 등을 관리. 리더의 자질을 갖춘 사람이어야 하며 반드시 리뷰 중재자 교육이 필요함
- 저자 : 리뷰 대상 문서의 작성자 또는 책임자(개발자)
- 검토자 : 해당 분야의 기술적/비즈니스적 배경을 갖춘 자, 인시던트를 발견하고 기술하는 사람(인스펙터, 테스트 전문가), 모든 형태의 리뷰 미팅에 참석하여 리뷰 활동을 함께 수행해야 한다.
- 기록자 : 리뷰 미팅에서 발견된 모든 이슈, 문제점 등을 기록하고 문서화
리뷰의 유형
1. 비공식적 리뷰
목적 : 저렴한 방법으로 일정 수준의 성과를 달성하기 위함
- 공식적인 절차가 없음, 문서화 또한 선택적임
- Pair 프로그래밍에 의한 리뷰이거나 기술 선임자와 설계와 코드를 리뷰
- 리뷰하는 사람이 누구냐에 따라 성과가 좌우됨
2. 기술적 리뷰
목적 : 기술적 문제 해결, 토론, 의사결정, 대안평가, 결함발견, 명세서와의 적합성을 검토하기 위함
- 동료와 기술 전문가가 참여, 일정 프로세스가 존재함
- 관리자 개입이 없이, 동료 검토 형태로 진행될 수 있다.
- 사전 준비 단계 있음, 체크리스트, 리뷰 리포트, 인시던트 리스트 등이 선택적으로 있을 수 있음
- 검토자에 관계없이 일관되고 정량적인 효과 도출 가능
3. 워크쓰루
목적 : 학습, 시스템에 대한 이해, 결함 발견
- 저자에 의한 진행 및 제어
- 시간 및 인원수의 제한이 없음, 상황에 따라 변할 수 있는 세션
- (선택적) 검토자 지정, 리뷰 리포트 등의 준비과정이 있을 수 있음
4. 인스펙션
목적 : 결함 발견
- 훈련된 중재자에 의한 진행 및 제어
- 주로 동료 검사 활용
- 역할 정의됨, 메트릭을 수집하고 활용함
- 정식 프로세스들이 존재함
- 미팅 전 준비과정이 필수
- 인스펙션 리포트와 인시던트 리스트 산출
- 정식적인 후속 처리 확인(Follow-up)프로세스 존재
인스펙션의 절차
1) 분량(Capacity)계획
- 매월 작성량(코드) 추정 / 인스펙션 목표 및 비율 설정 / 주기적인 인스펙션량 추정 / 시간, 인원 할당
2) 인스펙션 수행
- 준비 / 인스펙션 수행 / 프로세스 개선 / 재작업 여부 결정 / 종료
3) 분석 및 평가
- 데이터 수집 / 분석 / 관리자 보고 / 결함 사전 예방 활동
리뷰는 리스크 기반으로 접근하는 시각이 필요하다
높은 리스크 - 공식적인 기법 / 낮은 리스크 - 비공식적 기법
사업적 높은 리스크 - 워크쓰루 / 기술적 높은 리스크 - 기술적 리뷰 또는 인스펙션
3.3 도구에 의한 정적 분석
동적 테스팅으로 찾기 힘든 결함을 발견, 장애보다는 결함을 발견
도구의 도움을 받아 수행, 프로그램 코드를 분석, HTML이나 XML과 같이 생성된 결과물도 분석 가능
- 테스트 실행 전에 결함을 조기 발견할 수 있다.
- 높은 복잡도와 같은 메트릭 계산을 통해 코드와 설계의 의심스러운 부분을 조기에 경보
- 코드와 설계의 유지보수성 향상, 결함 예방
주로 발견되는 결함
- 정의되지 않은 값으로 변수 참조 / 모듈과 컴포넌트 간의 일관되지 않은 인터페이스 / 사용되지 않는 변수, 코드 / 코딩 표준 위반 / 보안 취약성 / 구문 규칙 위반 등
'ISTQB 공부방' 카테고리의 다른 글
Part.4 테스트 설계 기법 - ISTQB (3) - 구조 기반 기법 (0) | 2021.01.05 |
---|---|
Part.4 테스트 설계 기법 - ISTQB (2) - 명세기반 기법 (0) | 2021.01.05 |
Part.4 테스트 설계 기법 - ISTQB (1) (0) | 2021.01.04 |
Part.2 소프트웨어 수명주기와 테스팅 - ISTQB (0) | 2021.01.03 |
Part.1 소프트웨어 테스팅의 기초 - ISTQB (0) | 2021.01.03 |
댓글