소프트웨어 테스트라고 하면 보통 프로그램을 실행해보는 장면을 떠올린다.
하지만 모든 테스트가 실행을 필요로 하는 것은 아니다.
정적 테스트(Static Testing)는 코드를 실행하지 않고 결함을 발견하는 방법이다.
요구사항 명세서, 설계서, 코드와 같은 산출물을 직접 검토하거나 분석 도구를 활용해 문제를 찾는다.
이 방법의 가장 큰 장점은 개발 초기에 결함을 발견할 수 있다는 점이다.
일반적으로 결함은 뒤로 갈수록 수정 비용이 커지기 때문에, 정적 테스트는 비용 절감 효과가 매우 크다.
정적 테스트의 대표적인 방법은 리뷰다.
리뷰는 사람이 직접 산출물을 읽고 검토하면서 문제를 찾는 활동이다.
리뷰에는 여러 형태가 있다.
관리 리뷰는 기술적인 결함을 찾기 위한 활동이라기보다는
프로젝트가 계획대로 진행되고 있는지를 점검하는 활동에 가깝다.
일정, 예산, 자원 배분, 품질 상태 등을 확인하고
위험 요소가 있는지 판단하는 것이 목적이다.
보통 프로젝트 관리자나 상위 관리자가 주재한다.
기술 리뷰는 전문가들이 모여 설계나 코드가 기술적으로 적합한지 평가하는 과정이다.
아키텍처 구조가 타당한지, 요구사항을 제대로 반영했는지,
성능이나 확장성에 문제가 없는지를 검토한다.
비교적 공식적이지만 인스펙션만큼 엄격하지는 않다.
인스펙션은 가장 체계적이고 공식적인 리뷰 방식이다.
정해진 절차와 역할을 따르며, 결함을 체계적으로 발견하는 것이 목적이다.
참가자는 명확한 역할을 가진다.
인스펙션은 보통 다음과 같은 순서로 진행된다.
이 과정은 표준(IEEE 1028-2008 등)에 따라 구조화되어 있다.
퍼실리테이터는 회의가 원활하게 진행되도록 돕는 촉진자다.
중립적인 입장에서 참여를 유도하고, 논쟁이 과열되지 않도록 조율한다.
대규모 리뷰나 이해관계자가 많은 경우 특히 중요하다.
워크쓰루는 비교적 비공식적인 리뷰 방식이다.
작성자가 중심이 되어 문서나 코드를 설명하면서 참여자들과 함께 검토한다.
주요 목적은 결함 탐지뿐 아니라 이해 공유와 교육에 있다.
초기 설계 단계에서 자주 활용된다.
감사는 표준이나 계약 조건을 제대로 준수하고 있는지를 확인하는 활동이다.
외부 기관이나 독립적인 조직이 수행하는 경우가 많다.
품질 인증이나 규정 준수 여부 확인에 사용된다.
정적 분석은 사람이 아니라 도구가 자동으로 코드 구조를 분석하는 방식이다.
코드를 실행하지 않고도 다음과 같은 문제를 찾아낼 수 있다.
특히 대규모 프로젝트에서 일관된 품질을 유지하는 데 큰 도움이 된다.
정적 테스트는 코딩 표준 준수 여부를 확인하는 데도 활용된다.
코딩 표준은 팀이 합의한 규칙이다.
예를 들어 변수 이름 규칙, 들여쓰기 방식, 주석 작성 규칙 등이 있다.
코딩 스타일은 가독성과 유지보수성을 높이는 역할을 한다.
일관된 스타일은 협업 품질을 크게 향상시킨다.
정적 분석 도구는 코드의 복잡도도 측정할 수 있다.
대표적인 지표가 순환 복잡도(Cyclomatic Complexity)다.
이는 프로그램 내 독립 경로의 수를 의미하며,
값이 높을수록 테스트해야 할 경우의 수가 많아진다.
일반적으로 조건문이 많을수록 복잡도는 증가한다.
복잡도가 높다면 리팩토링을 고려해야 한다.
자료 흐름 분석은 변수가 어디에서 정의되고
어디에서 사용되는지를 추적하는 기법이다.
이를 통해 다음과 같은 문제를 찾을 수 있다.
테스트 설계 시 정의-사용 경로를 기준으로 케이스를 설계하기도 한다.
정적 테스트는 “실행하기 전에 품질을 확보하는 활동”이다.
코드를 실행하는 동적 테스트만큼 눈에 띄지는 않지만,
실제로는 프로젝트 품질을 좌우하는 중요한 단계다.
특히 대규모 시스템이나 장기 유지보수가 필요한 프로젝트에서는
정적 테스트의 효과가 더욱 크게 나타난다.