(수락) 테스트 주도 개발의 상대적 비용 효율성

소프트웨어 계획에 대한보다 "전통적인"접근 방식과 달리 프로젝트의 요구 사항과 설계가 자동화 된 승인 테스트 및 단위 테스트에 의해 주도되는 소프트웨어 프로젝트에 대한 자원 계획의 전반적인 영향이 무엇인지 알고 싶습니다.

경험상, "전통적인"개발 방법론과 달리 TDD 하에서 소프트웨어 프로젝트를 완료하기위한 자원 요구 사항에 대한 전반적인 영향은 무엇입니까? 테스트가 더 일찍 이루어지기 때문에 품질이 향상되고 불확실성이 감소한다는 것은 자명 한 것 같습니다. 버그를 사전에 제거하여 개발 노력이 얼마나 증가합니까, 아니면 실제로 감소합니까?

고객에게 더 많은 노력이 필요합니까? 특히 대형 디자인에 익숙한 경우 프로젝트와 관련된 방식을 변경해야합니까? 고객에게 필요한 총 시간이 증가합니까, 아니면 실제로 감소합니까?

소프트웨어 개발 계획이 없기 때문에 TDD 프로젝트가 시작될 때 반복적 인 TDD 프로세스에서 시간 추정치가 매우 모호하다고 생각합니다. 프로젝트에 20 %의 포인트가 있는가, 어느 정도 안정적인 시간과 비용 추정이 결국 고객에게 제공 될 수있을 정도로 신뢰가 높아지는가?

참고 : 여기서는 주관적인 의견이나 이론을 찾고 있지 않으므로 추측하지 마십시오. TDD의 실제 경험을 찾고 있습니다.

가장 먼저 언급해야 할 것은 TDD가 소프트웨어의 품질을 반드시 향상 시키지는 않는다는 것입니다 (사용자 관점에서). 총알이 아닙니다. 만병 통치약이 아닙니다. 버그 수를 줄이는 것이 TDD를 수행하는 이유는 아닙니다.

TDD는 더 나은 코드를 생성하기 때문에 주로 수행됩니다. 보다 구체적으로, TDD는 변경하기 쉬운 코드를 생성합니다 .

TDD 사용 여부는 프로젝트 목표에 따라 다릅니다. 이것이 단기 컨설팅 프로젝트입니까? 가동 후 프로젝트를 지원해야합니까? 사소한 프로젝트입니까? 이러한 경우 추가 된 오버 헤드가 가치가 없을 수 있습니다.

그러나 프로젝트에 관련된 시간과 자원이 선형으로 증가함에 따라 TDD의 가치 제안이 기하 급수적으로 증가하는 것은 저의 경험입니다.

좋은 단위 테스트는 다음과 같은 장점을 제공합니다.

1. 단위 테스트는 개발자에게 의도하지 않은 부작용을 경고합니다.
2. 단위 테스트를 통해 구형 시스템에서 새로운 기능을 신속하게 개발할 수 있습니다.
3. 단위 테스트를 통해 새로운 개발자는 코드를 더 빠르고 정확하게 이해할 수 있습니다.

TDD의 부작용은 버그 가 적을 수 있지만 불행히도 대부분의 버그 (특히 가장 불쾌한 버그)는 일반적으로 불분명하거나 열악한 요구 사항으로 인해 발생하거나 반드시 1 차 단위 테스트에서 다루지 않는 것이 내 경험입니다.

요약하면 다음과 같습니다.

버전 1에서의 개발이 느려질 수 있습니다. 버전 2-10에서의 개발이 더 빠릅니다.

테스트 주도 개발에 관한 소프트웨어 제작 에는 여기에서 논의 된 논문을 인용 하는 장이 있습니다 .

사례 연구는 Microsoft의 3 개 개발 팀과 TDD를 채택한 IBM의 한 개발 팀에서 수행되었습니다. 사례 연구의 결과는 4 가지 제품의 시험판 결함 밀도가 TDD 사례를 사용하지 않은 유사한 프로젝트에 비해 40 %에서 90 % 사이로 감소했음을 나타냅니다. 주관적으로, 팀은 TDD를 채택한 후 초기 개발 시간이 15–35 % 증가했습니다.

물론 이러한 결과가 귀하의 사건에 일반화 될 수 있는지 여부는 TDD의 지지자들이 주장 할 것이 분명하며 TDD의 비방 자들이 주장하는 것은 사실이 아닙니다.

나는 당신에게 줄 연구 논문이나 통계가 없지만 역사적으로 평균 단위 테스트 범위가 적고 엔드 투 엔드 테스트가 없었던 팀 / 조직에서 일한 경험을 점차적으로 이야기 할 것입니다. 우리가 ATDD (그러나, 아이러니하게도, 더으로, 지금 위치로 줄 이동 하지 전통적인 TDD) 방식을.

특히, 프로젝트 타임 라인이 어떻게 진행되는지 (그리고 여전히 같은 조직의 다른 팀 / 제품에서 진행되는 방식)입니다.

• 최대 4주의 분석 및 구현
• 2 주간의 회귀 테스트, 버그 수정, 안정화 및 릴리스 준비
• 1-2 주간의 알려진 결함 수정
• 2-3 주간의 코드 정리 및 사후 제작 문제 / 지원 (알 수없는 결함 / 예상치 못한 중단)

이것은 어리석은 오버 헤드 처럼 보이지만 실제로는 매우 흔합니다. 많은 조직에서 종종 품질 보증이 누락되거나 비효율적입니다. 우리는 좋은 테스터와 집중적 인 테스트 문화를 가지고 있기 때문에 이러한 문제는 수개월 / 년에 걸쳐 천천히 진행되는 것이 아니라 초기에 발견되어 (대부분) 미리 해결됩니다. 55-65 %의 유지 보수 오버 헤드는 디버깅에 소요되는 시간의 80 %에 비해 일반적으로 수용되는 표준보다 낮 습니다. 이는 일부 단위 테스트와 부서 간 팀 (QA 포함)을 가지고 있기 때문에 합리적 입니다.

우리 팀이 최신 제품을 처음 출시하는 동안 승인 테스트를 개편하기 시작했지만 제대로 작동하지 않았으며 여전히 많은 수동 테스트에 의존해야했습니다. 릴리스는 우연한 승인 테스트와 다른 프로젝트에 비해 매우 높은 단위 테스트 적용으로 인해 다른 것보다 다소 덜 고통 스럽습니다. 그러나 우리는 거의 2 주 동안 회귀 / 안정화에, 2 주 동안 후반 작업 문제에 썼습니다.

반대로, 최초 릴리스 이후의 모든 릴리스 에는 초기 승인 기준과 승인 테스트가 있었으며 현재 반복은 다음과 같습니다.

• 8 일간의 분석 및 구현
• 안정화 2 일
• 0 ~ 2 일의 후반 작업 지원 및 정리

즉, 유지 보수 오버 헤드 55-65 %에서 유지 보수 오버 헤드 20-30 %로 진행했습니다. 동일한 팀, 동일한 제품, 주요 차이점은 승인 테스트의 점진적인 개선 및 간소화입니다.

유지 보수 비용은 스프린트 당 QA 분석가의 경우 3-5 일, 개발자의 경우 1-2 일입니다. Google 팀에는 4 명의 개발자와 2 명의 QA 분석가가 있습니다 (UX, 프로젝트 관리 등은 제외). 60 일 중 최대 7 일이며, 15 %의 구현 오버 헤드로 반올림합니다. 안전한면.

우리는 각 릴리스 기간의 15 %를 자동화 된 승인 테스트 개발에 사용하며,이 과정에서 각 릴리스의 70 %를 회귀 테스트를 수행하고 사전 프로덕션 및 사후 프로덕션 버그를 수정할 수 있습니다.

두 번째 타임 라인이 첫 번째 타임 라인보다 훨씬 정확하고 짧다는 것을 알았을 것입니다. 그것은 사전 승인 기준과 승인 테스트에 의해 가능해진 것입니다. "완료된 정의"를 크게 단순화하고 릴리스의 안정성에 훨씬 더 자신감을 가질 수 있기 때문입니다. 아주 사소한 유지 보수 릴리스 (버그 수정 전용 등)를 수행하는 경우를 제외하고 다른 팀은 지금까지 격주 릴리스 일정에 성공하지 못했습니다.

또 다른 흥미로운 부작용은 출시 일정을 비즈니스 요구에 맞게 조정할 수 있다는 것입니다. 한 번은 다른 릴리스와 일치시키기 위해 약 3 주로 연장해야했으며 더 많은 기능을 제공하면서도 테스트 나 안정화에 추가 시간을 소비하지 않고도 그렇게 할 수있었습니다. 또 다른 시간, 우리는 공휴일과 자원 충돌로 인해 약 1½ 주로 단축해야했습니다. 우리는 더 적은 개발 작업을 수행해야했지만 예상대로 새로운 결함을 도입하지 않고도 테스트 및 안정화에 더 적은 시간을 소비 할 수있었습니다.

내 경험상, 특히 프로젝트 나 스프린트에서 매우 초기에 수행 될 때, 그리고 제품 소유자가 작성한 승인 기준으로 잘 유지 될 때의 합격 테스트는 여러분이 할 수있는 최고의 투자 중 하나입니다. 다른 사람들이 올바르게 지적하는 기존의 TDD와 달리 결함이없는 코드 보다 테스트 가능한 코드 를 만드는 데 더 중점을 둡니다. ATDD는 실제로 결함 을 훨씬 빨리 포착 하는 데 도움이됩니다 . 그것은 매일 완전한 회귀 테스트를 수행하는 테스터 군대를 보유하는 것과 동등한 조직이지만 훨씬 저렴합니다.

ATDD는 RUP 또는 폭포 스타일의 3 개월 이상 지속되는 장기 프로젝트에서 도움이 되나요? 배심원은 여전히 ​​저쪽에 있다고 생각합니다. 내 경험상 장기 실행 프로젝트에서 가장 크고 추악한 위험은 비현실적인 마감일과 변화하는 요구 사항입니다. 비현실적인 마감일로 인해 바로 가기 테스트를 포함하여 바로 가기를 수행하게되며 요구 사항을 크게 변경하면 많은 테스트가 무효화되어 다시 작성해야하고 구현 오버 헤드가 발생할 수 있습니다.

ATDD는 애자일 모델이나 공식적으로 애자일은 아니지만 출시 일정이 매우 빈발 한 팀에게 환상적인 보상을 제공 할 것입니다. 나는 장기 프로젝트에서 그것을 시도한 적이 없다. 주로 그런 종류의 프로젝트에서 기꺼이 시도하려는 조직에 대해 들어 본 적이 없거나 들어 본 적이 없기 때문에 표준 면책 조항을 여기에 삽입하십시오. YMMV와 그 모든 것.

PS이 경우 "고객"의 추가 노력이 필요하지 않지만 실제로 승인 기준을 작성하는 전담 풀 타임 제품 소유자가 있습니다. "컨설팅웨어"비즈니스에 종사하고 있다면 최종 사용자 가 유용한 승인 기준을 작성 하는 것이 훨씬 어려울 수 있습니다 . ATDD를 수행하기 위해서는 제품 소유자 / 제품 관리자가 매우 중요한 요소 인 것 같습니다. 다시 한 번 본인의 경험을 통해서만 말할 수는 있지만 ATDD가 그 역할을 수행 할 사람이 없이도 성공적으로 수행되는 것을 들어 본 적이 없습니다.

자원 요구 사항

경험상, "전통적인"개발 방법론과 달리 TDD 하에서 소프트웨어 프로젝트를 완료하기위한 자원 요구 사항에 대한 전반적인 영향은 무엇입니까?

필자의 경험에 따르면 사전 테스트 요구 비용은 명확한 승인 기준을 미리 정의한 다음 테스트에 작성함으로써 즉시 완화됩니다. 사전 테스트 비용이 완화되었을뿐만 아니라 전반적인 개발 속도가 빨라지는 것을 알았습니다. 프로젝트 속도가 나쁘거나 요구 사항이 변경되면 이러한 속도 향상이 사라질 수 있습니다. 그러나, 우리는 여전히 심각한 영향없이 그러한 종류의 변화에 ​​상당히 잘 대응할 수 있습니다. 또한 ATDD는 다음과 같은 경우 자동화 된 테스트 스위트를 통해 올바른 시스템 동작을 확인하는 개발자의 노력을 크게 줄입니다.

• 큰 리 팩터
• 플랫폼 / 패키지 업그레이드
• 플랫폼 마이그레이션
• 툴체인 업그레이드

이것은 관련된 프로세스와 관행에 익숙한 팀을 가정합니다.

고객 참여

고객에게 더 많은 노력이 필요합니까?

그들은 지속적으로 훨씬 더 관여해야합니다. 초기 투자 비용이 크게 줄었지만 훨씬 더 많은 수요가 진행되고 있습니다. 측정하지는 않았지만 고객에게 더 많은 시간을 투자 할 것이라고 확신합니다.

그러나 5 번 정도의 데모를 통해 소프트웨어 관계가 서서히 개선되는 모습을 보인 이후 고객 관계가 크게 개선되는 것을 발견했습니다. 모든 사람들이 프로세스에 익숙해지고 관련 기대치가 높아 지므로 고객의 시간 약속은 시간이 지남에 따라 다소 줄어 듭니다.

프로젝트 견적

소프트웨어 개발 계획이 없기 때문에 TDD 프로젝트가 시작될 때 반복적 인 TDD 프로세스에서 시간 추정치가 매우 모호하다고 생각합니다.

나는 보통 그 요청이 얼마나 잘 정의되어 있는지, 그리고 기술 리드 (들)가 프로젝트를 카드 출력 (카드 평가 포함) 할 수 있는지에 대한 질문이라는 것을 알았습니다. 프로젝트가 잘 정돈되어 있고 합리적인 속도 평균과 표준 편차가 있다고 가정하면 적절한 추정치를 얻는 것이 쉽다는 것을 알았습니다. 분명히 프로젝트가 클수록 불확실성이 커지므로 나중에 계속하겠다는 약속으로 큰 프로젝트를 작은 프로젝트로 나눕니다. 고객과의 관계를 설정하면 훨씬 쉽게 수행 할 수 있습니다.

예를 들면 다음과 같습니다.

우리 팀의 "스프린트"는 일주일 정도이며 평균과 표준이 있습니다. 지난 14주의 편차. 프로젝트가 120 점이면 평균은 25이고 표준입니다. 6의 편차는 프로젝트의 완료를 추정하는 것입니다 :

Project Total / (Mean Velocity - (2 * Std. Deviation) = 95% Time Estimate
120           / (25            - (2 * 6             ) = 9.2 weeks

우리는 2 Std를 사용합니다. 95 % 신뢰 추정치에 대한 편차 규칙. 실제로 우리는 일반적으로 첫 번째 표준에 따라 프로젝트를 완료합니다. 편차, 그러나 우리의 평균 이상. 이것은 일반적으로 개선, 변경 등으로 인한 것입니다.

테스트를 미리 요구하는 데 더 많은 개발자 시간이 필요한 것 같습니다. 버그를 사전에 제거하여 개발 노력이 얼마나 증가합니까, 아니면 실제로 감소합니까?

이것은 사실이 아닙니다. 개발자가 단위 테스트를 작성하는 경우 시간이 거의 같아야합니다. 코드가 완전히 테스트되므로 요구 사항을 충족하기 위해 코드 만 작성해야하기 때문에 더 잘 말했습니다.

개발자의 문제점은 소프트웨어를 가능한 한 일반적으로 만들 필요가없는 것조차 구현하는 경향이 있다는 것입니다.

고객에게 더 많은 노력이 필요합니까? 특히 대형 디자인에 익숙한 경우 프로젝트와 관련된 방식을 변경해야합니까? 고객에게 필요한 총 시간이 증가합니까, 아니면 실제로 감소합니까?

그것은 중요하지 않습니다. 요구 사항을 수행하는 사람은 가능한 한 잘해야합니다.

민첩한 개발 방식을 사용한다고해서 큰 디자인이 먼저 시작되는 것은 아닙니다. 그러나 요구 사항, 아키텍처 및 디자인이 더 잘 수행되면 코드 품질이 향상되고 소프트웨어 완료 시간이 단축됩니다.

그러므로 그들이 BDUF를하고 싶다면 그렇게하십시오. 개발자로서 당신의 인생을 더 쉽게 만들어 줄 것입니다.