QA에 12 주가 걸리면 민첩하게 행동을 중단해야합니까?

우리 회사의 누군가가 최근 우리의 관리자가 회사가 전체 QA주기를 고려하는 것 (즉, 전체 제품군을 처음부터 테스트하는 것)을 유발해야한다고 생각하는 핵심 제품에 대한 변경을 제안했습니다. 분명히 QA는 제품에 대한 전체 QA주기를 수행하는 데 12 주가 걸립니다. 이것에 대한 나의 문제는 우리가 애자일 개발 (대부분 제 생각에는 반쯤 멍청한)을하려고한다는 것입니다. 스프린트 전체를 수행 한 다음 출시를 진행할 것입니다. 문제는 실제로 QA가 12 주 동안 업무를 수행해야한다면 애자일을 포기하는 것을 포기해서는 안 되는가입니다. 이런 상황에서 애자일을 시도하려는 이유는 무엇입니까?

음, 귀하의 질문에 직접 대답이 될 것이다 뮤 난 두려워 - 당신이 또는 시도 종료 할 것인지 여부 정보통 추측을하기에 충분한 세부 사항이 바로이 아니다.

내가 매우 긍정적으로 생각하는 것은 민첩성 수준이 고객 / 시장 요구 (정보를 제공하지 않은)에 의해 주도되어야한다는 것입니다.

• ^{예를 들어, IDE 사용자로서 일년에 한 번 또는 두 번 새 버전으로 업그레이드하는 것이 매우 기쁩니다. 결코 그렇게 서두르지 않습니다. 즉, 릴리스주기가 3 개월 ( 12 주 )이면 완벽하게 만족합니다.
   
  반면에, 금융 거래 회사가 소프트웨어가 시장 변화에 적응하는 데 한 달 이상이 걸리면 파산한다고 쉽게 상상할 수 있습니다 .이 경우 12 주 테스트주기는 지옥으로가는 길입니다. 이제이 점에서 귀하의 제품은 무엇입니까?}

고려해야 할 또 다른 사항은 고객 / 시장 요구를 충족시키기 위해 어떤 수준의 품질이 필요합니까?

• ^{예를 들어, 내가 한 회사에서 소프트웨어 공급 업체로부터 라이센스를받은 제품에 새로운 기능이 필요하다는 것을 알았습니다. 이 기능이 없다면 우리는 오히려 강하게 고통을 겪었습니다. 그래서 우리는 그들이 민첩 하고 한 달 안에 업데이트를 제공 하기를 정말로 원했습니다 .
   
  그리고 예, 그들은 민첩한 것처럼 보였습니다. 그리고 그들은 한 달에 그 업데이트를 발표했습니다 (QA주기가 12 주라면 그냥 건너 뛰었을 것입니다). 그리고 우리의 기능 은 완벽하게 작동했습니다-우리가 완벽하게 행복했을 것 같아요? 아니! 우리는 이전에 잘 작동했던 일부 기능에서 showtopper regression 버그를 발견했습니다. 그래서 우리는 이전 버전을 고수해야했습니다.
   
  또 다른 달이 지났습니다-그들은 또 다른 새로운 버전을 출시했습니다 : 우리의 기능동일한 회귀 버그가 있었지만 다시 업그레이드하지 않았습니다. 또 다른 달과 다른 달.
   
  결국 우리는 반년 만에 민첩성으로 업그레이드 할 수있었습니다.}

자, 언급 한 12 주에 대해 조금 더 자세히 살펴 보겠습니다 .

품질 관리주기를 단축하기 위해 어떤 옵션을 고려 했습니까? 당신은 위의 예에서 볼 수 있듯이, 단순히 당신이 더 나은 그래서, 음, 기대를 포기하지 않을 수 있습니다 건너 뛰는 민첩 하고 고려 다른 그것을 해결하는 방법을.

예를 들어, 제품의 테스트 가능성 을 향상시키는 방법을 고려 했 습니까?

아니면 더 많은 QA를 고용하기 위해 무차별 대입 솔루션을 고려 했습니까? 그러나 간단하게 보이지만 어떤 경우에는 실제로 갈 길입니다. 경험이 부족한 경영진이 평균 적인 전문 테스터만으로도 점점 더 많은 수석 개발자를 맹목적으로 고용함으로써 제품 품질 문제를 해결하려는 것을 보았습니다 . 한심한.

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

의견에 제공된 설명을 기반으로 업데이트

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

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

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

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

요구 사항이 민첩하지 않은 경우 민첩성을 적용하지 않는 측면에서 응답이 끝났을 때 가장 중요했습니다. 나는 이것이 자리에 있다고 생각합니다. 우리가 민첩하게 일을 시작했을 때, 우리는 전화를 걸었고 상황이 합리적이었습니다. 그러나 그 이후로 상황은 극적으로 변화했으며 더 이상 의미가없는 프로세스에 집착하고 있습니다.

정확히 맞았습니다. 또한 설명 한 내용에서 상태 (팀 / 관리 성숙도 및 고객 관계)에 도달 한 것처럼 보이므로 Scrum 대신 정기적 인 반복 모델 개발 을 사용할 수 있습니다 . 그렇다면 정기적 인 반복 과 같은 경우 내 경험에 따라 Scrum보다 생산성이 높았다는 것을 알고 관심을 가질 수도 있습니다 . 훨씬 더 생산 - 단순히 거기 때문에 훨씬 적은 오버 헤드, 단순히 너무 쉽게 (각각에 품질 보증을위한 테스트에 초점) 개발에 집중했다.

• ^{나는 보통 페라리 (정기 반복)와 랜드 로버 (스크럼)의 관점에서 생각합니다 .
   
  고속도로에서 운전할 때 (그리고 프로젝트가 해당 고속도로에 도달 한 것처럼 보임) 페라리는 Landrover에서 지옥을 이겼습니다.
   
  스포츠카가 아닌 지프가 필요한 오프로드입니다. 요구 사항이 불규칙하거나 팀워크 및 관리 경험이 좋지 않은 경우 스크럼을 선택해야합니다. 붙어-페라리는 오프로드에 붙어 것입니다.}

우리의 전체 제품은 실제로 독립적으로 업그레이드 할 수있는 많은 작은 부품들로 구성되어 있습니다. 고객은 이러한 작은 구성 요소를 훨씬 더 자주 업그레이드하려고합니다. 스프린트가 끝날 때 작은 구성 요소를 출시하고 QA하는 데 집중해야 할 것 같습니다.

위의 계획은 좋은 것 같습니다. 나는 그런 프로젝트에서 한 번 일했다. 우리는 매월 릴리스를 작은 위험이 적은 구성 요소에 국한된 업데이트와 함께 제공 했으며 그에 대한 QA 사인 오프는 쉽게 얻을 수있었습니다.

• ^{이 전략에 대해 명심해야 할 한 가지는 변경이 예상되는 곳에 현지화되어 있음을 테스트 할 수있는 검증하는 것입니다. 변경되지 않은 구성 요소에 대한 비트 단위 파일 비교에 이르기까지 갔다가 가지 않으면 선적하지 못할 것입니다. 우리 개발자가 아닌 릴리즈 품질을 책임지는 것은 QA입니다.
   
  예상치 못한 변경 사항이 발생하지 않도록하는 것은 테스터의 골치 아픈 일입니다. 솔직히 개발자에게는 걱정할만한 다른 것들이 더 중요하기 때문에 더 중요합니다. 그리고 그로 인해 (테스터) 는 테스트 후 출시로 상황이 통제되고 있다는 확실한 증거 가 실제로 필요합니다 .}

오, 나는 당신의 고통을 느낍니다. 이 작업을 수행하기 위해 품질 관리팀에 변경해야 할 사항이 몇 가지 있습니다.

내 조언은 팀을 세 팀으로 나누는 것입니다.

기능 테스트 -새로운 개발 테스트에 대한 빠른 처리.

회귀 테스트 -문 밖으로 나가기 전에 제품을 완전히 테스트합니다. 팀 규모를 줄인 후에도 첫 번째 팀에서 대부분의 버그를 발견하므로 3 개월이 걸리지 않습니다.

자동 테스트 -회귀 테스트 팀의 작업 속도를 높이기 위해 전체 회귀 테스트 모음을 작성합니다.

세 번째 팀은 보너스이지만 처음 두 팀을 가질 수 없다면 폭포 일 수도 있습니다.

예를 들어 :

참고 당신의 QA 팀은 아마도 (ATDD) 원 외부에서 작업하고, 당신이 내부를 위해 노력하고 있습니다.

그런 식으로 일해도 괜찮다고 생각합니다. 자동화 된 테스트에서 각 스프린트에서 고객의 요구 사항을 충족하고 있음을 증명할 수 있으면 QA가 여가 시간에 테스트를 수행하도록 허용하고 결함이있는 경우 다음 스프린트로 진행할 수 있습니다.

"정의 정의"문제가있는 것 같습니다.

품질 보증 그룹은 외부에 있으며 고객 릴리스에만 관련되어 있기 때문에 문제에 대한 적시에 피드백을 제공 할 수는 없습니다. 즉, 빠른 피드백을 원한다면 팀을 위해 "사내"어느 정도의 테스트를 수행해야합니다.

품질 보증 그룹이 존재하지 않는 것처럼 취급합니다. 스프린트 종료시 릴리스가 다음날 가장 중요한 환경에 배포 될 경우의 행동입니다. 소프트웨어는 고객에게 갈 때까지 완료되지 않습니다.

품질 관리는 아무것도 찾지 않아야합니다.

도착하기가 더 어려울 것입니다. 처음 몇 번은 몰래 들어간 것들이있을 것입니다. 자동 수락 테스트 및 "회귀"테스트는 여기서 가장 친한 친구입니다. TDD는 그러한 스위트의 큰 부분을 구축하는 데 도움이됩니다. 무언가를 깨뜨렸다면 빠르게 알 수 있어야합니다.

QA가 완료 되기 전에 특정 릴리스 를 보고 고객에게 정식 피드백 을 제공 할 수있는 고객 담당자 / 제품 소유자 가 있습니까? 그렇다면 QA를 2 차적인 다소 느린 피드백 소스로 취급하면서 민첩한 방법을 사용할 수 있고 이점을 최대한 활용할 수 있습니다. 품질 보증이 완료된 후에 만 ​​출시가 "공식적으로 준비"될 수 있지만 다음에 시작하기 전에 기다릴 필요는 없습니다.

그러나 회사 규칙에 따라 QA가 완료되기 전에 고객이 릴리스를 보지 말아야한다고하면 해당 규칙을 변경할 때까지 민첩성을 잊어 버릴 수 있습니다.

설명한 프로세스는 민첩한 프로세스가 아닙니다. 민첩성이 높은 팀은 모든 스프린트마다 안정적이고 잠재적으로 릴리스 가능한 빌드를 제공 할 수 있습니다. 대부분의 민첩한 구현에서 QA 기능은 민첩한 팀 내에 구축되어이 목표를 달성하는 데 도움이됩니다.

귀하, 프로젝트 책임자, 제품 소유자 및 개발자가 함께 작업하지 않고 개선 계획 (레트로 펙트)이없는 경우 프로세스 이름을 다른 것으로 지정하고 계속 진행하십시오. 팀 문제가 관리자 또는 QA의 결함 인 것으로 보이지 않습니다. 그들은 개발 조직에서 나오는 체계적인 문제에 반응하는 것 같습니다. 팀이 책임을지고 이해 관계자와 협력하기 시작하면 모든 것이 손실되지 않습니다.

세 가지를 시도 할 수 있습니다. 하나, 각 이해 관계자가 간결하게 정의 된 역할을 갖고 각 사람이 자신의 책임을 이해하도록하십시오. 둘째, 빌드를 안정화 한 다음 추가 변경없이 QA에서 승인을받습니다. 셋째, 연구소 테스트 자동화. 품질 보증팀이이를 사랑합니다.

피드백이 너무 오래 걸리는 것이 유감이지만 민첩하게 멈추는 것이 가치가 있다고 생각하지 않습니다. 스프린트 (또는 커플)가 끝나면 시장에 출시 될 수 있다고 확신하는 제품을 출시합니다. 팀의 민첩성은 수행 할 작업에 집중하고 제품을 출시 할 수있는 능력을 제공합니다. 품질 관리팀에서 문제를 발견하면 이러한 문제에 대한 버그 보고서를 작성하고 다음 스프린트에서 우선 순위가 높은 문제를 해결하는 것이 좋습니다.

우리의 제품 현장 테스트에는 8 주가 더 걸리며 외부 재배자에 의존합니다. 그래도 민첩하게 작업을 진행하여 필요한 작업에 집중하고 새로운 버전을 신속하게 제작할 수 있습니다.

QA 부서의 문제는 (눈에 있습니다) 문제를 해결할 수 있습니까? 토론 했어?

12 주가 길지만 QA가 해당 기간 (3 개월 후) 동안 피드백 및 버그 보고서를 제공 할 수 있기를 바랍니다.

그러면 가장 중요한 문제에 민첩하게 대응할 수 있으며 완료되기 전에 모든 문제를 해결할 수 있습니다!

여러 스프린트를 실행하는 동안 QA 직원은 무엇을하고 있습니까? 모든 변경 후에 모든 것을 테스트 할 필요가 있다고 느끼는 것처럼 들립니다 (왜냐하면 전체 변경을 기다리는 이유입니다).

개발 팀은 민첩하지만 나머지 회사는 그렇지 않습니다.

QA를 담당하는 사람은 자신이하는 일을 알지 못하거나 최고 경영진에서 제다이 마인드 트릭을 수행했으며 달콤한 시간을 가질 수 있습니다. 품질 관리는 개발보다 시간이 오래 걸립니까?