[CTFL] 3장. 정적 테스팅

#ISTQB

ISTQB-CTFL 실러버스 3장 정리하기

3장. 정적 테스팅

용어

이상 사항(anomaly): 예상과 다른 모든 상태나 결과로, 결함의 가능성을 나타내는 것
동적 테스팅(dynamic testing): 소프트웨어를 실행하여 결함을 발견하는 테스팅 방법
공식 리뷰(formal review): 정의된 프로세스와 문서화된 결과물이 요구되는 체계적인 리뷰
비공식 리뷰(informal review): 정의된 프로세스 없이 수행되는 리뷰
인스펙션(inspection): 가장 공식적인 리뷰 유형으로, 이상 사항을 최대한 찾는 것을 목적으로 함
리뷰(review): 작업 산출물의 품질을 평가하기 위해 수행하는 정적 테스팅 활동
정적 분석(static analysis): 소프트웨어를 실행하지 않고 도구를 이용해 코드나 산출물을 분석하는 활동
정적 테스팅(static testing): 소프트웨어를 실행하지 않고 작업 산출물을 검토하는 테스팅 방법
기술 리뷰(technical review): 기술적 자격을 갖춘 리뷰어가 수행하는 공식적인 리뷰 유형
워크쓰루(walkthrough): 저자가 주도하여 참가자들이 함께 작업 산출물을 검토하는 리뷰 유형

3.1 정적 테스팅의 기초

동적 테스팅과 달리 정적 테스팅은 테스트 대상 SW를 실행하지 않아도 된다. 정적 테스팅은 Validation과 Verification 모두에 적용할 수 있다.

정적 분석은 테스트 케이스가 필요 없고 도구를 사용하는 경우가 많기 때문에 상대적으로 적은 노력으로 동적 테스팅 전에 문제를 식별할 수 있다. 정적 분석을 지속적 통합(CI) 프레임워크에 통합하는 경우가 많다. 정적 분석은 주로 구체적인 코드 결함을 식별하는 데 사용하지만 유지보수성과 보안을 평가하는 데도 사용한다(예: 맞춤법 검사기, 가독성 도구).

3.1.1 정적 테스팅으로 검사 가능한 작업 산출물

정적 테스트를 사용해 거의 모든 작업 산출물을 검토할 수 있다. 읽고 이해할 수 있는 모든 작업 산출물은 리뷰 대상이 될 수 있다. 그러나 정적 분석의 경우 작업 산출물을 검토할 수 있는 기준이 되는 어떤 구조가 필요하다(예: 모델, 공식 문법이 정해진 코드나 텍스트).

사람이 해석하기 어려운 것과 도구로 분석해서는 안 되는 작업 산출물은 정적 테스트에 적합하지 않다.

3.1.2 정적 테스팅의 가치

정적 테스팅은 SDLC 초기 단계에서 결함을 식별하기 때문에 조기 테스팅의 원리를 지킬 수 있게 한다. 또한 동적 테스팅으로 식별할 수 없는 결함을 찾을 수 있다.

정적 테스팅은 작업 산출물의 품질을 평가하고 신뢰를 쌓을 방법을 제공한다. SDLC 초기에 수행할 수 있으므로 이해관계자 간 공통된 이해를 형성할 수 있다.

※ 정적 테스팅에서는 다양한 이해관계자가 참여하는 것이 권장된다.

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

정적 테스팅과 동적 테스팅은 서로를 보완한다. 작업 산출물 결함의 식별을 지원하는 등 비슷한 목적을 가지고 있지만 다음과 같은 차이도 있다.

  • 정적 테스팅이나 동적 테스팅 중 한 가지로만 식별할 수 있는 결함 유형도 있다.
  • 정적 테스팅은 결함을 직접 식별하는 반면, 동적 테스팅은 장애를 일으킨 후 연관된 결함을 후속 분석을 통해 찾아낸다.
  • 정적 테스팅은 거의 실행되지 않거나 동적 테스팅으로 도달하기 어려운 코드 경로에 있는 결함을 더 쉽게 찾아낸다.
  • 정적 테스팅은 비-실행 작업 산출물에도 적용할 수 있지만, 동적 테스팅은 실행 가능한 작업 산출물에만 적용할 수 있다.
  • 정적 테스팅은 코드 실행에 의존하지 않는 품질 특성을 측정하는 데 사용할 수 있는 반면, 동적 테스팅은 코드 실행에 의존적인 품질 특성(예: 성능 효율성)을 측정하는 데 사용할 수 있다.

정적 테스팅을 통해 더 쉽게 적은 비용으로 식별할 수 있는 대표적인 결함은 다음과 같다.

  • 요구사항 결함
  • 설계 결함
  • 특정 유형의 코딩 결함
  • 표준 위반
  • 잘못된 인터페이스 명세
  • 특정 유형의 보안 취약성
  • 테스트 베이시스 커버리지의 차이 또는 부정확성

3.2 피드백과 리뷰 프로세스

3.2.1 이해관계자가 피드백을 조기에 자주 받을 때의 이점

피드백을 조기에 자주 받으면 잠재적인 품질 문제를 조기에 파악할 수 있다. SDLC 전반에 걸쳐 이해관계자의 피드백을 자주 받으면 요구사항에 대한 오해를 방지하고 요구사항 변경을 조기에 이해하고 구현할 수 있다.

3.2.2 리뷰 프로세스 활동

ISO/IEC 20246 표준은 특정 상황에 맞게 리뷰 프로세스를 조정할 수 있는 체계적이면서 유연한 프레임워크를 제공하는 보편적인 리뷰 프로세스를 정의한다. 필요한 리뷰가 공식적일수록 각 활동에 대해 설명된 작업 중 수행할 것이 더 많아지게 된다.

작업 산출물이 너무 커서 한 번의 리뷰로 다룰 수 없는 경우도 많다. 전체 작업 산출물의 리뷰를 끝내기 위해 리뷰 프로세스를 여러 번 수행할 수 있다.

리뷰 프로세스에 포함되는 활동은 다음과 같다.

  1. 계획
  2. 리뷰 착수
  3. 개별 리뷰
  4. 논의 및 분석
  5. 수정 및 보고

3.2.3 리뷰에서의 역할과 책임

리뷰에는 다양한 이해관계자가 참여하며 한 명이 여러 역할을 동시에 맡을 수 있다. 주요 역할과 책임은 다음과 같다.

  • 관리자
  • 저자
  • 중재자 (퍼실리테이터라고도 함)
  • 서기 (기록자라고도 함)
  • 리뷰어 (검토자)
  • 리뷰 리더

※ 기타 더 세부적인 역할도 있으며, 관련해서는 ISO/IEC 20246 표준에서 설명하고 있다.

3.2.4 리뷰 유형

비공식 리뷰부터 공식 리뷰까지 다양한 리뷰 유형이 있다. 처음에는 비공식적으로 리뷰하고 나중에 보다 공식적으로 리뷰하는 등, 같은 작업 산출물도 여러 형태로 리뷰할 수 있다.

많이 사용하는 몇 가지 리뷰 유형은 다음과 같다.

  • 비공식 리뷰: 정의된 프로세스를 따르지 않으며 공식적인 결과 문서도 요구하지 않는다. 주요 목적은 이상 사항을 식별하는 것이다.
  • 워크쓰루: 리뷰어는 워크쓰루 전에 개별 리뷰를 수행할 수도 있지만 반드시 해야 하는 것은 아니다.
  • 기술 리뷰: 기술적인 자격을 갖춘 리뷰어가 수행하고 중재자가 리더가 된다.
  • 인스펙션: 가장 공식적인 리뷰 유형으로 보편적 프로세스(3.2.2 참조)를 철저히 따라야 한다. 주요 목적은 이상 사항을 최대한 많이 찾는 것이다. 메트릭을 수집해 리뷰 프로세스를 포함한 전체 SDLC를 개선하는 데 사용한다.

3.2.5 리뷰의 성공

리뷰의 성공 여부를 결정하는 요소에는 다음과 같은 것들이 있다.

  • 명확한 목표와 측정 가능한 완료 조건을 정의한다. 참가자의 평가가 목적이 되어서는 절대 안 된다.
  • 주어진 목표를 달성할 수 있으면서 작업 산출물 유형, 리뷰 참여자, 프로젝트 요구사항 및 정황에 맞는 리뷰 유형을 선택한다.
  • 리뷰어가 개별 리뷰 또는 리뷰 회의에서 집중력을 잃지 않도록 작은 단위로 리뷰를 진행한다.
  • 이해관계자와 저자에게 리뷰 피드백을 제공해 제품 및 활동을 개선할 수 있게 한다.
  • 참가자가 리뷰를 준비할 수 있는 충분한 시간을 제공한다.
  • 관리층의 지원을 받는다.
  • 학습 및 프로세스 개선 촉진을 위해 리뷰가 조직 문화의 일부가 되도록 한다.
  • 모든 참가자가 자신의 역할을 어떻게 충족해야 하는지 알 수 있도록 적절한 교육을 제공한다.
  • 회의에 퍼실리테이션(facilitation) 을 적용한다.

참고

ISTQB 공식 Syllabus