여러 개의 브랜치가있는 큰 프로젝트를 테스트하는 프로세스와 도구

Question

우리는 개발을 위해 상당한 수의 브랜치 (상당히 전통적인 메인 라인 모델)를 사용하며, 대규모의 프로젝트를 효율적으로 관리하고 구성하는 방법으로 매우 효과적입니다. 팀. 메인 라인을 항상 안정적으로 유지하기 위해 QA 테스트 개발 브랜치를 메인 라인으로 다시 밀기 전에 QA 테스트 개발 브랜치를 가지고 있습니다.

이제 테스트와 관련된 몇 가지 흥미로운 문제가 있습니다. 가장 일반적인 방법은 테스트하는 동안 테스터가 버그를 발견하면 이미 수정 된 것으로 표시되어 있다고 가정합니다. 수정이 실패했기 때문에 (버그를 다시 열어야하는 경우), 또는 수정 사항이 테스트중인 분기에 도달하지 않았기 때문입니까?

perforce 사용자로서 우리는 PERFORCE 작업을 통해 이러한 문제를 해결하려고합니다. 그것은 꽤 "원시"도구입니다 - 더 많거나 적은 기본 기능을 제공하지만 테스터가 사용할 수있는 쉬운 인터페이스는 아닙니다. 그래서 거기에 더 많은 사용자 친화적 인 방법 또는 완전히 다른 방법이 있는지 궁금하네요 (나는 "분기를 피하십시오"는이 경우 우리를위한 실용적인 대답이라고 생각하지 않습니다!)

무엇이 최선입니까? 여러 지점에서 효과적인 QA를 수행하는 방법은 무엇입니까? 이러한 문제에 대한 자동화와 지원을 제공하는 훌륭한 도구가 있습니까?

Answer 1

때때로 테스트는 개발 분기에서 한 번 수행되고 릴리스 분기로 병합 된 후에 다시 수행됩니다. 그러나 이것이 프로세스의 선택 사항이며 요구 사항은 아닙니다.

"mainline"브랜치에서만 릴리스하는 경우 변경 사항이 릴리스 브랜치에 병합 된 후에 만 ​​테스트 할 수 있도록 QA 프로세스를 변경하는 것이 좋습니다. 또한 개발자가 변경 사항을 프리/포스트 병합을 통해 테스트 할 수 있습니다. 이것은 더 전형적입니다.

이제는 개발자 당 하나의 브랜치 (그냥 추측)가있는 것 같습니다. 그리고 각 개발 지점에 버그를 제출합니다. 나는이 과정을 심각하게 고려할 것이다. 그것은 유지 보수가 불가능하며 병합 후에 버그를 추적하는 것이 매우 어려울 것입니다.

TrueWill이 제안했듯이 지속적인 통합을 설정하는 것이 좋습니다. 빈번한 (매일) 빌드로 보충하십시오. 그런 다음 QA에서 빌드를 테스트합니다.

Answer 2

품질 보증 본점에서 버그를 발견하고는 다음 dev에 지점에 고정되어있는 경우

:

• 하자 그것을 dev에 지점에 주요 지점에서
• 하자 QA 주석 버그가 수정되었는지 확인하여 품질 관리를하지만, 열린 상태로 유지
• 메인 브랜치에 수정본을 릴리스 한 후 다시 테스트합니다. 메인 브랜치
• 메인 브랜치의 주요 버그를 수정했습니다.

다른 상황에서는 이와 같은 운동 시나리오를 시도하십시오 (여기에는 버그 수명주기가 있습니다). 테스트 시점 및 테스트 대상, qa-dev 통신의 모습을 준비하십시오. 모든 것을 적어 라. 그것이 당신의 시험 과정이 될 것입니다. QA를 따르십시오 (적절한 경우 dev). 아마도 모든 상황을 즉시 처리 할 수는 없으므로 시간을 들여 프로세스를 개선하십시오.

대형 멀티 프로젝트입니다. 어쩌면 테스트 관리자/테스트 리드/또는이 역할이라고 부르는 것이 무엇이든 고용하는 것에 대해 생각해보십시오. qa 작업을 관리 할 사람. 테스트 전략을 준비하십시오. 테스트 계획을 준비하십시오. 개발팀과 공동 작업 qa. 적절한 의사 소통을 보장하십시오. 또한이 담당자는 다른 지점 간의 품질 보증 작업을 관리 할 수 ​​있습니다. 병렬 브랜치가있는 복잡한 프로젝트에서 qa는 (다른 모든 사람처럼) 훌륭한 관리가 필요합니다.

도구에는 몇 가지가있을 수 있지만 HP Quality Center 및 HP Quick Test Pro에서만 작동했습니다. QTP는 테스트 자동화 소프트웨어입니다 (레코드 & 재생, 데이터 기반, 스크립팅 - VB). QC는 Tests (수동 및 자동) 저장소이며, Defects는 또한 Requirments, Test Results를 보유 할 수 있습니다. 요구 사항 커버리지를 추적하고 테스트 결함 링크 (실제 테스트 실행 결함이지만 테스트 실행에서 테스트로 이동할 수 있음)를 추적 할 수 있습니다.
또한 Cycles 및 Releases를 정의 할 수 있습니다. 예를 들어 분기마다 순환 수 및 코드 릴리스 릴리스 (각 릴리스는 주어진주기와 관련되어 있으므로 릴리스 된 분기 코드가 명확하게 나타납니다) 일 수 있습니다. 또는 다르게 매핑 할 수 있습니다.
문제는 소프트웨어 비용이 들게된다는 것입니다. 나는 정말로 돈을 의미한다. 그것은 헌신이다.