관리자에게 단위 테스트를하도록 어떻게 확신 시켰습니까?

"사용"이란 시간이 지남에 따라 개발, 소스 제어 체크인 및 단위 테스트 유지 등을 의미합니다.

일반적인 관리 이의 제기는 다음과 같습니다.

1. 고객이 단위 테스트 비용을 지불하지 않았습니다
2. 이 프로젝트는 단위 테스트 시간을 허용하지 않습니다
3. 기술 부채? 어떤 기술적 부채?

다른 반대 의견을 알고 있습니까? 당신의 대답은 무엇입니까?

미리 감사드립니다!

최근 고객이 우리의 방법론에 익숙해 졌을 때이 문제에 부딪 쳤지 만, 높은 경영진은 개발자가 개발하는 대신 테스트에 시간을 소비하고 있다는 것에 관심을 갖게되었습니다. 여기에서 어떻게 처리했는지 블로그에 올렸습니다.

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

요약하자면, 예상 시간을 프로젝트의 실제 시간과 비교 한 다음 결함 비율을 다른 팀의 결함 비율과 비교했습니다. 우리의 경우 이러한 숫자는 호의적으로 비교되었으며 더 이상 걱정하지 않았습니다.

이 경험을 바탕으로 한 나의 결론은 다음과 같습니다.

... 어떤 일을하는 당신의 접근 방식이 실용적이고 실용적이라는 것을 다른 사람에게 설득하는 가장 좋은 방법은 그것을 수행하고 다른 접근 방식과 비교하여 측정하는 것입니다. 사람들은 교리에 신경 쓰지 않거나 왜 무언가가 최선의 방법이라고 생각하는지에 관심이 없습니다. 사람들에게 숫자를 보여주고 접근의 효과를 측정하는 것만으로도 당신의 관행이 효과적이라는 것을 보여줄 수 있습니다.

다른 프로젝트에서는 단위 테스트를 만들지 않았거나 TDD를 수행하지 않은 고객 개발자와 함께 작업했으며 중단 된 테스트를 유지해야했습니다. 그러나 고객 개발자가 코드에 무엇이 잘못되었는지 알기 전에 고객에게 TDD 방식을 판매하는 것이 매우 쉬워졌습니다!

하지만, 필요한 (아마 자주하거나 책임이 있음을 변경 테스트를 시작할 수있는 코드의 작은 영역이) 경우에 따라서 귀하의 경우에, 나는 스텔스에 의해 그것을 할 것입니다 귀하의 번호를 추적 무엇가있다가 - 테스트 작성을위한 노력? 결함률은 얼마입니까? 이것은 다른 프로젝트 / 팀원과 어떻게 비교됩니까?

제 생각에는 아무도 자신의 업무를 제대로 수행하기 위해 허가를 요청하거나 사과 할 필요가 없으며 전문 개발자는 가능하고 실용적인 곳이라면 어디에서나 자동화 된 테스트로 코드를 테스트하려고 시도해야합니다. 희망적으로 그것은 귀하의 경우 에이 두 가지입니다. 행운을 빕니다!

투자 수익률 (ROI) 표시

자동 테스트를 작성하려면 시간이 걸립니다. 한번. 자동화 된 테스트를 실행하면 실행 중에 다른 작업을 수행 할 수 있으므로 시간이 걸리지 않습니다.

예 : 기능 X를 수동으로 테스트하는 데 30 분이 걸립니다. 자동 테스트를 작성하려면 1 시간이 걸립니다. 버그가 없더라도 프로젝트 진행 중에 종속 레이어와 구성 요소가 수정되므로 기능 X를 10 번 테스트해야합니다. 따라서 피처 X 테스트를 자동화하면 프로젝트 수명 기간 동안 4 시간이 절약됩니다.

실제로, 자동화 된 테스트가 실제로 비용을 지불하는 버그가있는 경우-먼저 버그를 조기에 저렴하게 발견하므로 시간과 당황을 줄일 수 있습니다. 둘째, 어려운 버그가 있고 코드 빌드 테스트의 여러주기를 거쳐이를 파악하면 수동 테스트보다 시간이 엄청나게 빨라집니다.

기업은 시간과 비용 절약을 이해합니다. 그것이 그것을 판매하는 방법입니다.

이미 문제에 직면했지만 문제가 없지만 코드가 없으면 편안하게 코드를 작성하는 것이 불편한 경우에는 다시 묻지 마십시오. 그냥 작성하고 체크인하지 마십시오.

경영진은 코드 라인을 세지 않을 것이지만, 모든 체크인은 QA (또는 고객)의 통과율이 더 높으며 결국 이유를 묻습니다 ... 그러면 "BAM! TDD! ! "

프로젝트, 프로세스 또는 소스를 엉망으로 만들지 않으므로 부정적인 이유가 없습니다. 솔직히 모든 수동 실행 + 입력 + 검사 결과 테스트를 실행하는 것과 시간이 다른 이유를 알 수 없습니다.

1) 고객이 단위 테스트 비용을 지불하지 않았습니다.

고객은 그들이 생각한 솔루션에 대한 비용을 지불했습니다. 계약에 따라 결함을 수정하면 실제로 회사에 이익이 될 수 있습니다. 잠금이 충분하면 작업 솔루션 비용을 지불하십시오. TDD는 그 목표를 지원해야합니다.

2) 프로젝트는 TDD 시간을 허용하지 않습니다

TDD는 더 오래 걸리지 않습니다. 외부 코드 또는 불필요한 코드의 양을 줄이고 테스트를 통과시키는 대상에 코드 기반을 집중시켜야합니다. 테스트 품질과 적합성에 따라 모든 테스트 통과는 코드가 완료되었음을 의미합니다.

3) 기술 부채? 어떤 기술적 부채?

기존 코드에 소급하여 테스트를 추가한다고 주장 할 수도 있습니다. 이것은 최고의 악몽 판매이며 기대할 수있는 혜택을 가져 오지 않습니다. 그러나 버그를 수정할 때 테스트를 추가하는 것은 허용되며 장기적으로 도움이됩니다.

어쨌든 Snorfus가 제안한대로 테스트를 작성하지 않는 것이 좋습니다. 그것은 이론적으로 좋은 소리를하지만, 단위 테스트 할 수 와 할 시간이 지남에 따라 변화합니다. 요구 사항이 변경되면 새로운 기능이 추가되어 단위 테스트를 업데이트해야합니다. 팀의 일원으로 일하는 경우 다른 사람들이 기능 / 수정 사항을 추가하면 단위 테스트가 만료됩니다.

나는 당신이 언급 한 특정 요점을 다루고 있는데, 왜 그것이 진척되지 않았는지 이해하거나 발전시킬 여지가 있기 때문입니다.

생산 문제에 직면 한 모든 고객에게

1. 단위 테스트를 작성하고 시나리오를 다루기 위해 단위 테스트를 추가했다는 이메일을 관리자에게 보냅니다.

2. 또한 단위 테스트가 야간에 실행되므로이 ​​문제는 프로덕션에서 다시 발생하지 않으며이 단위 테스트 실패를 관찰하여 코드가 프로덕션에 들어가기 전에 알게 될 것입니다.

3. 코드가 생산되기 전에이 단위 테스트를 이미 실시했다면이 생산 문제는 발생하지 않았을 것입니다.

이를 일관되고 지속적으로 그리고 곧 확신하십시오. 관리자는 고객이 생산 문제에 직면하는 것을 좋아하지 않으며 단위 테스트 아이디어를 구매할 것입니다. 행운을 빕니다.