개발과 QA 간 지연 시간이 길다

현재 위치에서 품질 관리는 병목 현상이되었습니다. QA가 테스트를 완료 할 수 있도록 현재 빌드에서 보류중인 기능이 유감스럽게 발생했습니다. 즉, 개발중인 기능은 개발자가 이미 이동 한 후 2-3 주 동안 테스트되지 않을 수 있습니다. 개발자가 QA를 빠르게 진행함에 따라이 시간 간격은 점점 커질 것입니다.

코드 완성 사본을 계속 살펴보면서 결함 수정 비용이 기하 급수적으로 증가하는 것을 보여주는 "하드 데이터"스 니펫을 찾습니다. 누군가이 개념을 뒷받침하는 연구를 알려 줄 수 있습니까? 품질 보증 병목 현상이 생각보다 훨씬 비싸다는 힘을 확신하려고합니다.

IMHO 참조가 필요하지 않습니다. 여기에 당신이 (오히려 수 무엇을 해야 ) 할 :

지연 비용을 수량화하십시오! 기능을 테스트하는 데 1 주일이 걸린다고 가정 해 봅시다. 2-3 주 지연은 해당 기능을 최소한 4 주까지 사용할 수 없음을 의미합니다. 그리고 그것도 100 % 성공을 가정합니다. 약 5주의 지연이되도록 다른 주에 고정 시간을 추가하십시오.

가능하면 프로젝트 / 기능의 예상 마감일에 액세스하십시오. 클라이언트는 언제 그것을 기대합니까? 미끄러질까요? 그렇지 않다면 다른 사람들이 결과적으로 미끄러질 것인가? 결과적으로 '릴리스'가 얼마나 지연 될까요?

해당 릴리스의 '회사에 대한 비용'은 무엇입니까? 즉, 클라이언트가 해당 릴리스에서 얼마나 많은 수익을 기대합니까? 그들이 그 릴리스에서 5200 달러 / 년의 이익을 기대한다면 매주 비용이 100 달러 감소하여 매출 손실이 발생합니다. 이것이 클라이언트 관점입니다. 이 데이터에 액세스 할 수도 있고 액세스하지 않을 수도 있지만 지연이 관계에 미치는 영향을 고려해야합니다.

이제 개발자에게 어떤 손실이 있습니까? 개발자가 다른 기능으로 넘어 가면주기를 중단하고 이전 기능을 '수정'하도록 요청합니다. 시간 / 노력 상실은 무엇입니까? 결과적으로 낭비되는 시간당 급여를 배수로 사용하여 회사에 비용으로 전환합니다. 이것을 사용하여 폐기물이 "먹고있는" "수익 / 수익"의 양을 말할 수 있습니다.

당신이 우연히 만난 것은 제품 개발 흐름의 원칙에서 Don Reinerstein과 Agile Software Requirements의 Dean Leffingwell이 주장한 "지연 비용 (Cost of Delay)"을 사용하여 편리하게 정량화 할 수 있습니다. 경제적 인 요인으로 그러한 모든 주장을 뒷받침 할 수 있어야하며 기본 언어가 $$ 인 '더 높은 힘' 을 설득 할 수 있어야합니다.

행운의 짐승! (pun 의도 :)

Code Complete 가 여기에 적합한 리소스 라고 생각하지 않습니다 . 이것은 코드 문제가 아니며 프로세스 문제이며 관리 문제 일 수 있습니다.

프로세스의 일부가 특히 약한 경우 제약 이론 을 정리할 차례 입니다 .

1. 구속 조건을 식별하십시오.

   이는 전체 프로세스에서 가장 느리거나 비효율적 인 부분을 찾는 것을 의미합니다. 귀하의 경우 테스트 중입니다. 그러나 테스트의 어떤 부분 입니까? 그렇습니까?

   • 테스트 환경을 준비하고 있습니까?
   • 무엇을 테스트해야합니까?
   • 기능 (수락) 테스트?
   • 회귀 테스트?
   • 탐사 테스트?
   • 테스트에서 버그 / 결함을보고합니까?
   • 버그를 재현하는 단계를 결정하고 있습니까?
   • 개발자 또는 프로젝트 관리자로부터 설명을 받고 있습니까?
   • 품질 관리 단계에서 발견 된 문제를 해결 하시겠습니까?

   이것들은 모두 매우 다른 문제이며 다른 해결책을 요구합니다. 가장 비싼 / 중요한 것을 결정해야합니다. 위의 모든 활동에 시간 (AKA 머니)이 소요되고 그 중 두 개만 부가가치 시간이기 때문에 경영진에게 정당화하는 것이 어렵지 않아야합니다.

2. 구속 조건을 이용하십시오.

   즉, 최적화 주위 구속 과정. 테스터를 유휴 상태로 두지 마십시오. 이것은 본질적으로 다음과 같습니다.

   • 테스터 퍼팅 내부 가 아닌 경우 개발 팀, 그래서 개발자들과 지속적인 피드백 루프가있다.
   • 테스트 배포가 빈번하므로 테스트 할 새로운 사항이 항상 있습니다.
   • 보다 빠르고 빈번한 의사 소통 예를 들어, 이메일 스레드보다 인스턴트 메시징을 선호합니다.
   • 테스터가 사용 가능한 최상의 도구 (빠른 기계, 다중 모니터, 간소화 된 버그 추적 등)를 갖도록 보장

   이 단계는 테스트 프로세스 자체를 최적화하는 것이 아니라 오버 헤드를 줄이는 것입니다. 테스터의 시간을 낭비하지 마십시오. 낭비되는 시간을 없애는 것도 경영진에게 쉽게 팔리는 것이되어야합니다.

3. 제약 조건에 다른 활동을 종속시킵니다.

   이 시점에서 테스터는 가능한 한 생산성이 높으므로 다른 영역에서 생산성을 빌려야합니다.

   • 개발자와 운영 직원에게 테스터에게 우선 순위를 부여하도록 지시하십시오.
   • 다기능 팀이없는 경우 테스터가 매일 예약 시간을 낭비하지 않도록 미리 설정된 시간에 매일 회의실을 예약하십시오.
   • 기능 작업에서 개발자 (및 가능한 경우) 시간의 더 큰 비율을 전환하십시오. 예를 들어, 버그 수정, 기술 부채 / 리팩토링, 코드 검토 및 단위 테스트에 중점을 둡니다.
   • 지속적이고 점진적으로 테스트 – 3 주 동안 개발하지 말고 테스터에게 전달하십시오. 개발자가 스캐 폴딩 또는 프로토 타입 UI와 같이 코드를 즉시 테스트 할 수 있도록 노력하십시오.

4. 구속 조건을 높이십시오.

   테스터가 생산성과 최소한의 오버 헤드 측면에서 최대 용량으로 작업하고 있고 여전히 빠르지 않은 경우 테스트에 더 많은 투자를 시작해야합니다.

   • 수동 테스트 배포에 의존하는 경우 지속적인 통합 및 구성 관리 스크립트를 사용하여 자동화하십시오.
   • 테스트 계획을 작성하는 데 시간이 오래 걸리면 더 나은 승인 기준 (예 : INVEST ) 을 얻는 데 노력하십시오 . 대부분의 조직은 처음에 이것에 매우 나쁩니다.
   • 합격 시험이 너무 오래 걸리면 자동화를 시작하십시오. Cucumber 또는 FitNesse와 같은 도구를 사용하거나 필요한 경우 xUnit 유형 테스트를 작성하십시오. UI 테스트에 오랜 시간이 걸리면 Selenium, Watij 및 기타 브라우저 자동화 도구도 있습니다.
   • 회귀 테스트에 시간이 너무 오래 걸리면이를 자동화하십시오. 자동화 할 수없는 경우, 코드 검토, 단위 테스트, 정적 분석 도구 등에 더욱 중점을 두어 게이트 외부의 품질 향상에 중점을 둡니다. 개발자는 통과하기 전에 실제 버그 가 거의 없다고 확신해야 합니다. 품질 보증에 (제품 결함은 다른 이야기입니다).
   • 탐색 테스트가 병목 현상 인 경우 릴리스 이후까지 일부를 연기하거나 테스트 브라우저와 계약을 맺어 여러 브라우저에서 동일한 워크 플로를 테스트하는 것과 같이 고도로 병렬 가능한 작업을 수행 할 수 있습니다.
   • 테스터가 많은 버그를 재현 할 수없는 경우 간헐적 인 오류를 재현 할 수 있도록 용량 테스트 환경을 구축하는 것이 좋습니다. 또는 자동화 된 승인 테스트를 하루 종일 병렬로 지속적으로 실행하여 자세한 로그를 유지하십시오.
   • 버그를 수정하는 데 시간이 오래 걸리면 프로젝트 분할을 시작하거나 솔루션 재구성을 진지하게 고려하십시오. 또는 대안으로 일부를 수정하지 마십시오. 모든 버그가 중요하지는 않지만 기능 작업과 함께 우선 순위를 지정할 수 있어야합니다.
   • 다른 모든 방법이 실패하면 더 많은 테스터를 고용하십시오.

5. 1 단계로 돌아갑니다.

나는 이것이 모든 상식이라고 말하고 싶지만 불행히도 적어도 대부분의 조직에서는 그렇지 않습니다. 경영진으로부터 많은 저항을 받고 있다면, 귀중한 기술은 Value Stream Mapping (린 제조 기술)로, 릴리스 후보가 매일 얼마나 많은 시간과 비용을 낭비하고 있는지 실제로 보여주는 데 사용할 수 있습니다. 다음 단계로 넘어갑니다. 기회 비용은 이해하기 어렵지만 이것이 시각화하고 시연하는 가장 좋은 방법 중 하나입니다.

그리고 그 중 어느 것도 효과 가 없다면 ... 아마도 당신은 역기능 회사에 있고, 너무 늦기 전에 나가십시오!

그러나 관리자의 책상에 몇 가지 서류를 버리고 문제에 돈을 던져달라고 요청하는 것만으로는이 문제를 해결할 수는 없습니다. 왜냐하면 돈을 던지면 실제로 해결하지 못할 수도 있고 심지어 더 나쁘다. 솔루션 을 제공해야합니다 . 이것이 바로이 답변입니다. "우리는 더 많은 테스터가 필요하다"가 아니라 "이 문제를 해결할 수있는 방법의 목록이 있습니다. 비용 / 이익의 내림차순으로"문제를 소개하면 훨씬 더 많은 성공을 거둘 수 있습니다.

후속 조치가 필요할 수도 있지만 페이지 29 및 30에 원하는 데이터가있을 수 있습니다.

30 페이지의이 문장에서 언급 한 연구를 살펴 보겠습니다.

수십 개의 회사는 프로젝트의 후반부보다 결함을 바로 잡는 데 초점을 맞추는 것만으로도 개발 비용과 일정을 둘 이상의 요인으로 줄일 수 있다는 사실을 발견했습니다 (McConnell 2004).

BTW, 그것은 당신의 질문이었습니다.

당신이 설명하는 것은 프로세스의 병목 현상입니다. 린 이론은 프로세스에 항상 병목 현상이 발생하지만 심각도는 크게 다를 수 있다고 말합니다. QA가 추가로 하나를 고용하면 개발에 병목 현상이 발생할 수 있습니다.

비용을 이해하려면 다음 상황을 상상하십시오. 개발자 중 하나를 선택했습니다. 그의 작품은 결코 품질 보증이되지 않지만 항상 무기한 대기합니다. QA가 나머지 개발자의 작업을 적시에 보장 할 수 있으며 지연 비용이 들지 않는다는 것을 의미한다고 상상해보십시오.

이 시나리오에서 지연 비용은 개발자의 업무 비용이 낭비되기 때문에 개발자의 급여 비용입니다.

프로세스가 창출 한 가치가 아니라 비용 측면에서 논쟁하는 이유는 프로세스의 가치가 훨씬 우수하더라도 프로세스의 가치를 문서화하기가 더 어렵 기 때문입니다.

코드 완성 사본을 계속 살펴보면서 결함 수정 비용이 기하 급수적으로 증가하는 것을 보여주는 "하드 데이터"스 니펫을 찾습니다. 누군가이 개념을 뒷받침하는 연구를 알려 줄 수 있습니까?

버그를 찾는 기하 급수적 인 비용은 NIST 연구에 근거한 것으로 보인다 . 이 조사는 별도의 폭포 단계를 가정 한 설문 조사였습니다.

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( 여기에서 여기 표 )

애자일 소프트웨어 개발 방법론의 목표 중 하나는 이러한 고유 한 단계를 제거하고 비용을 줄이는 것입니다. 폭포수에 다른 방법론을 사용할 때는 수치가 적용되지 않습니다.

귀하의 probelm은 QA를 사용하지 않습니다. 실제로 QA가 테스트를 수행하는 경우 지연이 거의 걱정하지 않습니다. (프로그래밍 업계에서 일반적인 오해이므로 다시 설명하겠습니다) ... QA 요구 사항 (이전의 경우)에서 개발, 검증, 릴리스 및 지원을 통해 전체 SDLC를 감독하여 제품의 품질을 보장합니다. 테스트는 코드에 명백한 결함이 없는지 확인합니다. 매우 크고 중요한 차이점이 있습니다. 만약 당신이 진정한 QA를 가지고 있다면, 그들은 시험 / V & V 부서 전체에 그들이 왜 사업 시간 (그리고 따라서 돈)을 지연시키는 데 시간을 소비하고 있는지, 또는 프로젝트 일정을 제대로 관리하고 있었거나 또는 모든 관리 결정을했기 때문에 프로젝트 관리에 대한 비용을 지불해야하는 이유를 물었습니다. 코드 생성을위한 테스터가 충분히 있는지 확인하십시오.

따라서 QA에 의해 가정하면 실제로 원래 질문으로 돌아가서 테스트를 의미합니다. Code Complete가 제대로 해냈습니다. 결함 비용은 삽입에서 수정까지 걸리는 시간입니다. 조기 발견은 조기에 정정하는 경우에만 유용하지만 대부분의 사람들의 해석은 틀립니다.

(참고 : 나는 여기서 악마 옹호자를 연주하고 있는데, 나는 당신의 상황을 전혀 알지 못하므로 문자 그대로 사용하지 마십시오.) 테스트 부서의 지연 원인은 비용이지만, 당신이 그들이 당신의 결함을 발견하기를 기다리고, 당신은 무엇을하고 있습니까-당신은 자신의 결함을 발견하지 않아야합니까? 아마도 그들이 더 적은 결함으로 더 높은 품질의 입력을 통해 작업량이 적었다면, 지연은 그다지 중요하지 않으며 비용도 줄어 듭니다. 테스트 (자신의 주장에 근거한)에 따라 테스트에 의해 발견 된 결함은 더 많은 비용이 듭니다.

또한 관리자로서, 테스트 작업이 결함을 찾는 것이 아니라고 말할 수도 있습니다. 결함이 없음을 찾는 것입니다. 결함을 찾을 것으로 예상되는 경우 작업을 충분히 수행하지 않았을 수 있습니다.

당신이 이것에 어떻게 접근하는지주의하십시오. 문제에 대한 해결책이 없으면 두 번째로 나올 가능성이 높습니다.