Ми витрачаємо більше часу на тестування функціоналу, ніж на реалізацію самої системи, це нормально?

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

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

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

Отже, яка цінність у витрачанні більше часу на написання функціонального тесту, ніж на написання системного коду, тестування блоку та виправлення QA-тикетів? Це нормально? Чи не слід ми писати функціональні тести лише для критичних функцій і не дозволяти QA робити тести регресії за відсутністю критичних функцій?

Примітка: ми не розробляємо медичне програмне забезпечення або програмне забезпечення NASA або нічого такого, що є критичним.

Функціональні тести дуже важливі. Так, для написання потрібен час, але якщо ви пишете правильні функціональні тести, вони будуть більш ніж варті.

Існує кілька вагомих причин робити автоматизовані функціональні тести на програму.

• Коли на ваш веб-сайт додається нова функція, вона повідомляє вас про те, чи зміни, внесені за цією новою функцією, порушують будь-яку іншу функціональність вашого сайту.
• Це документально підтверджені знання про те, як програма працює і працює разом для досягнення бізнес-потреб.
• Коли настав час оновити сторонні бібліотеки, ви можете оновити її та запустити свій функціональний тестовий набір, щоб побачити, чи щось порушиться. Замість того, щоб самостійно переглядати кожну сторінку, ви можете змусити комп’ютер зробити це за вас і дати вам список усіх тестів, які зламалися.
• Тестування навантаження! Ви можете імітувати тисячі одночасно користувачів, які потрапляють на ваш сайт одночасно, і ви можете бачити, де ваш сайт сповільнюється і піддається тиску. Ви можете бачити, як поводиться ваш веб-сайт задовго до того, як ви отримаєте дзвінок пізньої ночі про те, що сайт вийшов з ладу.
• Функціональне тестування потребує часу вручну. Так, писати справи потрібно багато часу, але якби вам довелося сісти за палітуркою з 500 сторінок тестів, які вам довелося виконати, перш ніж ви могли доставити продукт, який ви хочете, щоб у вас були автоматизовані тести!
• Документи тестування застаріли швидко. Коли буде додана нова функція, вам потрібно обов’язково оновити документ головного тестування. Якщо хтось пропускає якісь тести, ви раптом отримуєте помилки, що переповзають на сторінки, які "зроблені та перевірені". Зараз я працюю в такому середовищі, і можу вас запевнити, це кошмар.

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

Це ваша мережа безпеки. Коли хтось заходить і викрадає збережену програму і внесе невеликі зміни, щоб вона працювала з їх кодом, ви зрозумієте, що вона порушила 3 ​​інші функції в процесі. Ви зловите його в ту ніч, а не в ніч до встановленого терміну!

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

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

• погана підтримка інструментів для створення та обслуговування тестів

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

Поговоріть зі своїми розробниками.

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

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

Абсолютно. Написання справді хороших тестів, ймовірно, займе більшу частину часу у багатьох (хороших) магазинах.
Тож співвідношення 2-1 добре. Менш досвідчені розробники часто не беруть до уваги весь час на тести.

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

Тести одиниць - це код, тому вони містять помилки (як і всі інші коди). Виправлення цих помилок потребує часу.

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

Йдеться про якість.

Якщо вам потрібно вийти на ринок - ви розвинете свій додаток якомога швидше. Ви навіть не можете мати автоматичні тести =), але ви віддасте свою програму на слух перед конкурентами.

Але якщо ви знаєте, що ваша слухова система не згасне, ви зробите все, що не можете їх розчарувати. Кожен квиток на помилку знизить вашу репутацію. Уявіть, що одна помилка зніме 50 відсотків вашої репутації, наступна - ще 25 відсотків і так одна. Тож чи може бути занадто багато тестів?

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

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

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