Я не маю жодних дослідницьких робіт чи статистики, які б вам надавав, але я передам свій досвід роботи в команді / організації, яка історично мала низький середній рівень тестового покриття та не була проведена тестами, і поступово переміщуючи планку туди, де ми зараз, з більшою кількістю підходів ATDD (але, як це не дивно, не традиційний TDD).
Зокрема, ось так, як графіки проекту використовувались для розігрування (і досі відтворюються для інших команд / продуктів тієї самої організації):
- До 4 тижнів аналізу та впровадження
- 2 тижні регресійного тестування, виправлення помилок, стабілізація та підготовка до випуску
- 1-2 тижні виправлення відомих дефектів
- 2-3 тижні очищення коду та проблеми післяпродажної підтримки (невідомі дефекти / незаплановані відключення)
Це здається смішним накладними, але насправді це дуже часто, його часто маскують у багатьох організаціях відсутнім або неефективним КЯ. У нас є хороші тестери і культура інтенсивного тестування, тому ці питання вирішуються рано та вирішуються на фронт (більшу частину часу), а не дозволяють їм повільно грати протягом багатьох місяців / років. 55-65% накладних витрат нижче, ніж загальновизнана норма 80% часу, витраченого на налагодження - що здається розумним, оскільки у нас були деякі одиничні тести та багатофункціональні команди (включаючи QA).
Під час першого випуску нашого останнього продукту нашою командою ми розпочали модернізацію приймальних тестів, але вони були не зовсім придатними для нюху, і нам все одно довелося розраховувати на багато ручних тестувань. Випуск був дещо менш болісним, ніж інші, IMO почасти через наші випадкові тести прийняття, а також частково через наш дуже високий рівень тестового покриття щодо інших проектів. Тим не менш, ми витратили майже 2 тижні на регресію / стабілізацію і 2 тижні на питання після виробництва.
На відміну від цього, кожен випуск з моменту початкового випуску мав ранні критерії прийняття та тести прийняття, і наші поточні ітерації виглядають приблизно так:
- 8 днів аналізу та впровадження
- 2 дні стабілізації
- 0-2 комбіновані дні післяпродукційної підтримки та очищення
Іншими словами, ми прогресували від 55-65% накладних витрат до 20-30% накладних витрат. Один і той же колектив, той самий продукт, головна відмінність полягає в прогресивному вдосконаленні та впорядкуванні наших тестів на прийняття.
Витрати на їх утримання складають, за спринт, 3-5 днів для аналітика якості та 1-2 дня для розробника. У нашій команді є 4 розробники та 2 аналітики щодо якості, так що (не рахуючи UX, управління проектами тощо), це максимум 7 робочих днів із 60, що я обійду до 15% витрат на реалізацію лише для того, щоб бути на безпечна сторона.
Ми витрачаємо 15% кожного періоду випуску, розробляючи автоматизовані тести прийняття, і в процесі цього ми можемо скоротити 70% кожного випуску, роблячи тести регресії та виправляючи помилки перед виробництвом та після виробництва.
Можливо, ви помітили, що друга часова шкала набагато точніша, а також набагато коротша, ніж перша. Це стало можливим завдяки попереднім критеріям приймання та тестам на прийняття, оскільки це значно спрощує "визначення зробленого" та дозволяє нам бути впевненішими у стабільності випуску. Жодна інша команда (поки що) не досягла успіху з розкладом випуску на два тижні, за винятком можливо, коли робили досить тривіальні випуски технічного обслуговування (лише для виправлення помилок тощо).
Ще одним цікавим побічним ефектом є те, що нам вдалося адаптувати наш графік випуску до потреб бізнесу. Одного разу нам довелося подовжити його приблизно на 3 тижні, щоб збігтися з іншим випуском, і ми змогли це зробити, надаючи більше функціональності, але не витрачаючи зайвого часу на тестування або стабілізацію. В інший раз, нам довелося скоротити його приблизно до півтори тижня через свята та конфлікти з ресурсами; нам довелося брати на себе менше роботи, але, як очікувалося, ми змогли витратити відповідно менше часу на тестування та стабілізацію, не вводячи нових дефектів.
На мій досвід, тести прийняття, особливо коли зроблено дуже рано в проекті або спринті, і коли добре дотримуються критерії прийняття, написані Власником продукту, є однією з найкращих інвестицій, які можна зробити. На відміну від традиційного TDD, який інші люди правильно зазначають, зосереджений більше на створенні тестового коду, ніж бездефектного коду - ATDD дійсно допомагає виправити дефекти набагато швидше; це організаційний еквівалент наявності армії тестерів, які щодня роблять повний тест на регресію, але набагато дешевше.
Чи допоможе вам ATDD у довгострокових проектах, виконаних у стилі RUP або (ugh) Водоспад, проектах тривалістю 3 місяці і більше? Я думаю, що присяжне все ще не в цьому. На мій досвід, найбільші та найгубніші ризики у тривалих проектах - це нереальні терміни та зміни вимог. Нереалістичні терміни змусять людей приймати ярлики, включаючи ярлики тестування, а значні зміни вимог, ймовірно, скасують велику кількість тестів, що вимагатиме їх переписування та потенційно завищить накладні витрати.
Я майже впевнений, що ATDD має фантастичну виплату для моделей Agile або для команд, які офіційно не Agile, але мають дуже часті графіки випусків. Я ніколи не пробував це на довгостроковому проекті, головним чином тому, що я ніколи не був або навіть чув про організацію, яка бажає спробувати його на такому проекті, тому вставте сюди стандартну відмову від відповідальності. YMMV і все таке.
PS У нашому випадку не потрібні додаткові зусилля від "замовника", але у нас є відданий, повний робочий день Власник продукту, який фактично пише критерії прийняття. Якщо ви займаєтесь консалтинговою компанією, я підозрюю, що кінцевим користувачам може бути набагато складніше писати корисні критерії прийняття. Власник продукту / менеджер продукту здається досить важливим елементом для ATDD, і хоча я в черговий раз можу говорити лише зі свого власного досвіду, я ніколи не чув, щоб ATDD успішно практикувався без того, щоб хтось виконував цю роль.
