Відносна економічна ефективність розробки (прийняття) тестового керування


15

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

введіть тут опис зображення

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

Скільки більше зусиль потрібно від замовника? Чи повинні вони змінити спосіб відношення до проекту, особливо якщо вони використовуються для великого дизайну на передній план? Чи збільшується кількість годин, необхідних клієнту загалом, чи фактично зменшується?

Я думаю, що оцінки часу були б дуже невиразними в ітеративному процесі TDD на початку проекту TDD (оскільки немає Плану розробки програмного забезпечення). Чи є сенс, скажімо, 20% в проекті, де впевненість зростає достатньо, що більш-менш стабільна оцінка часу та грошей може бути надана замовнику?

Примітка. Я не шукаю тут суб'єктивних думок чи теорій, тому, будь ласка, не спекулюйте. Я більше шукаю досвіду в реальному світі в TDD.


Я впевнений, що даних про реальний світ немає. Ви отримуєте лише суб'єктивні думки та теорії на основі досвіду реального світу peoeple.
Ейфорія

1
@Euphoric: Я шукаю об'єктивні спостереження та реалії, засновані на реальному досвіді. Вибачте, що я цього не зрозуміла. Однак мені не потрібні важкі цифри; Я прийму загальні враження, такі як: "в той час, коли наш час розробки значно збільшився, наші витрати на обслуговування зменшились, оскільки програмне забезпечення було більш надійним, а клієнт зрозумів це програмне забезпечення краще, оскільки він брав участь у розробці впродовж усіх зусиль з розробки".
Роберт Харві

2
Отже, це питання, засноване на думці? Це, звичайно, звучить як одне
BЈович


@ BЈовић: Ознайомтеся з останнім абзацом у моєму питальному органі.
Роберт Харві

Відповіді:


11

Перше, що потрібно зазначити, це те, що TDD не обов'язково підвищує якість програмного забезпечення (з точки зору користувача). Це не срібна куля. Це не панацея. Зменшення кількості помилок - це не те, чому ми робимо TDD.

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

Бажаєте ви використовувати TDD чи ні, більше залежить від ваших цілей проекту. Це буде короткотерміновим консультаційним проектом? Чи потрібно вам підтримувати проект після прямої трансляції? Це тривіальний проект? Додані накладні витрати можуть не вартувати в цих випадках.

Однак, на моєму досвіді, значення пропозиції для TDD зростає експоненціально, оскільки час та ресурси, залучені до проекту, лінійно зростають.

Хороші одиничні тести дають такі переваги:

  1. Експертні тести попереджають розробників про непередбачувані побічні ефекти.
  2. Тестові одиниці дозволяють швидко розвивати нові функціональні можливості на старих, зрілих системах.
  3. Експериментальні тести дають новим розробникам швидше та точніше розуміння коду.

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

Підсумовувати:

Розробка версії 1 може бути повільнішою. Розробка у версії 2-10 буде швидшою.


1
Мені подобається, що явна супозиція «кращого коду» відрізняється від підвищення «якості програмного забезпечення», тобто те, що цінність програмістів у коді не обов'язково полягає в тому, що він робить те, що хоче клієнт.

1
Чи не є передні приймальні випробування та одиничні випробування для уточнення вимог?
Роберт Харві

@RobertHarvey Вони повинні бути, але не обов'язково . Одиничні тести та приймальні тести відображатимуть розуміння розробником вимог під час їх написання. У розробників може виникнути що-небудь від повного розуміння до нерозуміння вимог, коли вони починають писати програмне забезпечення. Ця частина рівняння набагато більше залежить від клієнта та менеджера продукту, ніж все інше. Теоретично тести повинні дуже допомогти. На практиці, ну, "це залежить".
Стівен

1
Я повинен уточнити, тут ми говоримо про TDD ізольовано, а не про реалізацію SCRUM, яка включає TDD. Окремо TDD - це все, що стосується написання тестів, щоб ви писали кращий код і могли пізніше переробляти швидше та безпечніше.
Стівен

1
@Stephen: Можливо, я повинен був би зрозуміти, що я говорю про аромат TDD, який включає тести прийняття як частину процесу збору вимог. Я додав графіку до питання, щоб зробити це зрозумілішим.
Роберт Харві

6

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

Тематичні дослідження проводилися з трьома командами розробників у Microsoft та однією в IBM, які прийняли TDD. Результати тематичних досліджень свідчать про те, що щільність дефектів перед випуском чотирьох продуктів знизилася між 40% і 90% щодо аналогічних проектів, які не застосовували практику TDD. Суб'єктивно команди зазнали збільшення на 15–35% початкового часу після прийняття TDD.

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


4
Проблема цього дослідження полягає в тому, що вони не перевіряли код перед адаптацією TDD. TDD не є магічним інструментом, який зменшує кількість дефектів на 40-90%, просто прийнявши його
BЈович

1
@ BЈовић Я не думаю, що вони вимагають "магії" де-небудь у цьому документі. Вони стверджують, що деякі команди прийняли TDD, деякі команди не зробили, їм було надано "схожу" роботу, а деякі щільності дефектів та час розвитку були зафіксовані. Якби вони змусили команди, що не мають ТДВ, все одно писати одиничні тести просто так, щоб усі мали одиничні тести, це не було б екологічно обгрунтованим дослідженням.

Екологічно обгрунтоване дослідження? Сорта залежить від того, що ти вимірюєш. Якщо ви хочете дізнатися, чи важливо писати свої тести на передній план , то всі повинні складати одиничні тести, а не лише групи TDD.
Роберт Харві

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

2
На щастя, я не сказав, що вони є.

5

Я не маю жодних дослідницьких робіт чи статистики, які б вам надавав, але я передам свій досвід роботи в команді / організації, яка історично мала низький середній рівень тестового покриття та не була проведена тестами, і поступово переміщуючи планку туди, де ми зараз, з більшою кількістю підходів 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 успішно практикувався без того, щоб хтось виконував цю роль.


Це дуже корисно, дякую. Мені не прийшло в голову, що ATTD може змінити характер зусиль TDD, але це має сенс, особливо коли ви чуєте про людей, які здатні вчасно та на бюджет викласти добре написане, відносно вільне програмне забезпечення без бюджету обов'язково широко використовувати тестування одиниць.
Роберт Харві

@RobertHarvey: Я повинен уточнити - ми все ще створюємо одиничні тести, тільки не як частина процесу TDD. Зазвичай тести прийняття проводяться спочатку або паралельно з початковою розробкою, потім завершуються кодом, потім одиничними тестами та рефакторингом. Я іноді думав, що TDD допоможе певним розробникам написати кращий код, але я не можу це зробити (поки). Хоча я можу говорити сам - я часто підхоплюю безліч помилок та недоліків дизайну у власному коді просто під час написання одиничних тестів.
Aaronaught

1

Вимоги до ресурсу

Який, на ваш досвід, загальний вплив на потреби в ресурсах для завершення програмного проекту в рамках TDD, на відміну від більш "традиційних" методологій розробки?

На мій досвід, вартість необхідності проведення попередніх тестів негайно зменшується шляхом визначення чітких критеріїв прийняття, а потім написання до тесту. Мало того, що вартість попереднього тестування зменшена, я також вважаю, що це загалом прискорює загальний розвиток. Хоча ці покращення швидкості можуть бути усунені невдалим визначенням проекту або зміною вимог. Однак ми все ще здатні реагувати на такі зміни без серйозного впливу. ATDD також значно зменшує зусилля розробника щодо перевірки правильної поведінки системи за допомогою автоматизованого набору тестів у таких випадках:

  • великі рефактори
  • оновлення платформи / пакету
  • міграція платформи
  • оновлення інструментальної ланцюга

Це передбачається команда, яка знайома з процесом та практикою, що стосується.

Залучення клієнтів

Скільки більше зусиль потрібно від замовника?

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

Однак я виявив, що стосунки з клієнтами значно покращуються після 5 демонстраційних демонстрацій, коли вони бачать, що їх програмне забезпечення повільно формується. Час зобов'язань від замовника дещо зменшується з часом, коли розробляється звіт, всі звикають до цього процесу та пов'язаних з ним очікувань.

Оцінка проекту

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

Я виявив, що це зазвичай питання про те, наскільки чітко визначено запит, і чи технічні керівники здатні здійснити карту (включаючи оцінку картки) проекту. Якщо припустити, що проект добре зафіксований, і ви маєте розумне середнє значення швидкості та стандартне відхилення. Ми виявили, що легко отримати гідну оцінку. Очевидно, що чим більший проект, тим більше невизначеності, тому я загалом розбиваю великий проект на малий проект із обіцянкою продовжити пізніше. Це набагато простіше зробити, коли ви встановите звіт із замовником.

Наприклад:

"Спринти" моєї команди тривають тиждень, і у нас є середній біг і std. відхилення останніх 14 тижнів. Якщо проект складає 120 балів, ми маємо середнє значення 25 і STD. відхилення 6, то оцінюючи завершення проекту:

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

Ми використовуємо 2 Std. Правило відхилення для нашого 95-відсоткового оцінювання достовірності. На практиці ми зазвичай завершуємо проект під першим стд. відхилення, але над нашим значенням. Зазвичай це пов’язано з уточненнями, змінами тощо.


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

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

-1

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

Це насправді не так. Якщо ваші розробники пишуть одиничні тести (і вони повинні), то час повинен бути приблизно однаковим або кращим. Я сказала краще, оскільки ваш код буде повністю перевірений, і їм доведеться написати лише код, щоб виконати вимоги.

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

Скільки більше зусиль потрібно від замовника? Чи повинні вони змінити спосіб відношення до проекту, особливо якщо вони використовуються для великого дизайну на передній план? Чи збільшується кількість годин, необхідних клієнту загалом, чи фактично зменшується?

Це не має значення. Хто б не виконав вимоги, повинен робити це якомога краще.

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

Тому, якщо вони люблять робити BDUF, нехай вони це роблять. Це полегшить ваше життя як розробника.


1
Як я розумію, TDD і BDUF взагалі не сумісні між собою.
Роберт Харві

3
BDUF, як правило, не сумісний з жодними добрими методами управління розвитком. Але можна було б зробити проект BDUF у формі TDD. TDD - це методика створення програмного забезпечення кращої якості, тоді як BDUF - це техніка для забезпечення вимог. Погана техніка, але все-таки техніка.
Стівен

@RobertHarvey Правильно, але якщо вони хочуть робити BDUF - це їх вибір. Якщо ти справді робиш спритність, то ти можеш вдосконалити їхній дизайн та все ще робити TDD.
BЈоviћ

тож ви кажете, що якщо я напишу тестовий модуль, мій код буде повністю перевірений, і якщо всі тести пройдуть, це, звичайно, означає, що програмне забезпечення є помилковим (або, принаймні, кращим). Тому мені просто потрібно перевірити кожен метод мого програмного забезпечення, наприклад "функція testSqr () {int a = 3; assertTrue (mySqr (a) == 9);} функція mySqr (int a) {return 9;}"
Дайніус

@Dainius Ні, читайте ще раз. 100% покриття коду не є помилкою. Так, вам потрібно провести тестування кожного методу. Звичайно, доступ до бази даних тестування, GUI тощо не має сенсу. Одиничні тести не для них.
BЈоviћ
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.