소프트웨어 리뷰

소프트웨어 리뷰 상세 설명

소프트웨어 개발 및 테스팅 프로세스에서 '리뷰(Review)'는 작업 산출물(문서, 코드 등)의 결함을 발견하고 개선 기회를 식별하기 위해 여러 사람이 모여 체계적으로 검토하는 정적 테스팅 기법의 핵심입니다.

리뷰 개요 (Overview of Reviews)

리뷰는 소프트웨어를 실행하지 않고 문서나 코드를 읽고 분석함으로써 결함을 조기에 발견하고 수정 비용을 절감하는 데 매우 효과적인 방법입니다. 또한, 참여자들 간의 의사소통과 지식 공유를 촉진하여 제품의 품질과 팀의 역량을 향상시키는 데 기여합니다.

리뷰는 공식적인 정도(formality level)에 따라 다양한 유형으로 나눌 수 있으며, 프로젝트의 목표, 위험 수준, 문화 등에 따라 적절한 유형을 선택하여 적용합니다.

다양한 리뷰 유형

1. 관리 리뷰 (Management Review)

• 목적: 프로젝트의 진행 상태, 계획, 리스크, 예산, 자원 등을 평가하고, 주요 결정(예: 다음 단계 진행 승인, 출시 결정)을 내리기 위해 수행됩니다. 작업 산출물의 기술적 내용보다는 프로젝트 관리 관점에 초점을 맞춥니다.
• 참여자: 프로젝트 관리자, 개발 팀 리더, 고객 대표, 고위 경영진 등 의사 결정 권한이 있는 관리자 및 이해관계자.
• 대상: 프로젝트 계획서, 진행 보고서, 위험 분석 보고서 등.
• 특징: 프로젝트 전반의 비즈니스 및 관리 측면을 검토합니다. 기술적인 세부 사항보다는 큰 그림과 주요 이슈에 집중합니다.

2. 기술 리뷰 (Technical Review)

• 목적: 특정 작업 산출물(요구사항 명세, 설계 문서, 코드 등)의 기술적인 측면을 전문가들이 검토하여 잠재적인 결함, 표준 위반, 기술적 문제점 등을 발견하고 대안을 논의합니다.
• 참여자: 해당 기술 분야의 전문가, 관련 이해관계자(선임 개발자, 설계자, 테스터 등).
• 대상: 기술 설계 문서, 코드, 테스트 계획서 등.
• 특징: 정의된 프로세스를 따르지만, 인스펙션만큼 엄격하거나 측정 중심적이지는 않을 수 있습니다. 주로 기술적인 정확성과 일관성을 검토합니다.

3. 인스펙션 (Inspection)

• 목적: 가장 공식적이고 체계적인 리뷰 기법으로, 정의된 규칙과 절차에 따라 작업 산출물의 결함을 효율적으로 식별하는 것을 목표로 합니다.
• 참여자 및 역할:
  • 진행자(Moderator): 인스펙션 프로세스를 주관하고 회의를 진행합니다.
  • 저자(Author): 검토 대상 작업 산출물을 만든 사람입니다.
  • 기록자(Recorder): 회의 중에 발견된 결함 및 기타 문제점을 기록합니다.
  • 읽는 사람(Reader): 작업 산출물을 요약하거나 특정 부분을 읽으면서 참여자들의 검토를 돕습니다.
  • 검사자(Inspector): 작업 산출물을 검토하고 결함을 발견합니다. 최소 한 명 이상의 검사자는 검토 대상 작업 산출물에 대한 전문 지식이 있어야 합니다.
• 프로세스:
  • 계획 (Planning): 인스펙션 대상, 범위, 참여자, 일정 등을 계획합니다.
  • 개요 (Overview): (선택 사항) 저자가 작업 산출물에 대해 간략히 설명합니다.
  • 준비 (Preparation): 각 검사자가 개별적으로 작업 산출물을 검토하고 잠재적 결함을 식별합니다.
  • 인스펙션 회의 (Inspection Meeting): 검사자들이 모여 발견된 결함을 보고하고 기록합니다. (결함 수정 방법 논의는 이 회의에서 하지 않는 것이 일반적입니다.)
  • 재작업 (Rework): 저자가 보고된 결함을 수정합니다.
  • 후속 조치 (Follow-up): 진행자 또는 다른 참여자가 결함이 올바르게 수정되었는지 확인하고, 필요한 경우 재 인스펙션을 수행합니다.
• 특징: 엄격한 프로세스, 명확한 역할 분담, 체크리스트 활용, 결함 데이터 수집 및 분석(측정 지향), 결함 수정에 초점.

4. 워크쓰루 (Walkthrough)

• 목적: 저자가 작업 산출물을 설명하고, 참여자들이 시스템의 기능 흐름이나 특정 시나리오를 이해하면서 잠재적인 결함을 발견하고 대안을 논의합니다. 시스템 이해도 향상에도 목적이 있습니다.
• 참여자: 저자, 동료 개발자, 테스터, 기타 이해관계자.
• 대상: 코드, 설계 문서, 명세서 등.
• 특징: 인스펙션보다 덜 공식적입니다. 저자가 회의를 주도하며 작업 산출물을 설명하고 특정 경로를 따라갑니다. 질의응답과 토론이 활발하며, 발견된 결함 외에 개선 제안이나 대안에 대한 논의도 이루어질 수 있습니다.

5. 감사 (Audit)

• 목적: 조직의 프로세스, 표준, 규제, 계약 요구사항 등이 준수되고 있는지 독립적으로 평가하고 확인하는 것입니다. 특정 작업 산출물의 결함 발견보다는 프로세스의 준수 여부에 초점을 맞춥니다.
• 참여자: 독립적인 감사인 또는 팀.
• 대상: 프로세스 문서, 절차 기록, 프로젝트 산출물(샘플), 표준 및 규제 준수 기록 등.
• 특징: 공식적이고 독립적으로 수행됩니다. 프로세스 감사가 주를 이루며, 결과는 적합/부적합 판단 및 개선 권고로 이어집니다.

이러한 다양한 리뷰 기법들은 정적 테스팅의 중요한 부분이며, 소프트웨어 개발 초기부터 품질을 확보하는 데 필수적인 활동입니다.