3.1.1 정적 테스팅으로 검토할 수 있는 작업 산출물(다양한 정적 테스팅 기법으로 확인할 수 있는 SW 작업 산출물 유형을 인식할 수 있다.)
정적 분석은 적절한 분석 도구가 있거나 자연어로 작성된 작업 산출물을 통해 평가 가능
- 비즈니스 요구사항, 기능 요구사항, 보안 요구사항과 같은 명세
- 에픽(epic), 사용자 스토리, 인수 기준
- 아키텍처 및 설계 명세
- 코드
- 테스트 계획, 테스트 케이스, 테스트 프로시저, 자동화 테스트 스크립트와 같은 테스트웨어
- 사용자 가이드
- 웹 페이지
- 계약, 프로젝트 계획, 일정, 예산 기획
- 형상 및 인프라 셋업
- 액티비티 다이어그램과 같은 모델 기반 테스팅에 사용되는 모델
3.1.2 정적 테스팅의 효과(정적 테스팅의 가치를 예제를 통해 설명할 수 있다.)
효과
- 동적 테스트 실행 전, 효율적으로 결함을 발견하고 수정 혹은 제거
- 동적 테스팅으로 발견이 쉽지 않은 결함 식별(코딩 등....)
- 요구사항 불일치, 애매모호함, 모순, 누락, 부정확, 중복 등을 식별해서 설계나 코딩의 결함 예방
- 개발 생산성 향상 (예: 설계 개선, 향상된 코드 유지보수성)
- 개발 비용 및 기간 단축
- 테스팅 비용 및 기간 단축
- 수명주기 후반 또는 출시 후 운영 과정에서 발견되는 장애 감소로 소프트웨어 수명주기 전반에 걸친 총 품질 비용 감소
- 리뷰에 참여하는 팀원 간의 의사소통 개선
3.1.3 정적 테스팅과 동적 테스팅의 차이(정적 기법과 동적 기법의 차이를 테스트 목적, 식별해야하는 대상, 결함 유형, SW 생명주기의 역할 등을 고려해 설명할 수 있다.)
정적 테스팅 | 동적 테스팅 | |
특징 | 작업 산출물에서 결함 발견 적은 노력(비용)으로 발견 가능 일관성과 내부 품질을 위한 테스팅 |
SW 실행으로 결함 발견 많은 노력(비용)으로 발견 가능 외부에 보이는 동작을 위한 테스팅 |
결함 유형 | 요구사항 결함 (예: 불일치, 모호함, 모순, 누락, 부정확, 중복 등) 설계 결함 (예: 비효율적인 알고리즘이나 데이터베이스 구조, 높은 결합도, 낮은 응집도) 코딩 결함 (예: 정의되지 않은 값이 있는 변수, 선언했으나 사용하지 않는 변수, 도달할 수 없는 코드, 중복 코드 등) 표준과의 차이 (예: 코딩 표준 미준수 등) 잘못된 인터페이스 명세 (예: 호출하는 시스템과 호출되는 시스템이 서로 다른 측정 단위 사용) 보안 취약점 (예: 버퍼 오버플로우에 대한 취약성) 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성 (예: 특정 인수 조건에 대한 테스트 누락) 유지보수성 결함(예: 잘못된 모듈화, 낮은 컴포넌트 재사용성, 새로운 결함을 발생시키지 않고는 분석하거나 수정하기 어려운 코드) |
수명주기 초기에 런타임 문제를 찾을 수 있게 해준다. |
3.2.1 작업 산출물 리뷰 프로세스(작업 산출물 리뷰 및 활동을 요악할 수 있다.)
계획(정의, 추정, 식별, 역할 할당, 조건 정의, 시작 조건 충족 여부)
- 리뷰 목적, 리뷰할 문서가 전체인지 특정 부분인지, 평가할 품질 특성 등을 포함하는 범위의 정의
- 노력과 기간 추정
- 리뷰 유형에 따라 결정되는 역할, 활동, 체크리스트와 같은 리뷰 특성의 식별
- 리뷰에 참석할 인원을 선정하고 역할 할당
- 인스펙션과 같은 보다 공식적인 리뷰의 경우에는 시작 및 종료 조건 정의
- 공식적인 리뷰 유형의 경우 시작 조건이 충족되는지 확인
리뷰착수
- (물리적, 전자적 수단에 의한) 작업 산출물과 이슈 기록 양식, 체크리스트, 관련된 작업 산출물 같은 기타 자료 배포
- 참가자에게 범위, 목적, 프로세스, 역할, 작업 산출물을 설명
- 참가자가 리뷰에 대해 가질 수 있는 여러 질문에 답변
개별 리뷰
- 작업 산출물 전체 혹은 부분 리뷰
- 잠재 결함, 권고사항, 질문 기록
이슈 논의 및 분석
- 식별한 잠재 결함 전달 (예: 리뷰 회의 중 전달)
- 잠재 결함 분석 및 담당자 및 상태 할당
- 품질 특성 평가 및 문서화
- 종료 조건을 기준으로 리뷰 결과를 평가하여 리뷰 결과 결정 (예: 거부(reject), 주요 수정 필요, 약간의 수정 후 수락 등)
수정 및 보고
- 작업 산출물에 대한 수정을 요하는 잠재 결함에 대한 결함 보고서 작성
- 리뷰한 작업 산출물에서 발견한 결함 수정 (일반적으로 저자가 수정)
- 결함 정보를 적절한 사람이나 팀과 공유 (리뷰한 작업 산출물과 연관된 다른 작업 산출물이 있는 경우)
- 필요한 경우 주석 작성자의 동의를 포함해 (공식적인 리뷰 유형인 경우) 업데이트 된 결함 상태 기록
- 메트릭 수집 (공식적인 리뷰 유형인 경우)
- 종료 조건의 충족여부 확인 (공식적인 리뷰 유형인 경우)
- 종료 조건이 충족되면 해당 작업 산출물 인수
3.2.2 공식 리뷰에서의 역할과 책임(역할과 책임을 인식할 수 있다.)
리뷰 유형에 따라 한 사람이 두 개 이상의 역할을 수행할 수 있으며, 각 역할과 활동 역시 리뷰 유형에 따라 달라질 수 있다. 각종 툴로 인해 서기가 필요하지 않는 경우가 많다.
저자
- 리뷰 대상 작업 산출물 작성
- 리뷰 대상 작업 산출물 결함 수정 (필요한 경우)
관리자
- 리뷰 계획 담당
- 리뷰 실행 결정
- 인력, 예산, 시간 할당
- 진행 비용 대비 효과 모니터링
- 결과가 만족스럽지 않은 경우 제어 결정(control decisions) 실행
촉진자(중재자)
- 리뷰 회의 진행 시 효과적 회의 진행 보장(인스펙션 등)
- 필요한 경우 다양한 관점들에 대한 중재
- 많은 경우 리뷰의 성공 여부에 결정적인 역할을 하는 사람
리뷰 리더
- 전반적으로 리뷰에 대한 책임을 지는 사람
- 참여자를 결정하고 언제 어디서 진행할지 결정
검토자
- 해당 주제에 대한 전문가, 프로젝트 참여 인원, 작업 산출물에 관심이 있는 이해관계자나 특정 기술
- 혹은 비즈니스 배경을 가진 사람 등
- 리뷰 대상 작업 산출물의 잠재적 결함 식별
- 다양한 관점을 대표할 수 있음 (예: 테스터, 개발자, 사용자, 운영자, 비즈니스 분석가, 사용성 전문가 등)
서기
- 개별 리뷰 활동에서 발견한 잠재 결함 수집
- 리뷰 회의가 진행되는 경우 새로운 잠재 결함, 쟁점, 결정 사항 기록
3.2.3 리뷰 유형(리뷰 유형의 차이를 설명할 수 있다.)
비공식 리뷰 | 워크 쓰루 | 기술 리뷰 | 인스펙션 | |
정의 | 페어프로그래밍에 의한 리뷰이거나 기술 선임자가 설계와 코드를 리뷰하는 것일수 있음 | 개발 산출물을 작성하는 중에 산출물을 검토하고결함을 찾아내는 기법 | 기술자 개입 없이 동료와 기술 전문가가 참여하는 결함 발견을 위한 문서화 되고 정의된 프로세스가 존재함 | 개발 표준 위반, 상위 레벨 산출물 불일치 등의 결함 발견을 위해 저자 외 다른 전문가가 검사하는 가장 공식적인 리뷰 기법으로 항상 문서화된 절차를 기반으로 한다. |
예 | 버디 체크 페어링 짝 리뷰 |
|||
주요 목적 |
잠재적 결함 발견 | 결함 발견 SW 제품 개선 다른 구현 방법 고려 표준, 규정 준수 평가 |
합의 도출 잠재적 결함 발견 |
잠재적 결함 발견 작업 산출물의 품질 평가 및 자신감 획득 저자 학습과 근본 원인 분석을 통한 유사 결함의 발생 예방 |
기타 목적 |
새로운 아이디어나 해결책 도출 소소한 문제의 빠른 해결 |
다양한 기술이나 스타일에 대한 아이디어 교환 참여자 교육 합의 도출 |
작업 산출물의 품질평가 및 자신감 획득 새 아이디어 도출 저자가 미래의 작업 산출물을 개선하도록 지원 및 동기 부여 다른 구현 방법 고려 |
저자가 앞으로의 작업 산출물과 SW 개발 프로세스를 개선하고 합의를 이끌어 내도록 동기 부여 |
특징 | 문서화된 프로세스를 기반으로 하지 않음 리뷰 회의를 진행하지 않을 수 있음 저자의 동료(버디 체크) 또는 다른 사람이 수행할 수 있음 결과는 문서로 기록할 수 있음 검토자에 따라 성과가 달라짐 체크리스트 사용 여부는 상황에 맞게 판단 애자일 개발에서 매우 일반적으로 사용됨 |
리뷰 회의 전 개별 준비는 필요에 따라 수행 리뷰 회의는 일반적으로 작업 산출물의 저자가 주도 서기 참여 필수 체크리스트 사용 여부는 상황에 맞게 판단 시나리오, 드라이 런, 시뮬레이션의 형태로 수행할 수 있음 잠재 결함 로그와 리뷰 보고서 작성 실무에서는 비공식적인 형식에서 매우 공식적인 형식까지 다양할 수 있음 |
검토자는 저자의 기술 동료이면서, 동일 분야 또는 다른 분야의 기술 전문가여야 함 리뷰 회의 전 개별 준비 필요 리뷰 회의는 선택 사항이며, 이상적으로는 훈련된 촉진자(일반적으로 저자가 아닌)가 주도 서기는 반드시 있어야 하며, 이상적으로는 저자가 아닌 사람이 수행 체크리스트 사용 여부는 상황에 맞게 판단 잠재 결함 로그와 리뷰 보고서 작성 |
규칙 및 체크리스틀 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행 3.2.2 절에서 필수로 지정한 바와 같이 명확하게 정의된 역할 참여, 낭독자의 참여 가능 리뷰 회의 전 개별 준비 필요 검토자는 저자의 동료 또는 작업 산출물과 연관된 분야의 전문가 명시된 시작 및 종료 조건을 사용 서기 참여 필수 리뷰 회의는 훈련받은 촉진자(저자가 아닌 사람)가 주도 저자는 리뷰 리더, 글을 읽는 사람 또는 서기가 될 수 없음 잠재적인 결함 로그 및 리뷰 보고서 작성 인스펙션 프로세스 포함 전체 소프트웨어 개발 프로세스를 개선하기 위해 메트릭을 수집하고 사용 |
3.2.4 리뷰 기법 적용(작업 산출물에 리뷰 기법을 적용해 결함을 식별할 수 있다.)
유형에 따른 리뷰 방법
애드 훅 | 체크리스트 기반 | 시나리오 및 드라이 런 |
관점 기반 | 역할 기반 |
준비 없이 사용되는 기법 검토자에게 안내가 제공 X 검토자는 작업 산출물을 순차적으로 읽으며 이슈를 식별하고 기록 검토자에 능력에 크게 의존 여러 검토자가 동일한 문제를 보고 가능 |
체계적인 리뷰 기법 체크리스트를 기반으로 이슈 식별(리뷰 체크리스트는 잠재 결함을 식별하기 위해 경험에서 도출한 일련의 질문으로 구성) 체크리스트는 유형별로 작성해야 한다. 이전 리뷰에서 누락 된 이슈 유형을 다루기 위해 주기적인 개선 필요 일반적인 결함 유형에 대한 체계적인 커버리지를 가짐 검토자는 체크리스트를 단순히 실행하는 것 뿐만 아니라 체크리스트로 식별할 수 없는 결함도 찾아야 함 |
작업 산출물을 어떻게 검토할지에 대한 구조화된 지침을 제공 받음 작업 산출물의 예상되는 용도를 기반으로 드라이런(고장 가능성을 의도적으로 완화시키는 테스트 프로세스)을 수행할 수 있도록 검토자를 지원함 단순한 체크리스트 항목보다 특정 결함 유형을 식별하는 방법에 대한 지침 제공 체크리스틍와 마찬가지로 누락된 기능을 발견하기 위해 시나리오에 얽매이면 안됨 |
역할 기반과 마친가지로 다양한 관계자의 관점(사용자, 영업, 설계자, 테스터, 운영자)을 사용하게 된다. 이를 통해 검토자 간 중복되는 이슈가 줄어들고 개발리뷰가 좀 더 깊이 있게 진행 됨 검토자가 리뷰 대상 작업 산출물로부터 관계자의 관점을 기반으로 하는 산출물 작성 요구(테스터가 인수 테스트 초안 작성 시도 가능) 체크리스트도 활용 리뷰 중 가장 효과적인 기법 |
검토자가 작업 산출물을 개별 관계자 역할의 관점에서 평가하는 기법 역할에는 특정 최종 사용자(경험 많은, 적은, 노인, 아동)과 조직 내 특정 역할(사용자 관리자, 시스템 관리자, 테스터)가 있다. 역할이 비슷하기 때문에 같은 원칙이 관점 기반에도 적용된다. |
3.2.5 리뷰의 성공 요소(리뷰의 성공 요소를 설명할 수 있다.)
성공적인 리뷰를 위해서는 적절한 리뷰 유형과 기법을 고려해야 한다. 또한, 리뷰의 결과에 영향을 주는 여러 가지 요인이 존재한다.
조직 차원의 성공 요인
- 리뷰는 명확한 목적이 있어야 한다. 목적은 리뷰 계획 시 정의하며, 측정 가능한 종료 조건으로 사용된다.
- 목적을 달성하기에 적합하고, SW 작업 산출물 및 참여자 유형 수준에 맞는 리뷰 유형을 적용해야 한다.
- 체크리스트 기반 및 역할 기반 리뷰와 같이 사용하는 모든 리뷰 기법은 리뷰 대상 작업 산출물의 결함을 효과적으로 식별하기에 적합해야 한다.
- 사용하는 체크리스트는 주요 리스크 식별을 위해 작성해야 하며, 가장 최신의 정보를 반영해야 한다.
- 규모가 큰 문서는 작은 단위로 작성하고 리뷰를 수행해 저자에게 결함에 대한 피드백을 조기에, 빈번하게 제공하여 품질 관리를 수행한다.
- 참여자는 충분한 준비 시간을 갖는다
- 충분한 여유를 가지고 리뷰 일정을 수립한다.
- 경영진은 리뷰 프로세스를 지원하다.(충분한 시간, 인력)
- 리뷰는 기업의 품질 및 테스트 정책에 통합된다.
사람과 관련된 성공 요인
- 리뷰 목적 달성을 위해 적절한 사람들이 참여한다.
- 테스터는 리뷰에 기여하는 중요한 검토자로 간주 된다. 테스터는 작업 산출물의 학습을 통해 좀 더 효과적인 테스트를 준비하고 조기에 테스트를 준비할 수 있게 된다.
- 참여자는 세부사항에 충분한 시간과 주의를 기울여야 한다.
- 검토자가 집중력을 잃지 않도록 해야 한다.
- 식별된 결함은 승인하고 평가하고, 객관적으로 처리해야 한다.
- 리뷰 회의를 잘 관리해 참여자가 리뷰에 참여한 시간이 가치 있다고 인식하게 해야 한다.
- 리뷰는 모든 참여자가 신뢰하는 분위기에서 진행해야 한다.
- 참여자는 지루함, 분노, 적대감을 나타낼 수 있는 언어 및 행동을 피해야 한다.
- 적절한 교육을 제공한다. 특히 공식적인 리뷰에는 더 그렇다.
- 학습 및 프로세스 개선에 대한 조직 문화를 촉진해야 한다.
'ISTQB CTFL' 카테고리의 다른 글
5. 테스트 관리 (0) | 2021.05.26 |
---|---|
4. 테스트 기법 (0) | 2021.05.25 |
2. 소프트웨어 개발 수명주기와 테스팅 (0) | 2021.05.23 |
1. 테스팅의 기초 (0) | 2021.04.04 |
0. ISTQB CTFL 합격후기 (1) | 2021.03.31 |
댓글