우리의 개발팀은 GitFlow 브랜칭 전략을 사용하고 있습니다.
최근에 소프트웨어 품질을 향상시키기 위해 몇 명의 테스터를 모집했습니다. 아이디어는 모든 기능을 테스터가 테스트 / QA해야한다는 것입니다.
과거에는 개발자가 별도의 기능 분기에서 기능에 대해 작업하고 develop완료되면 다시 분기로 병합합니다 . 개발자는 해당 feature지점 에서 자신의 작업을 직접 테스트 합니다. 이제 테스터와 함께이 질문을 시작합니다
테스터는 어떤 지점에서 새로운 기능을 테스트해야합니까?
분명히 두 가지 옵션이 있습니다.
- 개별 기능 지점에서
- 상의
develop지점
개발 지점 테스트
처음에 우리는 이것이 다음과 같은 확실한 방법이라고 믿었습니다.
- 이 기능은
develop개발이 시작된 이후 지점에 병합 된 다른 모든 기능으로 테스트 되었습니다. - 나중에 충돌을 감지 할 수 있습니다
- 테스터의 업무를 쉽게 해주므로 항상 한 지점 (
develop) 만 처리 합니다. 그는 개발자에게 어떤 브랜치가 어떤 기능에 대한 것인지 묻지 않아도됩니다 (기능 브랜치는 관련 개발자가 독점적으로 자유롭게 관리하는 개인 브랜치입니다)
이것의 가장 큰 문제는 다음과 같습니다.
develop분기 버그로 오염되어있다.테스터는 버그 나 충돌을 발견하면 개발자에게 다시보고합니다. 개발자는 개발 브랜치에서 문제를 해결하고 (기능 브랜치는 병합 된 후에 포기 됨) 나중에 더 많은 수정이 필요할 수 있습니다. 여러 하위 시퀀스 커밋 또는 병합 (
develop버그 수정을 위해 브랜치를 다시 브랜치에서 다시 만든develop경우) 가능한 경우 브랜치 에서 기능을 롤백 하는 것이 매우 어렵습니다.develop지점에 다른 시간 에 병합되고 수정되는 여러 기능이 있습니다 .develop브랜치의 일부 기능만으로 릴리스를 만들려고 할 때 큰 문제가 발생합니다.
기능 지점 테스트
다시 한 번 생각하고 기능 분기에서 기능을 테스트해야한다고 결정했습니다. 테스트하기 전에 develop브랜치에서 기능 브랜치로 변경 사항을 병합합니다 (브랜치 따라 잡기 develop). 이것은 좋다 :
- 여전히 주류의 다른 기능으로 기능을 테스트합니다.
- 추가 개발 (예 : 버그 수정, 충돌 해결)은
develop분기를 오염시키지 않습니다 . - 기능이 완전히 테스트되고 승인 될 때까지 기능을 릴리스하지 않도록 쉽게 결정할 수 있습니다.
그러나 몇 가지 단점이 있습니다
- 테스터는 코드 병합을 수행해야하며, 충돌이있을 경우 (아마도) 개발자에게 도움을 요청해야합니다. 우리의 테스터는 테스트를 전문으로하며 코딩 할 수 없습니다.
- 다른 새로운 기능이 없어도 기능을 테스트 할 수 있습니다. 예를 들어, 피처 A와 B는 동시에 테스트 중이며, 두 피처는
develop브랜치 에 병합되지 않았으므로 서로를 알지 못합니다 . 즉,develop두 기능이 모두 개발 브랜치에 병합되면 브랜치 에 대해 다시 테스트해야 합니다. 그리고 나중에 이것을 테스트해야한다는 것을 기억해야합니다. - 기능 A와 B가 모두 테스트되고 승인되었지만 충돌이 확인되면 두 기능의 개발자 모두 테스트를 통과 한 기능 분기 때문에 자신의 결함 / 작업이 아니라고 생각합니다. 의사 소통에 여분의 오버 헤드가 있으며 때로는 갈등을 해결하는 사람이 좌절됩니다.
위는 우리의 이야기입니다. 제한된 리소스로 모든 곳의 모든 것을 테스트하지 않기를 바랍니다. 우리는 여전히 이에 대처하는 더 좋은 방법을 찾고 있습니다. 다른 팀이 이런 상황을 어떻게 처리하는지 듣고 싶습니다.
