Як ви переконали свого керівника дозволити вам пройти тестування?

Під "використанням" я маю на увазі, що мені дозволяють розробляти, перевіряти контроль джерела та підтримувати тестові одиниці з часом тощо

Типові заперечення керівництва:

1. Замовник не платив за одиничні тести
2. Проект не передбачає часу для тестування одиниць
3. Технічна заборгованість? Яка технічна заборгованість?

Чи знаєте ви інші заперечення? Які були ваші відповіді?

Спасибі заздалегідь!

Я зіткнувся з цією проблемою недавно, коли замовник був на борту з нашою методологією, але вище керівництво отримало впевненість, що розробники витрачають свій час на тестування, а не на розробку, і переймаються цим - адже вони мали QA людей для тестування! Я блогів про те, як я тут справився з цим:

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

Підводячи підсумок, я порівняв орієнтовну кількість годин із фактичною кількістю годин на проект, а потім порівняв показник дефектів та показник дефектів інших команд. У нашому випадку ці цифри вигідно порівняні, і проблем більше не було.

Мій висновок на основі цього досвіду:

... найкращий спосіб переконати когось у тому, що ваш підхід до того, щоб зробити щось практичний і прагматичний, - це зробити це і порівняти його з іншими підходами. Людей не хвилює догма, або чому ти вважаєш, що щось має бути найкращим способом. Тільки показуючи людям цифри і вимірюючи ефективність вашого підходу, ви можете по-справжньому показати, що ваші практики ефективні.

В інших проектах ми працювали разом із розробниками клієнтів, які не створювали модульні тести чи TDD, і нам довелося підтримувати тести, які вони порушують. Однак продати підхід TDD тим розробникам клієнтів стає дуже просто, коли ви можете сказати їм, що вони зламали в коді, перш ніж вони дізнаються!

Тож у вашому випадку я б зробив це приховано, якщо це необхідно (можливо, є невелика область коду, яку ви можете почати перевіряти, що часто змінюється, або за яку ви несете відповідальність), але слідкуйте за своїми цифрами - що таке зусилля для створення ваших тестів? Який показник дефекту? Як це порівнюється з іншими проектами / членами команди?

На мою думку, нікому не потрібно просити дозволу чи вибачення за те, що вони хочуть виконати свою роботу належним чином, і будь-який професійний розробник повинен намагатися перевірити свій код за допомогою автоматизованих тестів, де це можливо і практично. Сподіваємось, це обоє речі у вашому випадку. Удачі!

Показати рентабельність інвестицій (ROI)

Написання автоматизованих тестів потребує часу. Раз. Запуск автоматизованих тестів займає нуль часу, тому що ви можете робити щось інше, поки вони працюють.

Приклад. Функція ручного тестування X займає 30 хвилин. Написання автоматизованого тесту на це зайняло б 1 годину. Навіть якщо у нас немає помилок, нам доведеться тестувати функцію X десять разів під час проекту, оскільки його залежні шари та компоненти змінені. Тож автоматизація тесту на функцію X допоможе нам заощадити 4 години протягом життя проекту.

Насправді, коли у вас є помилка, автоматичні тести справді окупаються - По-перше, вони виявляють помилки рано і дешево, що економить час і бентежить. По-друге, якщо у вас є складна помилка і ви пройшли багато циклів тестування коду, щоб зрозуміти це, час, який заощаджується на ручному тестуванні, надзвичайно швидко збільшується.

Підприємства розуміють економію часу та грошей. Ось як продати.

Якщо ви вже стикалися з ними, і з ними все не в порядку, але вам не зручно писати код без них ... тоді не запитайте знову. Просто напишіть їх і не перевіряйте їх.

Керівництво не збирається рахувати рядки коду, але вони побачать, що всі ваші чеки мають більш високі швидкості пропуску від QA (або клієнтів), і в підсумку вони запитають, чому ... тоді ви можете бути схожими на "BAM! TDD" ! "

Ви не вадитесь з проектом, процесом чи джерелом ... тому я не бачу негативної причини. Чесно кажучи, я не бачу причини, чому це відрізняється часом, ніж запускати всі ваші ручні запуски + введення + перевірити результати тестів.

1) Замовник не платив за одиничні тести

Замовник (думав, що вони) заплатив за робоче рішення. Залежно від договорів виправлення недоліків може бути фактично вигідним вашій компанії. Якщо замок достатній. Тому повертаємося до оплати робочого рішення. TDD має допомогти досягти цієї мети.

2) Проект не передбачає часу на TDD

TDD не займає більше часу. Він повинен зменшити кількість стороннього або зайвого коду і зосередити базу коду на тому, що змушує пройти тести. Усі тести, що проходять, залежно від якості та відповідності тесту, означає, що код виконаний.

3) Технічна заборгованість? Яка технічна заборгованість?

У мене складається враження, що ви могли б сперечатися про те, щоб ретроспективно додати тести до існуючого коду. Це кошмар, який продається в найкращі часи, і не приносить користі, яку ви можете очікувати. Однак додавання тестів під час виправлення помилок має бути прийнятним та допомагати в довгостроковій перспективі.

Я не рекомендую писати тести все одно, як запропонував Снорфус. Теоретично це звучить приємно, але одиничні тести можуть і можуть змінюватися з часом. По мірі зміни вимог додаються нові функції, одиничні тести потрібно оновлювати. Якщо ви працюєте в складі команди, ваші одиничні тести застаріють, оскільки інші додають функції / виправлення.

Я звертаюсь до конкретних питань, про які ви згадали, а не піднімаю нові, тому що там є вільний простір, щоб досягти прогресу або зрозуміти, чому це блокування.

Для кожного клієнта, який стикається з виробничими проблемами,

1. Напишіть тест на одиницю та надішліть електронному листу менеджеру повідомлення про те, що ви додали тест на одиницю для висвітлення сценарію.

2. І скажіть йому, що ця проблема більше не повториться у виробництві, тому що наша тестова одиниця працює щоночі, і ми дізнаємось, перш ніж код надійде до виробництва, спостерігаючи про вихід цього тесту з ладу.

3. Скажіть йому, що якби до цього коду було проведено тестування до початку випуску коду, цього питання про виробництво ніколи б не сталося.

Робіть це послідовно і наполегливо і незабаром він переконається. Менеджерам не подобається, що клієнт стикається з виробничими проблемами, і він задумає про тестування підрозділу. Удачі.