[ISTQB] Chapter 3. 정적 테스팅

🟡 3.1 정적 테스팅 기초

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

 

 

 

 

✅ 3.1.2 정적 테스팅의 효과

 

- 소프트웨어 개발 수명주기 초반에 적용하면 동적 테스팅을 실행하기 전에 결함을 조기 발견할 수 있음.

- 정적 테스팅 기법을 사용해 결함을 발견하고 수정하는 것이 동적 테스팅에 비해 적은 비용이 듦.

- 동적 테스팅으로 발견이 쉽지 않은 결함 식별 가능.

- 설계나 코딩의 결함 예방

- 개발 생산성 향상

- 개발 비용 및 기간 단축

- 테스팅 비용 및 기간 단축

- 리뷰에 참여하는 팀원 간의 의사소통 개선

- 소프트웨어 수명주기 전반에 걸친 총 품질 비용 감소

 

 

 

✅ 3.1.3 정적 테스팅과 동적 테스팅의 차이

 

공통 목적 : 작업 산출물의 품질을 평가하고 가능한 빨리 결함을 식별하고자 하는 것.

 

 

정적 테스팅 VS 동적 테스팅

 

1. 소프트웨어를 실행함으로써 결함으로 발생하는 장애를 찾아내기(동적 테스팅) 보다는 작업 산출물에서 직접 결함을 발견.

-> 결함은 장애를 일으키지 않고 오랜 기간 숨어있을 수 있는데 정적 테스팅은 훨씬 적은 노력으로 발견 가능.

 

2. 정적 테스팅은 작업 산출물의 일관성과 내부 품질을 향상하기 위해 사용하는 반면, 동적 테스팅은 외부에 보이는 동작에 초점을 맞추고 있음.

 

 

<정적 테스팅으로 발견하기 쉬운 결함 유형>

- 요구사항 결함

- 설계 결함

- 코딩 결함

- 표준과의 차이

- 잘못된 인터페이스 명세

- 보안 취약점

- 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성

 

"유지보수성 결함은 정적 테스팅으로만 발견할 수 있다."

 

 

 

🟡 3.2 리뷰 프로세스

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

 

1) 계획

- 리뷰에 포함한 체크리스트 전달 받음.

- 리뷰 목적, 리뷰할 문서의 범위, 평가할 품질 특성 등을 포함하는 범위의 정의

- 공수와 기간 산정

- 리뷰 유형에 따라 결정되는 역할, 활동, 체크리스트와 같은 리뷰 특성의 식별

- 리뷰에 참석할 인원을 선정하고 역할 할당

- 공식적인 리뷰에서는 시작 및 종료 조건 정의

- 공식적인 리뷰에서는 시작 조건이 충족되는지 확인

 

2) 리뷰 착수

- 작업 산출물과 이슈 기록 양식, 체크리스트, 관련된 작업 산출물과 같은 기타 자료 배포

- 참가자에게 범위, 목적, 프로세스, 역할, 작업 산출물을 설명

- 참가자가 리뷰에 대해 가질 수 있는 여러 질문에 답변

 

3) 개별 리뷰

- 작업 산출물 전체 혹은 부분 리뷰

- 잠재 결함, 권고사항, 질문 기록

 

4) 이슈 논의 및 분석

- 식별한 잠재 결함 전달

- 잠재 결함 분석 및 담당자 및 상태 할당

- 품질 특성 평가 및 문서화

- 종료 조건을 기준으로 리뷰 결과를 평가하여 리뷰 결과 결정

 

5) 수정 및 보고

- 잠재 결함에 대한 결함 보고서 작성

- 발견한 결함 수정(author가 수정함)

- 결함 정보를 공유

- 필요한 경우, 주석 작성자의 동의를 포함해 업데이트 된 결함 상태 기록

- 메트릭 수집(공식적 리뷰의 경우)

- 종료 조건의 충족 여부 확인(공식적 리뷰의 경우)

- 종료 조건이 충족되면 해당 작업 산출물 인수

 

 

 

✅ 3.2.2 공식  리뷰에서의 역할과 책임

 

1) 저자(Author)

- 리뷰 대상 작업 산출물 작성

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

 

2) 관리자(Management)

- 리뷰 계획 담당

- 리뷰 실행 결정

- 인력, 예산, 시간 할당

- 진행 비용 대비 효과 모니터링(비용 효율성)

- 결과가 만족스럽지 않은 경우, 제어 결정(control decisions) 실행

 

3) 촉진자 or 중재자(Facilitator or Moderator)

- 리뷰 회의가 효과적으로 진행되도록 하는 사람

- 다양한 관점들에 대한 중재

- 리뷰의 성공 여부에 결정적인 역할을 하는 사람

 

4) 리뷰 리더(Review leader)

- 리뷰에 대한 책임을 지는 사람

- 참여자를 결정하고 언제 어디서 진행할지 결정

 

5) 검토자(Reviewers)

 - 해당 주제에 대한 전문가, 프로젝트 참여 인원, 작업 산출물에 관심이 있는 이해관계자나 특정 비즈니스 배경을 가진 사람 등

- 리뷰 대상 작업 산출물의 잠재적 결함 식별

- 다양한 관점을 대표하는 사람

 

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

- 개별 리뷰 활동에서 발견한 잠재 결함 수집

- 새로운 잠재 결함, 쟁점, 결정 사항 기록(리뷰 회의가 진행되는 경우)

 

 

 

✅ 3.2.3 리뷰 유형

 

1) 비공식 리뷰

- 목적 : 잠재적 결함 발견, 소소한 문제의 빠른 해결, 새로운 아이디어나 해결책 도출

- 공식 프로세스를 기반으로 하지 않음

- 리뷰 회의를 진행하지 않을 수 있음

- 저자의 동료 또는 다른 사람이 수행할 수 있음

- 결과는 문서로 기록될 수 있음

- 검토자에 따라 성과가 달라짐

- 체크리스트 사용 여부는 상황에 맞게 판단 가능

- 애자일 개발에서 사용

 

2) 워크쓰루(walkthrough)

- 목적 : 결함 발견, 소프트웨어 제품 개선, 다른 구현 방법 고려, 표준이나 규정 준수 평가, 참여자 교육, 합의 도출, 다양한 기술이나 스타일에 대한 아이디어 교환

- 리뷰 회의 전 개별 준비는 필요에 따라 수행

- 리뷰 회의는 작업 산출물의 저자가 주도

- 서기 참여 필수

- 체크리스트 사용여부는 상황에 맞게 판단

- 시나리오, 드라이런, 시뮬레이션의 형태로 수행 가능

- 잠재 결함 로그와 리뷰 보고서 작성

 

3) 기술 리뷰(Technical review)

- 목적 : 합의 도출, 잠재적 결함 발견, 작업 산출물의 품질 평가, 새로운 아이디어 도출, 저자가 미래의 작업 산출물을 개선하도록 지원하고 동기를 부여, 다른 구현 방법 고려

- 검토자는 저자의 기술 동료이면서, 동일 분야 또는 다른 분야의 기술 전문가여야 함.

- 리뷰 회의 전 개별 준비 필요

- 리뷰 회의는 선택사항이며, 훈련된 촉진자(저자가 아님)가 주도

- 서기 참여 필수(저자가 아님)

- 체크리스트 사용 여부는 상황에 맞게 판단 가능

- 잠재 결함 로그와 리뷰 보고서 작성

 

4) 인스펙션(Inspection)

- 목적 : 잠재적 결함 발견, 작업 산출물의 품질 평가, 저자 학습과 근본 원인 분석을 통한 유사 결함의 발생 예방, 저자가 미래의 작업 산출물을 개선하고 합의를 이끌어내도록 동기를 부여

- 규칙 및 체크리스트를 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행

- 리뷰 회의 전 개별 준비 필요

- 명확하게 정의된 역할 참여, 낭독자의 참여 가능

- 검토자는 저자의 기술 동료이면서, 동일 분야의 기술 전문가여야 함.

- 명시된 시작 및 종료 조건을 사용

- 서기 참여 필수

- 리뷰 회의는 훈련된 촉진자(저자가 아님)가 주도

- 저자는 리뷰 리더, 글을 읽는 사람 또는 서기가 될 수 없음.

- 잠재 결함 로그와 리뷰 보고서 작성

- 메트릭 수집 및 사용

 

 

 

✅ 3.2.4 리뷰 기법 적용

 

1) 애드혹(Ad hoc)

- 검토자에게 리뷰 수행 방법에 대한 안내가 거의 제공되지 않음.

- 검토자는 작업 산출물을 순차적으로 읽으면서 이슈를 식별하고 기록.

- 특별한 준비 없이 사용되기 때문에 검토자의 능력이 중요함.

 

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

- 체계적인 기법

- 검토자는 리뷰 시작 시점에 배포된 체크리스트를 기반으로 이슈를 식별

- 체크리스트는 리뷰 대상 작업 산출물 유형별로 작성해야 하며, 주기적으로 개선

- 일반적인 결함 유형에 대한 체계적인 커버리지를 갖는 다는 장점이 있음.

 

3) 시나리오 및 드라이 런

- 검토자는 작업 산출물을 어떻게 검토할지에 대한 구조화된 지침을 제공받음.

- 작업 산출물의 예상되는 용도를 기반으로 작업 산출물에 대해 "드라이런"을 수행할 수 있도록 검토자를 지원

- 체크리스트와 마찬가지로 너무 시나리오에만 얽매이지 않아야 함.

 

4) 관점 기반(Perspective-based)

- 다양한 이해관계자의 관점을 사용

- 검토자 간에 중복되는 이슈가 줄어들고 개별리뷰가 좀 더 깊이 있게 진행된다는 장점이 있음.

- 검토자가 이해관계자의 관점을 기반으로 하는 산출물을 작성해야 함.

- 요구사항 및 기술 작업 산출물에 대한 리뷰에 가장 효과적인 기법

 

5) 역할 기반(Role-based)

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

 

 

 

✅ 3.2.5 리뷰의 성공 요소

 

<조직 차원의 성공 요인>

- 리뷰는 명확한 목적이 있어야 함.

- 목적을 달성하기에 적합하고 소프트웨어 작업 산출물 및 참여자 유형 수준에 맞는 리뷰 유형을 적용해야함.

- 모든 리뷰 기법은 리뷰 대상 작업 산출물의 결함을 효과적으로 식별하기에 적합해야 함.

- 사용하는 체크리스트는 주요 리스크 식별을 위해 작성해야 하며 가장 최신의 정보를 반영해야 함.

- 규모가 큰 문서는 작은 단위로 작성해야 함.

- 참여자는 충분한 준비 시간을 가져야 함.

- 충분한 여유를 가지고 리뷰 일정을 수립해야 함.

- 경영진은 리뷰 프로세스를 지원해야 함.

- 리뷰는 기업의 품질 및 테스트 정책에 통합되어야 함.

 

 

<사람과 관련된 성공 요인>

- 리뷰 목적 달성을 위해 적절한 사람들이 참여해야 함.

- 테스터는 리뷰에 기여하는 중요한 검토자로 간주됨.

- 참여자는 세부사항에 충분한 시간과 주의를 기울여야 함.

- 작은 단위로 리뷰를 진행해 개별 리뷰나 리뷰 회의 중에 검토자가 집중력을 잃지 않도록 해야 함.

- 식별된 결함은 승인하고 평가하고, 객관적으로 처리해야 함.

- 적절한 교육을 제공해야 함.

- 학습 및 프로세스 개선에 대한 조직 문화를 촉진해야 함.

- 다른 참여자에 대한 적대감을 나타낼 수 있는 신체 언어 및 행동을 피해야 함.

 

 

 

 

 

 

 

 

Reference

ISTQB CTFL Syllabus 2018 V 3.1.1_한글_v1.0

 

위 책 내용을 챕터별 중요한 포인트 위주로 정리한 자료입니다.

스스로 공부하기 위한 요점정리 노트이므로 상업적인 사용 목적은 전혀 없음을 알려드립니다:)

 

이 시험에 대한 정보 및 각종 자료는 아래 사이트에서 확인하실 수 있습니다. ⬇⬇⬇

http://www.kstqb.org/sw/sw3.asp