STQB_CTFL 3. 정적 테스팅

서론

    정적 기법인 리뷰에 대한 일반적이지만 중요하다. 정적 테스팅 경험자들은 기대 이상의 정적 테스팅 효과에 만족하며 정적 테스팅의 중요성과 가치를 높게 평가한다. 이번 3장의 학습 목표는 "정적 기법과 테스트 프로세스가 무엇인지 알고 정적과 동적 테스팅의 차이를 구별할 수 있다. 리뷰 프로세스와 도구에 의한 정적 분석에 대해 설명할 수 있어야 한다."이다. 이를 기억하고 내용을 이해해 보자.

---

배우기에 앞서 용어 정리

    용어를 확실하게 아는 것이 이해에 도움이 된다. ISTQB가 개발자뿐만 아니라 다른 직군도 시험을 충분히 볼 수 있기에 이해하기 쉽게 용어의 정의를 살펴보자.

• 정적 테스팅: 리뷰 또는 정적 코드 분석과 같이 소프트웨어의 실행 없이 명세 또는 구현, 개발 단계에서 컴포넌트나 시스템을 테스팅하는 것.
• 동적 테스팅: 컴포넌트나 시스템 소프트웨어를 실행하면서 수행하는 테스팅.
• 리뷰(review): 계획되어 있는 결과와 불일치하는 것을 확인하고 개선을 조언하기 위해 제품이나 프로젝트의 상태를 평가하는 것.
• 공식 리뷰(formal review): 경영 측 또는 대리자를 통해 소프트웨어 획득, 공급, 개발, 운영, 도는 유지보수 프로세스를 체계적으로 평가하는 것.
• 비공식 리뷰(informal review): 공식적인 절차를 따르지 않는 리뷰
• 인스펙션(inspection): 개발 표준 위반과 상위 레벨 개발 문서와의 불일치 등과 같은 결함을 발견하기 위해 문서를 눈으로 검사하는 리뷰의 한 종류.
• 워크스루(walkthrough): 개발 산출물을 작성하는 중에 산출물을 검토하고 결함을 찾아내는 기법
• 애드혹 리뷰(ad hoc review): 비공식 리뷰의 일종
• 인시던트(incident): 테스팅 중 발생하여 조사가 요구되는 모든 이벤트.

---

정적 테스팅

    테스트하고 있는 소프트웨어의 실행이 필요한 동적 테스팅과는 달리 정적 테스팅은 작업 산출물을 수동으로 검사하거나 코드나 다른 작업 산출물을 도구를 기반으로 평가(tool-driven evaluation)하는 방법에 의존한다. 두 가지 유형의 정적 테스팅 모두 테스트 중인 코드 또는 작업 산출물을 실제로 실행하지 않고 평가한다.

   정적 분석은 안전 최우선 컴퓨터 시스템에서 중요하지만 다른 영역에서도 점차 그 중요성이 일반화되고 있다. 예를 들어, 보안 테스팅에서 정적 분석은 중요한 부분이며, 또한 애자일 개발, 지속적 인도(continuous delivery), 지속적 배포(continuous deployment) 등과 같은 자동화된 소프트웨어 빌드나 배포 도구(distribution tools)에 통합되는 경우가 많다.

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

    대부분의 작업 산출물은 정적 테스팅(리뷰나 정적 분석)으로 검사할 수 있다.

• 비즈니스 요구사항, 기능 요구사항, 보안 요구사항과 같은 명세
• 에픽(epic), 사용자 스토리, 인수 기준
• 아키텍처 및 설계 명세
• 코드
• 테스트 계획, 테스트 케이스, 테스트 프로시저, 자동화 테스트 스크립트와 같은 테스트웨어
• 사용자 가이드
• 웹 페이지
• 계약, 프로젝트 계획, 일정, 예산 기획
• 형상(configuration) 및 인프라(infrastructure) 셋업
• 액티비티 다이어그램과 같은 모델 기반 테스팅에 사용되는 모델

    정적 분석은 적절한 정적 분석 도구가 존재하는 공식 구조를 사용하는 작업 산출물(일반적으로 코드 또는 모델)에 효율적으로 적용할 수 있다. 정적 분석은 요구사항과 같은 자연어로 작성된 작업 산출물을 평가하는 도구로 적용할 수도 있다.

정적 테스팅의 효과

    정적 테스팅 기법은 여러 이점이 있다. 정적 테스팅을 소프트웨어 개발 수명주기 초반에 적용하면 동적 테스팅을 실행하기 전 결함의 조기 발견을 가능하게 한다. 개발 초기에 발견한 결함을 제거하는 데 드는 비용은 수명주기 후반에 발견한 결함을 제거하는 비용에 비해 훨씬 적게 들며, 특히 소프트웨어를 배포하고 실제 사용하는 단계와 비교하면 더 현저하다. 정적 테스팅 기법을 사용해 결함을 발견하고 바로 수정하는 것이 동적 테스팅으로 결함을 발견하고 수정하는 것에 비해 적은 비용이 드는 경우가 대부분이다. 특히, 작업 산출물의 업데이트와 확인, 리그레션 테스팅 수행과 관련된 추가 비용을 고려하면 이는 더 명확해진다.

    그 외 정적 테스팅의 효과에는 다음과 같은 것들이 있다.

• 동적 테스트 실행 전에 보다 효율적으로 결함을 발견하고 수정
• 동적 테스팅으로 발견이 쉽지 않은 결함 식별
• 설계나 코딩의 결함 예방
• 개발 생산성 향상
• 개발 비용 및 기간 단축
• 테스팅 비용 및 기간 단축
• 소프트웨어 수명주기 전반에 걸친 총 품질 비용 감소
• 리뷰에 참여하는 팀원 간의 의사소통 개선

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

     정적 테스팅과 동적 테스팅의 공통 목적은 작업 산출물의 품질을 평가하고 가능한 한 빨리 결함을 식별하는 것이다. 정적 테스팅과 동적 테스팅은 발견하는 유형의 결함이 서로 달라 상호 보완적이다.

     가장 중요한 차이점 중 하나는 정적 테스팅은 소프트웨어를 실행해 결함으로 발생하는 장애를 찾아내기보다는 작업 산출물에서 직접 결함을 발견한다는 것이다. 결함은 장애를 일으키지 않고 작업 산출물에 상당히 오랜 기간 숨어 있을 수 있다. 결함이 존재하는 경로가 드물게 실행되거나 접근하기 어려워 이런 경로에 도달하는 동적 테스트를 구축하고 실행하는 것은 쉽지 않다. 반면 정적 테스팅은 훨씬 적은 노력으로 결함을 발견할 수 있다.

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

    동적 테스팅과 비교해 정적 테스팅으로 발견하기 쉽고 비용도 적게 들어가는 일반적인 결함 유형은 다음과 같다.

• 요구사항 결함
• 설계 결함
• 코딩 결함
• 표준과의 차이
• 잘못된 인터페이스 명세
• 보안 취약점
• 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성
• 불충분한 유지보수성

  또한 대부분의 유지보수성 결함은 정적 테스팅으로만 발견할 수 있다.

리뷰와 테스팅

   최근에는 결함을 일찍 발견하여 테스팅 비용과 전체 개발 프로젝트 비용을 줄이기 위한 다각적인 시도가 이뤄지고 있다. 그동안 시트템/인수 테스팅에 비해 테스팅 관점에서 상대적으로 중요시하지 않았던, 개발 단계에서의 하위 레벨 테스트의 강조도 이러한 추세를 반영한 것이다. 여기서 더 나아가 최근 테스팅이 결함 예방 차원의 활동으로 강조되는 경향이 있는 데, 개발 산출물을 테스트하는 정적 기법이 결함 예방을 위한 테스팅의 중심을 이룬다. 이와 같이 개발 프로젝트 초기에 결함을 줄이는 활동은 테스팅 관점에서 조기 테스트 설계(Early Test Design)와 직접적으로 연계되어 있다.

    잘못 설계된 문서와 같이 결함이 있는 문서로 인해 요구사항과 어긋난 방향으로 제품을 개발할 수 있는데, 나중에 이를 바로 잡기 위해서는 다량의 재작업이 발생하고 결과적으로 상당한 노력과 비용을 부가적으로 투입해야 한다. 조기 테스트 설계를 통해 코딩을 시작하기 전에 요구사항 문서와 설계 기준서 등에서 테스트 케이스를 만들 수 있으며, 이 과정에서 개발 문서상의 결함을 발견할 수 있다. 이뿐만 아니라 개발 프로젝트가 잘못된 방향으로 진행될 가능성을 코딩 작업 전에 최소화할 수 있다.

   그러나 시스템 명세는 그 내용이 자주 변경될 소지가 있으므로, 프로젝트 초기에 모든 테스트 케이스를 생성해 놓는 것은 현명치 못한 방법일 수 있다. 명세가 변경되면 관련된 테스트 케이스를 모두 수정 및 업데이트해야 하며, 상황에 따라서는 이미 만들어 놓은 테스트 케이스를 유지 보수하는 시간이 새로 테스트 케이스를 작성하는 시간보다 더 소요될 수 있다. 이 경우, 리스크가 높거나 중요한 기능(핵심 모듈)에 한해서 테스트 케이스를 도출하면서 문서를 테스트할 수 있다. 추후에 요구사항이 변경되어 미리 도출한 테스트 케이스를 사용하지 못하더라도, 리스크가 높은 부분에 대해 결함을 조기에 발견하는 활동은 매우 의미가 높고 중요하다.

---

리뷰 프로세스

    리뷰 방식은 리뷰를 통해 달성하고자 하는 합의된 목적에 맞는 형태를 취하게 된다. 여기서 리뷰를 통해 달성학하고자 하는 목적은 결함 발견, 이해도 증진, 합의에 의한 결정과 이에 도달하기 위한 토론 등이고, 각각의 목적에 맞는 리뷰 방식과 형식을 따르도록 한다.

    리뷰 유형은 공식 리뷰에서 비공식 리뷰까지 다양하다. 비공식 리뷰의 특징은 정의된 프로세스를 따르지 않고, 리뷰 결과를 공식적으로 문서화하여 제공하지 않는다는 점이다. 공식 리뷰의 특징은 팀 참여, 문서화된 리뷰 결과, 문서화된 리뷰 진행 절차 등이 있다. 리뷰 프로세스의 형식은 소프트웨어 개발 수명주기 모델, 개발 프로세스의 성숙도, 리뷰 대상 작업 산출물의 복잡도, 다양한 법적 또는 규정 요구사항이나 감사 추정의 필요성과 같은 요소와 관련이 있다.

   리뷰는 얼핏 보기에 단순한 검토에 불과한 것 처럼 보여 시간/비용 투자 대비 효과가 있을까 의심을 가질 수 있다. 자격을 갖춘 리뷰 미팅 리더와 능력 있는 검토자 없이 , 절차를 준수하지 않으면서, 적절하지 못한 리뷰 형식과 인원 구성으로 리뷰를 진행하면 그 효과를 기대하기 어렵고, 오히려 역효과로 비용과 개발 기간이 늘어나는 경우가 많다. 그러나 이와 반대로 체계적인 리뷰를 진행한다면 고품질 소프트웨어 개발과 비용 절감은 물론 개발 기간 단축이라는 효과를 이루어질 수 있다.

    리뷰의 성과를 객관화하고 체계화하여 정리한 일례가 페이건 익스펙션이다. 인스펙션을 도입할 경우 코딩 전까지는 소요 인력이 인스펙션이 없을 때보다 2배 정도 필요하며 초기 프로젝트 비용이 증가하지만, 성공적인 인스펙션 결과 코딩 단계에서의 재작업과 투입 인력이 줄게 되어 품질 비용이 감소하고 개발 기간을 단축할 수 있다.

리뷰 프로세스

    프로젝트 전반의 리뷰 활동에 대한 계획은 테스트 프로세스의 테스트 계획 단계에 수립되어 테스트 계획서에 해당 내용이 명시되어야 한다. 정적 테스트 프로세스는 크게 정적 테스트 준비 단계, 리뷰/분석 단계, 후속 처리 확인 단계의 3단계로 구성된다. 각 단계별로 세부 내용은 아래의 공식 리뷰 절차와 크게 다르지 않다.

    리뷰를 성공적으로 진행하기 위해서는 절차를 준수해야 한다. 비공식적인 리뷰의 경우, 절차의 많은 부분을 생략할 수 있지만, 기본적인 골격을 이루는 절차는 따르는 것이 좋다. 특히, 계획 활동과 개별 준비, 후속 처리 확인은 리뷰 미팅을 진행하면서 강제화하여도 좋은 전략이다.

    공식 리뷰 프로세스의 주요 활동은 다음과 같다.

• 계획 (Planning)
  • 리뷰 목적, 리뷰할 문서가 전체인지 특정 부분인지, 평가할 품질 특성 등을 포함하는 범위의 정의
  • 노력과 기간 추정
  • 리뷰 유형에 따라 결정되는 역할, 활동, 체크리스트와 같은 리뷰 특성의 식별
  • 리뷰에 참석할 인원을 선정하고 역할 할당
  • 인스펙션과 같은 보다 공식적인 리뷰의 경우에는 시작 및 종료 조건 정의
  • (공식적인 리뷰 유형의 경우) 시작 조건이 충족되는지 확인
• 리뷰 착수 (Initiate review, 시작)
  • 작업 산출물과 이슈 기록(issue log) 양식, 체크리스트, 관련된 작업 산출물과 같은 기타 자료 배포
  • 참가자에게 범위, 목적, 프로세스, 역할, 작업 산출물을 설명
  • 참가자가 리뷰에 대해 가질 수 있는 여러 질문에 답변
  • (공식적인 리뷰 유형의 경우) 시작 기준을 점검한다.
• 개별 리뷰 (Individual review, 개별 준비)
  • 작업 산출물 전체 혹은 부분 리뷰
  • 잠재 결함, 권고사항, 질문 기록
• 이슈 논의 및 분석 (Issue communication and analysis, 리뷰 미팅)
  • 식별한 잠재 결함 전달
  • 잠재 결함 분석 및 담당자 및 상태 할당
  • 품질 특성 평가 및 문서화
  • 종료 조건을 기준으로 리뷰 결과를 평가하여 리뷰 결과 결정
• 수정 및 보고 (Fixing and reporting, 재작업, 후속 처리)
  • 작업 산출물에 대한 수정을 요하는 잠재 결함에 대한 결함 보고서 작성
  • 리뷰한 작업 산출물에서 발견한 결함 수정 (일반적으로 저자가 수정)
  • 결함 정보를 적절한 사람이나 팀과 공유 (리뷰한 작업 산출물과 연관된 다른 작업 산출물이 있는 경우)
  • 필요한 경우 주석 작성자(comment originator)의 동의를 포함해 (공식적인 리뷰 유형인 경우) 업데이트 된 결함 상태 기록
  • 메트릭 수집 (공식적인 리뷰 유형인 경우)
  • 종료 조건의 충족여부 확인 (공식적인 리뷰 유형인 경우)
  • 종료 조건이 충족되면 해당 작업 산출물 인수

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

    일반적으로 공식 리뷰에는 다음과 같은 역할이 포함된다.

• 저자 (Author)
  • 리뷰 대상 작업 산출물 작성
  • 리뷰 대상 작업 산출물 결함 수정 (필요한 경우)
• 관리자 (Management)
  • 리뷰 계획 담당
  • 리뷰 실행 결정
  • 프로젝트 인력, 예산, 시간 할당
  • 진행 비용 대비 효과 모니터링
  • 리뷰 목적 달성 여부 확인 및 승인
  • 결과가 만족스럽지 않은 경우 제어 결정(control decisions) 실행
• 촉진자 (Facilitator, 중재자(moderator))
  • 문서의 리뷰 리드
  • 리뷰 회의 진행 시 효과적 회의 진행 보장
  • 필요한 경우 다양한 관점들에 대한 중재
  • 많은 경우 리뷰의 성공 여부에 결정적인 역할을 하는 사람 (리뷰의 성패를 좌우함)
• 리뷰 리더 (Review leader)
  • 전반적으로 리뷰에 대한 책임을 지는 사람
  • 참여자를 결정하고 언제 어디서 진행할지 결정
• 검토자 (Reviewers)
  • 해당 주제에 대한 전문가, 프로젝트 참여 인원, 작업 산출물에 관심이 있는 이해관계자나 특정 기술 혹은 비즈니스 배경을 가진 사람 등
  • 리뷰 대상 작업 산출물의 잠재적 결함(인시던트) 식별
  • 다양한 관점을 대표할 수 있음
• 서기 (Scribe, 기록자 (Recorder))
  • 개별 리뷰 활동에서 발견한 잠재 결함 수집
  • 리뷰 회의가 진행되는 경우 새로운 잠재 결함, 쟁점, 결정 사항 기록

    리뷰 유형에 따라 한 사람이 두 개 이상의 역할을 수행할 수 있으며, 각 역할과 관련된 활동 역시 리뷰 유형에 따라 달라질 수 있다. 또한, 리뷰 프로세스를 지원하는 도구, 특히, 결함, 쟁점 및 의사 결정의 기록을 지원하는 도구로 인해 서기가 필요하지 않은 경우가 많다. 다른 관점에서 문서를 살펴보는 것과 체크리스트를 이용하는 것은 리뷰를 좀 더 효과적이고 효율적이게 한다.

    테스트 전문가는 일반적으로 검토자로서 리뷰에 참여하게 된다. 이때, 테스트 전문가는 다른 검토자들과 달리 테스팅 관점에서 발견한 결함과 검토 의견을 가지고 리뷰에 참여한다. 즉, 리뷰 대상을 테스트 케이스로 만들면서 발견한 '다른 종류'의 결함을 가지고 리뷰에 기여한다. 테스트 전문가는 다른 참여자들이 찾는 결함과는 다른 종류의 결함을 발견하면서 향후 테스팅에서 사용할 테스트 케이스를 간접적으로 검토받고 원활한 테스트 수행을 위한 준비를 하게 한다.

    테스트 전문가는 리뷰 과정에 지속적으로 참여해온 경우, 테스팅 단계에 이르면 이미 준비된 테스트 케이스로 테스트를 실행하여 단기간에 테스팅을 진행할 수 있다. 이때 변수는 개발 기간 동안 변경되는 요구사항과 설계를 반영하기 위해 이미 개발해 놓은 테스트 케이스를 지속적으로 업데이트해주어야 하는데, 여기서 소요되는 시간과 노력이 많을 수 있다.

리뷰 유형

     리뷰를 다양한 목적으로 활용할 수 있지만, 주된 목적 중 하나는 결함 발견이다. 모든 리뷰 유형은 결함 발견에 도움이 될 수 있으며, 프로젝트 요구사항, 가용 자원, 제품 유형과 리스크, 비즈니스 도메인, 조직의 문화 등에 따라 적절한 리뷰 유형을 선택해야 한다.

    단일 작업 산출물은 여러 유형의 리뷰 대상이 될 수 있다. 하나 이상의 리뷰 유형이 사용된 경우에는 그 순서도 다양할 수 있다. 예를 들어, 비공식 리뷰는 작업 산출물이 기술 리뷰를 위해 준비되었는지 확인하기 위해 기술 리뷰 전에 수행될 수 있다.

    아래에 설명되어 있는 리뷰 유형은 동료 리뷰(peer reviews), 즉 동일한 작업의 수행 능력이 있는 동료가 수행할 수 있다.

    리뷰에서 발견되는 결함 유형은 특히 리뷰 중인 작업 산출물에 따라 다르다. 리뷰는 다양한 특성에 따라 분류될 수 있다. 다음은 가장 일반적인 4 가지 리뷰 유형과 각각의 특성을 나열한 것이다

• 비공식 리뷰 (Informal review)
  • 주요 목적: 잠재적 결함 발견, 저렴한 방법으로 일정 수준의 성과 달성
  • 기타 목적: 새로운 아이디어나 해결책 도출, 소소한 문제의 빠른 해결
  • 공식 (문서화된) 프로세스를 기반으로 하지 않음
  • 리뷰 회의를 진행하지 않을 수 있음
  • 저자의 동료 (버디 체크) 또는 다른 사람이 수행할 수 있음
  • 결과는 문서로 기록할 수 있음
  • 선택적으로 문서화될 수 있음
  • 검토자에 따라 성과가 달라짐
  • 체크리스트 사용 여부는 상황에 맞게 판단
  • 애자일 개발에서 매우 일반적으로 사용됨
  • 리뷰하는 사람에 따라 성과가 좌우됨
  • 예: 버디 체크 (buddy check), 페어링 (pairing), 짝 리뷰 (pair review)
• 워크쓰루 (Walkthrough)
  • 주요 목적: 결함 발견, 소프트웨어 제품 개선, 다른 구현 방법 고려, 표준이나 규정 준수 평가, 시스템에 대한 이해 향상
  • 기타 목적: 다양한 기술이나 스타일에 대한 아이디어 교환, 참여자 교육, 합의 도출
  • 리뷰 회의 전 개별 준비는 필요에 따라 수행
  • 리뷰 회의는 일반적으로 작업 산출물의 저자가 주도
  • 서기 참여 필수
  • 체크리스트 사용 여부는 상황에 맞게 판단
  • 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있는(Open-ended) 세션
  • 동료 검토(Peer review)
  • 시나리오, 예행 연습(dry run), 동료 그룹 검토의 형태로 수행할 수 있음
  • 잠재 결함 로그와 리뷰 보고서 작성
  • 실무에서는 비공식적인 형식에서 매우 공식적인 형식까지 다양할 수 있음
• 기술 리뷰 (Technical review)
  • 주요 목적: 합의 도출, 잠재적 결함 발견, 기술적 문제 해결, 표준과의 적합성 검토
  • 기타 목적: 작업 산출물의 품질 평가 및 자신감 획득, 새로운 아이디어 도출, 저자가 미래의 작업 산출물을 개선하도록 지원하고 동기를 부여, 다른 구현 방법 고려
  • 검토자는 저자의 기술 동료이면서, 동일 분야 또는 다른 분야의 기술 전문가여야 함
  • 동료 검토
  • 결함 발견을 위한 문서화되고 정의된 프로세스가 존재함
  • 리뷰 회의 전 개별 준비 필요
  • 리뷰 회의는 선택 사항이며, 이상적으로는 훈련된 촉진자(일반적으로 저자가 아닌)가 주도
  • 서기는 반드시 있어야 하며, 이상적으로는 저자가 아닌 사람이 수행
  • 체크리스트 사용 여부는 상황에 맞게 판단
  • 잠재 결함 로그와 리뷰 보고서 작성
  • (성공적으로 진행되는 경우) 검토자에 관계없이 일관되고 정량적인 효과 도출 가능
  • 실무에서는 공식적 또는 비공식적일 수 있음
• 인스펙션 (Inspection)
  • 주요 목적: 잠재적 결함 발견, 작업 산출물의 품질 평가 및 자신감 획득, 저자 학습과 근본 원인 분석을 통한 유사 결함의 발생 예방
  • 기타 목적: 저자가 앞으로의 작업 산출물과 소프트웨어 개발 프로세스를 개선하고 합의를 이끌어 내도록 동기를 부여
  • 규칙 및 체크리스틀 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행
  • 주로 동료 검사(동료 검토)
  • 역할이 지정되어 있음
  • 리뷰 역할 참여, 낭독자(리뷰 회의 중 작업 산출물을 종종 자신의 말로 의역하고 소리 내어 읽는 사람)의 참여 가능
  • 리뷰 회의 전 개별 준비 필요
  • 검토자는 저자의 동료 또는 작업 산출물과 연관된 분야의 전문가
  • 명시된 시작 및 종료 조건을 사용
  • 서기 참여 필수
  • 리뷰 회의는 훈련받은 촉진자(저자가 아닌 사람)가 주도
  • 저자는 리뷰 리더, 글을 읽는 사람 또는 서기가 될 수 없음
  • 잠재적인 결함 로그 및 리뷰 보고서 작성
  • 인스펙션 리포트와 발견사항(인시던트) 리스트 산출
  • 정상적인 후속 처리 확인(Follow up) 프로세스가 존재
  • 인스펙션 프로세스 포함 전체 소프트웨어 개발 프로세스를 개선하기 위해 메트릭을 수집하고 사용

    인스펙션 프로세스는 일반적으로 공식적인 리뷰 프로세스를 따르며, 프로세스 개선 단계가 인스펙션 미팅과 재작업 사이에 존재한다. 공식적인 리뷰에서는 일반적인 역할과 책임은 인스펙션에도 그대로 적용되며, 특징적인 것은 검토자와는 별도로 테스터의 역할을 두고 있다.

    리뷰는 "리스크 기반 테스트 전략"과 다른 시각에서 연계할 수 있다. 사업적 리스크가 높은 영역에서는 요구사항과 관련된 사용자 및 고객과 의사 소통해야 하므로, 이들에게 친숙하고 시간 및 인원수 등에 제한이 없는 워크 쓰루가 효과적이다. 한편, 제품의 기술적인 리스크가 높은 영역에서는 기술적 문제 해결이 중요한 목적인 기술적 리뷰나 인스펙션이 적절하다. 위 그림은 리스크 영역 별로 가장 적절한 리뷰 형식을 나타낸 것이다. 이와 같이 유형에 따라 리스크를 반영하여 전략적을 적용하면 리뷰의 효과를 높일 수 있다. 단, 리스크 메트릭스에 명시된 리뷰의 유형 이외에도 상황에 따라 다양한 형태의 리뷰를 단독으로 함께 사용할 수 있다.

리뷰 기법 적용

    개별 리뷰(개별 준비) 활동 중에 결함을 발견하기 위해 사용할 수 있는 리뷰 기법에는 여러 가지가 있다. 이런 기법은 위에서 설명한 모든 리뷰 유형에서 사용할 수 있다. 각 기법이 얼마나 효과적인지는 사용하는 리뷰 유형에 따라 달라질 수 있다. 여러 리뷰 유형에서 사용하는 개별 리뷰 기법들은 다음과 같다.

• 애드혹 (Ad hoc)
• 체크리스트 기반 (Checklist based)
• 시나리오 및 드라이 런 (Scenarios and dry runs)
• 관점 기반 (Perspective-based)
• 역할 기반 (Role-based)

애드혹

    애드혹 리뷰에서는 검토자에게 리뷰 수행 방법에 대한 안내가 거의 또는 전혀 제공되지 않는다. 검토자는 대부분의 경우 작업 산출물을 순차적으로 읽으면서 이슈를 식별하고 기록한다. 애드혹 리뷰는 특별한 준비 없이 일반적으로 사용되는 기법이다. 이 기법은 검토자의 능력에 크게 의존하며, 여러 검토자가 동일한 문제를 보고할 수 있다

체크리스트 기반

    체크리스트 기반 리뷰는 체계적인 기법으로, 검토자는 리뷰 시작 시점에 배포된 체크리스트를 기반으로 이슈를 식별한다. 리뷰 체크리스트는 잠재 결함을 식별하기 위해 경험에서 도출한 일련의 질문으로 구성된다. 체크리스트는 리뷰 대상 작업 산출물 유형별로 작성해야 하며 이전 리뷰에서 누락된 이슈 유형을 다루기 위해 주기적으로 개선할 필요가 있다. 체크리스트 기반 기법의 주요 장점은 일반적인 결함 유형에 대한 체계적인 커버리지를 갖는다는 점이다. 개별 리뷰를 수행할 때 검토자는 체크리스트를 단순히 실행하는 것뿐만 아니라, 체크리스트로 식별할 수 없는 결함도 찾기 위해 특별히 주의를 기울여야만 한다

시나리오 및 드라이 런

    시나리오 기반 리뷰에서 검토자는 작업 산출물을 어떻게 검토할지에 대한 구조화된 지침을 제공받는다. 시나리오 기반 리뷰는 (작업 산출물이 유스케이스와 같은 적절한 형식으로 문서화된 경우) 작업 산출물의 예상되는 용도를 기반으로 작업 산출물에 대해 “드라이런”(모의실험)을 수행할 수 있도록 검토자를 지원한다. 이러한 시나리오는 검토자에게 단순한 체크리스트 항목보다 특정 결함 유형을 식별하는 방법에 대한 좀 더 나은 지침을 제공한다. 체크리스트 기반 리뷰와 마찬가지로, 다른 결함 유형을 발견하기 위해 검토자는 기록된 시나리오에만 너무 얽매이지 않아야 한다.

관점 기반

    관점 기반 읽기(perspective-based reading)는 역할 기반 리뷰와 마찬가지로 검토자가 개별 리뷰 중 다양한 이해관계자의 관점을 사용하게 된다. 일반적으로 사용되는 이해관계자 관점에는 최종 사용자, 영업, 설계자, 테스터, 운영자 등이 있다. 서로 다른 이해관계자 관점을 사용하면, 검토자 간에 중복되는 이슈가 줄어들고 개별리뷰가 좀 더 깊이 있게 진행된다.

    또한, 관점 기반 읽기에서는 검토자가 리뷰 대상 작업 산출물로부터 이해관계자의 관점을 기반으로 하는 산출물을 작성해야 한다. 예를 들어, 테스터가 필요한 모든 정보가 존재하는지 확인하기 위해 요구사항 명세에 대한 관점 기반 읽기를 수행하면서 인수 테스트 초안을 작성을 시도할 수 있다. 또한 관점 기반 읽기에서는 체크리스트도 활용한다.

    실증적인 연구에 의하면, 관점 기반 읽기가 요구사항 및 기술 작업 산출물에 대한 리뷰에 가장 효과적인 기법이다. 주요 성공 요인은 리스크를 기반으로 다양한 이해관계자의 관점을 적절하게 포함시키고 평가하는 것이다.

역할 기반

    역할 기반 리뷰는 검토자가 작업 산출물을 개별 이해관계자 역할의 관점에서 평가하는 기법이다. 일반적인 역할에는 특정 최종 사용자 유형(경험 많은, 경험 적은, 노인, 아동 등)과 조직 내 특정 역할(사용자 관리자, 시스템 관리자, 성능 테스터 등)이 있다. 역할이 비슷하기 때문에 같은 원칙이 관점 기반 읽기에도 적용된다.

리뷰의 성공 요소

    성공적인 리뷰를 위해서는 적절한 리뷰 유형과 기법을 고려해야 한다. 또한, 리뷰의 결과에 영향을 주는 여러 가지 다른 요인도 있다.

  조직 차원의 성공 요인은 다음과 같다.

• 각 리뷰는 명확한 목적이 있어야 한다. 목적은 리뷰 계획 시 정의하며, 측정 가능한 종료 조건으로 사용된다.
• 목적을 달성하기에 적합하고, 소프트웨어 작업 산출물 및 참여자 유형 수준에 맞는 리뷰 유형을 적용해야 한다.
• 체크리스트 기반 및 역할 기반 리뷰와 같이 사용하는 모든 리뷰 기법은 리뷰 대상 작업 산출물의 결함을 효과적으로 식별하기에 적합해야 한다.
• 용하는 체크리스트는 주요 리스크 식별을 위해 작성해야 하며, 가장 최신의 정보를 반영해야 한다.
• 규모가 큰 문서는 작은 단위로 작성하고 리뷰를 수행해 저자에게 결함에 대한 피드백을 조기에 그리고 빈번하게 제공함으로써 품질 관리를 수행한다.
• 참여자는 충분한 준비 시간을 갖는다.
• 충분한 여유를 가지고 리뷰 일정을 수립한다.
• 경영진은 리뷰 프로세스를 지원한다.
• 리뷰는 기업의 품질 및 테스트 정책에 통합된다.
• 소프트웨어 개발 산출물과 검토자의 수준과 타입을 고려하여 리뷰 기법을 적절히 적용해야 한다.
• 리뷰 기법에 대한 교육 훈련 제공해야 한다. 특히, 인스펙션과 같이 보다 공식적인 기법에 대해서는 교육 훈련 제공이 필수적이다.

   사람과 관련된 성공 요인은 다음과 같다.

• 리뷰 목적 달성을 위해 적절한 사람들이 참여한다.
• 테스터는 리뷰에 기여하는 중요한 검토자로 간주된다. 테스터는 작업 산출물의 학습을 통해 좀 더 효과적인 테스트를 준비하고 조기에 테스트 준비를 할 수 있게 된다.
• 참여자는 세부사항에 충분한 시간과 주의를 기울여야 한다.
• 작은 단위로 리뷰를 진행해 개별 리뷰나 리뷰 회의(개최된다면) 중에 검토자가 집중력을 잃지 않도록 해야 한다.
• 식별된 결함은 승인하고 평가하고, 객관적으로 처리해야 한다.
• 리뷰 회의를 잘 관리해 참여자가 리뷰에 참여한 시간이 가치 있다고 인식하게 해야 한다.
• 리뷰는 모든 참여자가 서로 신뢰하는 분위기에서 진행해야 한다. 리뷰 결과를 가지고 참여자들을 평가해서는 안 된다.
• 참여자는 지루함, 분노 또는 다른 참여자에 대한 적대감을 나타낼 수 있는 신체 언어 및 행동을 피해야 한다.
• 적절한 교육을 제공한다. 특히 인스펙션과 같은 공식적인 리뷰 유형에는 더 필요하다.
• 학습 및 프로세스 개선에 대한 조직 문화를 촉진해야 한다.
• 사람관련 이슈와 심리적인 측면이 고려되어야 함. 즉, 코드 또는 문서의 저자가 리뷰를 통해 긍정적인 경험을 해야 지속적인 효과를 기대할 수 있음.
• 리뷰 경험과 효과를 내재화하여 지속적으로 적용하는 것이 필요하다.

    이 밖에도 성공적으로 리뷰를 진행하기 위해서는 참여자 수를 리뷰 경험과 조직의 특성을 고려하여  3~5명 정도로 제한하고, 모든 참여자가 기록을 습관화하고, 개별 준비를 성실하게 수행 하도목 유도하여야 한다. 이 밖에도 개발 산출물의 유형별로 체크리스트를 개발하고, 리뷰한 결과물을 다시  리뷰하는 것이 필요하다. 리뷰 프로세스의 개선을 위해 리뷰 수행 과정에서 리뷰의 효과성 및 효율성과 관련된 메트릭을 수집하고, 리뷰에 투입되는 노력에 대해 공식적으로 인정하는 것이 필요하다. 또한 인스펙션 프로세스의 안정화 및 효율적인 수행을 위한 자동화된 지원 도구를 활용하는 것이 좋다. 또한 개별 준비 양식과 리뷰 미팅에서 사용할 리뷰 양식을 사용하여 리뷰를 효율적이고 효과적으로 수행하고 메트릭을 체계적으로 수집하여야 한다. 경우에 따라서는 경험과 지식은 물론, 객관적인 시각과 인지도를 갖춘 외부 리뷰 전문가의 참여가 리뷰의 성패를 좌우할 수도 있다.

---

도구에 의한 정적 분석

   정적 분석의 목적은 소프트웨어의 소스코드와 모델에서 결함을 발견하는 것이다. 소프트웨어의 코드를 실행하여 수행하는 동적 테스팅에 비해, 정적 분석은 조사 대상 소프트웨어를 실제적으로 실행하지 않는 상태에서 도구의 지원으로 수행하는 것이다.

   정적 분석의 특징은 아래와 같다.

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

   정적 분석의 가치는 아래와 같다.

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

   정적 분석 도구를 통해 발견되는 전형적인 결함은 아래와 같다.

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

    정적 분석 도구는 정의된 규칙이나 코딩 표준을 준수하는지 확인하는 용도로 컴포넌트 테스팅과 통합 테스팅 동안에 주로 개발자에 의해 사용되고, 소프트웨어 모델링하는 동안에는 설계자에 의해 사용된다. 도구를 효과적으로 사용하기 위해서는 정적 분석 도구가 생성하는 대량의 경고 메시지를 적절히 관리하는 것이 필요하다.

---

주섬주섬

   공부 정리를 위한 블로그이며, "개발자도 알아야 할 소프트웨어 테스팅 실무 제3판"과 실라버스를 참고하였다.

참고

STEN