QA의 딜레마 대 반복

우리 회사에서는 민첩한 사례로 성공적으로 작업했지만 반복을 사용하지 않았습니다. 주된 이유는 반복주기에서 QA에 맞는 확실한 방법을 찾을 수 없기 때문입니다.

QA는 이 빌드가 고객에게 배포되기 전에 특정 빌드 (릴리스 후보)에 대한 추가 검증 비트로서 QA를 이해 합니다. 요점은 단일 악성 커밋이 전체 릴리스를 손상시키지 않도록하는 것입니다. 어떤 버전인지 알 수 없으므로 QA는 릴리스에 대한 모든 기능 / 커밋이 빌드에 있을 때까지 기다려야 합니다. ( '작은 변화 일뿐'이라는 유명한 마지막 단어는 허용되지 않습니다.)

QA가 릴리스 후보에서 버그를 발견하면 개발자는 해당 릴리스 분기에서 이러한 버그를 수정하고 트렁크에 병합합니다. 모든 버그가 수정되면 QA가 다시 테스트 할 수 있도록 새로운 빌드가 배포됩니다. 특정 릴리스 후보에서 버그가 발견되지 않은 경우에만 고객에게 검증을 위해 제공됩니다.

일반적으로 릴리스 당 약 1 주일에 2 ~ 3 명의 후보가 필요합니다. 수정 사항 작성 시간은 일반적으로 테스트 노력보다 훨씬 적습니다. 따라서 개발자를 바쁘게 유지하기 위해 릴리스 N + 1에서 작업하고 QA는 N에서 작업합니다.

반복을 사용하지 않으면 릴리스 N 및 N + 1에 대한 작업이 겹칠 수 있으므로 문제가되지 않습니다. 그러나 내가 이해 한 바에 따르면 Scrum 또는 XP와 같은 반복 기반 접근 방식과 호환되지 않습니다. 그들은 반복에 포함되는 모든 테스트 노력과 함께 마지막에 릴리스를 해제 할 수 있어야합니다.

이것이 필연적으로 다음과 같은 원치 않는 결과 중 하나를 초래한다는 것을 알았습니다.

(A) QA는 릴리스 후보를 확인하는 데 시간이 필요하고 버그 수정 작업으로 개발자가 바쁘게 행동하지 않기 때문에 개발자는 반복 종료시 유휴 상태입니다.

(B) QA는 첫 번째 출시 후보가 준비되기 전에 이미 작동하기 시작합니다. 이것이 Stack Exchange에서 주로 권장되는 사항입니다. 그러나 테스트 할 특정 릴리스 후보가 없기 때문에 회사가 QA로 이해하는 것은 아닙니다. 그리고 모든 것을 깨는 "작은 변화"는 여전히 눈에 띄지 않게 소개 될 수 있습니다.

(C) 버그는 다음 반복으로 넘어갑니다. Stack Exchange에서도 권장됩니다. 나는 그것이 전혀 해결책이라고 생각하지 않습니다. 그것은 기본적으로 버그 수정이 이루어질 때마다 확인되지 않은 새로운 커밋이 같은 브랜치에 추가되기 때문에 검증 된 빌드를 얻지 못했음을 의미합니다.

이 딜레마를 벗어날 수있는 방법이 있습니까?

QA는이 빌드가 고객에게 배포되기 전에 특정 빌드 (릴리스 후보)에 대한 추가 검증 비트로서 QA를 이해합니다.

이 형식의 QA와 Scrum과 같은 반복 기반 방법론 간에는 본질적으로 호환되지 않습니다.
Scrum 내에서이 팀은 X 주 단위로 고객에게 제공합니다. 여기서 중요한 부분은 개발 팀이 Scrum을 수행하는 경우 고객이 제품의 최종 사용자가 아닌 QA 팀이라는 점입니다.

개발자는 모든 테스트를 통과 할 가능성이있는 경우 QA로 배송 할 수있는 제품을 고려합니다. 이는 아마도 일부 QA 테스트가 일일 빌드에서 이미 실행되었지만 QA 팀의 공식 릴리스 테스트에 미치는 영향은 조직에 달려 있음을 의미합니다.

대부분의 실제 상황에서 애자일은 QA / UAT 또는 그 무엇이든 전달할 때 중지됩니다.

실제 환경에서 QA에서 프로덕션으로 전환하려는 노력은 종종 과소 평가됩니다. 대부분의 경우 실제 비즈니스 사용자는 테스트, 실제 비즈니스 관리자로부터 사인 오프, 작업 등으로 릴리스 일정을 설정하는 등의 작업이 필요합니다.

극단적 인 경우 소프트웨어는 외부 기관의 인증이 필요하거나 엄격한 보안 테스트를 받아야합니다.

이러한 상황에서 버그 수정을 제외하고 분기당 둘 이상의 릴리스를 예상하는 것은 불가능합니다.

심각한 소프트웨어 제품 일수록 악화됩니다. 문서를 교정하고 게시해야합니다. 마케팅 브로셔를 수정해야합니다. 영업 사원은 자신이 무엇을 판매하고 있는지 (쉬운 일이 아님) 등을 알아야합니다. 1 년에 한 번 이상 사업을 진행하고 싶지는 않습니다.

매우 단기적인 해결책은 QA에 반복 후 테스트를 완료하기 위해 추가 기간을 제공하는 것입니다. 즉. 2 주 반복이있는 경우 3 주까지 해제하지 마십시오. QA는 첫 번째 주 동안 다음 반복에 대해 테스트 할 것이 없습니다.

그러나 어떤 일이 일어날 지 미리 경고 할 것입니다 (여러 팀에서 이것을 보았습니다) : 2 주 동안 한 번의 반복 작업을 수행하고 QA가 과부하되어 상황에 처하게됩니다. 전체 QA 주간 및 다음 반복에서는 일주일의 작업 만 수행됩니다. 이러한 반복, QA는 할 일이 없으며 문제를 해결했다고 생각할 것입니다. 그러나 다음 반복에서는 사이클을 다시 시작합니다.

따라서 그 주에 추가하자마자 릴리스가 안정적인지 확인하기 위해 (내가 배운 한 가지 이유는 비즈니스에 대한 믿음을 잃으면 Agile이 기하 급수적으로 구현하기가 더 어렵다는 것입니다) 장기 계획에.

Jez Humble 's 사본 구입 Continuous Delivery, 읽고, 덮고, 팀 전체에 전달하십시오. 모두에게 영감을주십시오. 그런 다음 가능한 모든 것을 구현하십시오.

빌드 프로세스를 매끄럽게 만드십시오. 단위 테스트 정책을 구현하고 모든 빌드에서 실행되도록하십시오. 배포 프로세스를 가장 간결하게 만드십시오. 세 번의 클릭? 매끄럽지 않습니다.

이 모든 작업을 수행 한 후에 가끔 회귀 버그가 발생하더라도 큰 문제가되지 않습니다. 왜 그런지 알아? 비즈니스가 실패하기 전에 (선택적으로) 롤백하고, 수정 한 후 다시 배포 할 수 있습니다. 실제로 야간 관리인이 롤백 할 수 있으며 프로세스는 매우 간단합니다.

나는 당신이 생각하는 것을 알고 있습니다 : 우리는 그 모든 것을 할 시간이 없습니다. 내가 말해 줄게 QA를 오버로드하는 경우 반복 당 너무 많이 배포하는 것입니다. 그러지 마 이미 과부하가 걸리지 않은 경우 아직 자동화 된 테스트 스위트가없는 이유를 물어보십시오. 당신은 곧있을 것입니다.

비즈니스에 대한 완벽한 가시성을 바탕으로이 모든 작업을 수행하십시오. 이 작업의 일부를 낮게 추정하고 반복에 주입하십시오. 또는 더 나은 방법으로 이야기로 나누고 다른 모든 것들과 함께 우선 순위를 정하도록하십시오.

그들에게 a) 릴리즈의 안정성을 향상시키고 b) 문제에 대한 대응 능력을 향상시킬 것이며 c) 나중에 더 많은 속도를 구입할 것이라고 설명한다. 이런 것을 원하지 않는 드문 회사입니다. 애자일 회사를 원하지 않는 것은 아니므로 저항이 생기면 다른 문제가 있다는 것을 알게 될 것입니다.

Continuous Delivery가 중단되면 QA가 반복 종료시 걸리는 시간을 단축 할 수 있습니다. 가능한 한 빨리 반복을 병렬로 가져 오는 것이 모든 사람의 관심사입니다. 어쩌면 반복이 끝나면 언젠가 시간을 채워야 할 수도 있습니다. 나는 이미 다른 곳에서 어떻게해야하는지 대답했다 .

반복을 사용하지 않으면 릴리스 N 및 N + 1에 대한 작업이 겹칠 수 있으므로 문제가되지 않습니다.

정확히 무엇을 구성하는지 결정하는 방식에 문제가있는 것 같습니다 work for release N.

이상한 이유로 (특정 애자일 레시피에 대한 오해가 있다고 생각할 수 있습니다 ) 어쨌든 민첩한 접근 방식은 모든 QA 팀의 노력이 반복에 통합되도록 요구 합니다.

• ^{그것이 사실이라면, Agile의 인기는 우리가 지금 보는 것과 비슷하지 않을 것이라고 생각합니다. 개발자 팀 반복을 QA 테스트주기와 강제로 동기화 할 수있는 많은 프로젝트를 상상할 수 없습니다.}

아래 에 민첩성 에 대해 조금 더 있지만 먼저 정렬 해 봅시다 work for release N...

개발팀이 그런 식으로 일을 정의해야 할 강력한 이유는 없습니다. 당신의 설명과는 정반대로, 모 놀리 식 "작업 단위"대신 느낌이 쉽게 이정표가있는 여러 단위가 있음이 분명합니다 ...

• ^{예를 들어, 첫 번째 "단위"는 후보 빌드 가 테스터에게 전달 될 때 별개의 이정표로 표시되며 추가 이정표는 QA 등에 의해 수행되는 테스트주기와 관련된 변경에 해당합니다.}

또한 정의하는 방식에 유의하십시오. work for release N QA 워크 플로에 의해 강제되지는 않습니다. 당신이 묘사 한 것에서 물건은 그들 자신의 (그리고 상당히 합리적인) 일정을 가지고있는 것처럼 보입니다.

위에서 주어진 경우 작업 단위를 정의하는보다 현실적인 방법은 다음과 같습니다.

1. 빌드가 QA로 전달되는 순간까지의 개발 활동
   Release Candidate N
2. 첫 번째 QA 테스트주기와 관련된 개발 활동
   Release Candidate N patch 1
3. 두 번째 QA 테스트주기와 관련된 개발 활동
   Release Candidate N patch 2
4. 최종 빌드까지

위의 작업 단위는 애자일이든 무엇이든 관계없이 적용됩니다.

이들은 자연스럽고 정의, 추적 및 추적이 편리 합니다. 이는 QA 일정과도 잘 어울리므로 편리한 조정 및 QA 노력이 가능합니다.

그러나 내가 이해 한 바에 따르면 Scrum 또는 XP와 같은 반복 기반 접근 방식과 호환되지 않습니다. 그들은 반복에 포함되는 모든 테스트 노력과 함께 마지막에 릴리스를 해제 할 수 있어야합니다.

애자일과 의 호환성에 대한 이해 는 근본적으로 잘못 보이며 여기에 이유가 있습니다.

당신이 한 가정은 애자일과 아무런 관련이 없습니다. 만약 우리가 그 이름으로 표시된 바와 같이 액면가에서 철학 을 취한다면 그것은 민첩성 을 선호하고 실천하는 접근법입니다 .

이러한 관점에서, 특정 "고정"워크 플로우를 고수하고 그것이 편리한 지 아닌지를 단순히 무시하는 것은 애자일의 정신과 모순됩니다. 노예 관행에 "절차"리드를 다음 폄하 그래서 설득력에 반 Arsed 애자일 선언문 "... 우리는 어떻게 그 개인 (우리가 용어를 '자원'을 선호) 상호 작용 컨트롤을 필수 프로세스와 도구를 가지고" .

아래에 인용 된 다른 질문 에 대한 답변 에서 이에 대해 더 많이 찾을 수 있습니다 . "배송 가능 출시"에 대한 참고 사항을 살펴보면 이전과 비슷한 방식으로 OP가 비슷한 방식으로 혼동되었습니다.

민첩한 원칙의 적용에 대해 민첩 해야합니다 . 프로젝트 요구 사항이 민첩하지 않거나 (안정하거나 느리게 변경되는 경우) 왜 귀찮게합니까? 나는 한 번도 완벽하게 잘하고 있던 프로젝트에서 최고 경영진이 Scrum을 강요하는 것을 보았습니다. 정말 낭비였습니다. 전달 기능이 향상되었을뿐만 아니라 개발자와 테스터 모두 불행하게되었습니다.

나를 위해, 애자일의 가장 중요한 부분 중 하나는 각 스프린트가 끝날 때 배송 가능한 석방 물을 가지고 있다는 것입니다. 그것은 몇 가지를 의미합니다. 먼저, 고객에게 빌드를 공개 할 수 있다고 생각되는 경우, 버그가 발생하지 않도록 테스트를 수행해야합니다.

배송 가능한 릴리스 입니다. 흠. 흠. 민첩한 칵테일에 린 (Lean) 을 한두 번 더하는 것을 고려하십시오. 이것이 고객 / 시장 요구가 아니라면 (테스트) 자원 낭비 만 의미합니다.

나는 스프린트-엔드-릴리스를 팀을 만족시키는 몇 가지 체크 포인트 로 취급하는 데 범죄가 없다고 본다 .

• ^{dev : 네, 테스터에게 전달하기에 충분히 좋아 보입니다. QA : 예. 추가 배송 테스트가 필요한 경우에는 충분할 것 같습니다. 팀 (dev + QA)이 만족입니다.}