안전한 테스트 환경 : 시스템 버전 관리
시스템 버전 관리(a.k.a 형상관리)란, 소프트웨어의 변경 사항을 추적하고 여러 사용자들의 작업을 체계적으로 통제하고 조율하기 위한 것으로 소스코드, 개발환경, 배포버전 등 작업 내역에 대한 관리 체계를 정의한 것입니다. 형상관리는 단순히 소프트웨어 운용을 위한 시스템 버전 관리만을 의미하지 않고 소프트웨어와 연관된 문서나 파일의 변경사항 등을 포괄하여 관리합니다.
개발에서는 버전관리를 아래와 같이 정의하여 사용 할 수 있습니다.
배포 관리 : 작업자별 배포 시점을 관리. EX) 태그(Tag)를 달아 브랜치 버전이나 배포 시점을 관리
복구 : 버전 관리를 통해 복구 또는 백업 가능
협업 : 작업자별 수정사항을 쉽게 파악
그럼, 소프트웨어 테스팅 관점에서 형상관리가 필요한 이유와 버전 관리를 통해 얻을 수 있는 이점은 무엇일까요. QA관점의 버전관리를 이야기해보겠습니다.
QA가 프로젝트나 제품에 대한 테스트를 수행할 때 별도의 테스트 환경(시스템, 컴포넌트, 데이터 등)에서 이를 수행합니다. 테스트 환경은 프로젝트나 제품별로 테스트 요청이 발생할 때마다 새로 생성하여 사용할 수 없습니다. 제한된 환경 내에서 테스트 요청은 여러 건이 발생할 수 있고 모든 테스트 항목이 서로 섞여 정확한 테스트를 불가능하게 하여 테스트 실패의 결과를 초래하지 않기 위해 시스템 버전을 관리하는 형상 관리 활동이 필요합니다.
안전한 환경에서 신뢰할 수 있는 테스트 결과를 얻기 위해 테스트 수행 시스템에 대한 테스터의 요구사항은 다음과 같습니다.
각각의 테스트 항목은 다른 테스트와 독립적이어야 한다(테스트 생명주기, 버그 관리, 데이터베이스 포함).
관리되지 않은 시스템으로 인해 의도하지 않은 사이드 이펙트가 발생하지 않아야 한다(예: 테스트 수행 중 데이터 파일의 변경/삭제, 시스템이나 소프트웨어 환경 설정 중 테스트를 위해 약속된 기준 사항을 위반 등).
테스트 대상에 대한 개발 작업과 연관된 테스트 웨어Testware 항목이 식별되고 그 상태로 정확하게 유지되어야 한다.
시스템 버전을 제어할 수 있고, 변경 사항을 버전별로 추적 및 관리할 수 있어야 한다.
테스터에게 형상 관리는 다음의 효과를 기대할 수 있게 합니다. 시스템이나 소프트웨어에 고유 식별 번호를 부여함으로써 각각의 테스트 항목을 식별할 수 있고, 테스트 항목 간의 충돌을 막아 배타적으로 테스트할 수 있게 도와줍니다. 또한 테스트 웨어 버전을 관리하고, 변경사항을 기록하고, 테스트 항목 버전과 연결해서 테스트 프로세스 전반에 걸쳐 추적성을 유지할 수 있게 해주고 상호 참조할 수 있게 도와줍니다.
‘형상 관리’를 잘 유지하고 관리하려면 고유 식별 번호가 부여된 테스트 환경의 테스트 대상, 가용된 자원, 테스트 문서, 파일 시스템, 변경 사항 등에 대해 자세히 기록하여 문서화해야 합니다. 이를 통해 원하는 형태로 테스트 수행 환경을 다양하게 이용할 수 있습니다.
버전 관리 규칙
프로젝트나 제품 유지 보수 시 사용할 버전(고유 식별 번호)에 대한 표기 방법이나 정의는 별도로 없습니다. 팀 혹은 구성원과의 합의로 빌드 버전, 배포 버전, 환경 버전, 문서 버전, 버그 관리 버전을 동일하게 사용하기 위한 규칙을 정하고 약속된 규칙을 준수하는 것이 중요합니다.
다음은 몇 가지 버전 네이밍 규칙에 대한 예시입니다.
버전 네이밍 규칙 예시①
‘배포 버전_개발 Tagging number or Flag_프로젝트명_테스트 서버 환경’ 구성으로 규칙을 정하면 '배포버전 1.0/태깅 번호 123456/프로젝트A/테스트 서버 1번'을 사용한다는 가정하에 표기되는 고유 식별 번호는 “1.0_1234566_ProjectA_1”이 됩니다.
버전 네이밍 규칙 예시②
iOS/안드로이드의 빌드 버전과 ios-CFBundleVersion/aos-version code를 사용하는 방법입니다. ‘프로젝트명_빌드 버전_bundle version’이라는 규칙을 적용하면, 고유 식별 번호는 “ProjectA_1.3_201.4”가 됩니다.
버전 네이밍 규칙 예시③
[Major].[Minor].[Patch] 순으로 버전 규칙을 적용하는 방법입니다. 해당 방식은 Github의 공동창업자인 톰 프레스턴-베르너Tom Preston-Werner에 의해 설계된 방법을 인용하는 것입니다.
빌드 교체나 API 변경 등 기존 버전과 호환되지 않는 메이저 기능 변경 시 Major 버전을 올리고, 기존 버전과 호환되면서 마이너 기능 변경 시 Minor 버전을, 기존 버전과 호환되면서 리소스, 데이터 등 사소한 패치 발생 시 Patch 버전을 올리는 것입니다.
예를 들어, 기존 버전 1.0.0에서 major 버전업 시 2.0.0, minor 버전업 시 1.1.0, patch 버전업 시 1.0.1이 고유 식별 번호가 됩니다.
지금까지 예시로 살펴본 버전 네이밍 규칙을 적용하여 버전에 관리 규칙을 부여하고 규칙에 따른 명확한 정의를 제공함으로써 프로젝트 관련자에게 패키지가 어떤 식으로 변경되었는지 의도를 전달하고 이해할 수 있게 해주며 기존 소프트웨어와의 호환을 확인할 수 있도록 합니다.
