테스트 케이스의 버전 제어

Question

테스트 계획을 코드와 함께 버전 제어에 보관해야합니까? 즉, 테스트 계획과 코드는 동일한 버전 제어 시스템에 속하며 동일한 개정이 숫자로 표시됩니다. 나는 단위 테스트 코드에 대해서 말하고있는 것이 아니라 수동 테스트 케이스로 채워지는 테스트 계획 문서이다. 웹 기반 테스트 케이스 관리 시스템이 있지만 테스트 케이스가 버전 제어되고 코드와 어떻게 동기화되는지는 의심 스럽습니다.

업데이트 : 비 개발자 팀 구성원에게 쉽게 액세스 할 수 있기 때문에 Acornally 내 oragnization 용 웹 기반 테스트 관리 시스템을 찾고 있습니다 (예 : VC를 사용하여 리포지토리에서 테스트 계획을 체크 아웃 할 필요가 없음).). 그러나 소프트웨어의 주요 일정/출시와 동기화 된 이러한 테스트 계획을 버전 제어하는 ​​것을 선호합니다. 나는이 필요를 만족시키는 시험 관리 시스템을 찾지 못했습니다. 아니면 잘못된 방향으로보고 있습니까?

Answer 1

나에게 의미가 있습니다. 나는 테스트 (수동 사양 이건 단위 테스트 이건간에)와 해당 코드가 잠금 단계가 될 것으로 기대한다. 나는 또한 설명서가 특정 체크인을위한 코드에 크게 부합 할 것이라고 (아마도 낙관적 인) 기대할 것이다.

아마도 완전히 단계적으로 유지할 수없는 경우 소스 코드 태깅 (또는 분기?) 메커니즘을 사용하여 일관된 버전 세트를 식별 할 수 있습니까? 버전 관리에 수정하거나 코드 기반을 구축하는 테스트가 포함되어있는 경우 (즉, 테스트가 비정상적인 상황이 아닌 코드를 유도하는 경우) 버전 관리에 더 많은 의미가 있습니다.

Answer 2

개인적으로, 나는 당신의 생각을 좋아합니다. 많은 소프트웨어 개발 패러다임의 테스트가 시스템이 어떻게 작동해야하는지에 대한 스펙을 기반으로해야하지만, 현재 작동하는 방식이 아니므로 동기화 된 코드와 독립적으로 쉽게 개발할 수 있습니다. 문서는 본질적으로 문서이기 때문에 다양한 형식의 문서 버전 제어 시스템에서 제대로 작동 할 수 있습니다.

일부 팀에서는 TestDirector과 같은 도구를 사용하여 테스트 계획 및 테스트 사례를 관리하고 버그 추적 시스템에 연결합니다. 모든 테스트 케이스, 버그 등은 데이터베이스에 저장된 변경 기록을 가지고 있으므로 다시 돌아가 검토 할 수 있습니다 (그리고 약간의 작업과 약간의 위키 백과로 검색 할 수 있습니다. The Doctor). 그러나 우리는 코드를 동결 한 중요한 이정표를 제외하고는 코드를 동기화하지 않았으며 그 당시 코드 + 스크립트는 MKS Integrity (개인적으로 우리 직장에서 Integrity를 ​​사용하지 않았다고 생각합니다. 코드 발기인뿐만 아니라 전체 개발 팀과 함께).

다른 팀은 워드 문서를 작성하고 백업 된 폴더에 보관합니다. 간단하지만 너무 크지 않은 프로젝트의 소규모 팀에서도 작동 할 수 있습니다.