Чи варті тестів з метою завершення та інтеграції для критичних речей, що не належать до місії?

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

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

Я гадаю, моє питання в цілому скільки коштує тест інтеграції та тестування E2E і скільки грошей економить? Чи існує спосіб для цього розрахувати ризик / вартість?

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

Таким чином, у вашій оцінці витрат ви не порівнюєте витрати на впровадження тестів E2E з витратами, які оцінює ваш резервний план у разі відмови, ви порівнюєте:

• Витрати на тестування E2E вручну (кілька разів, перед кожною новою версією)

vs.

• Витрати на створення (та підтримку) автоматизованих тестів E2E

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

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

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

Ідея полягає в тому, що тести роблять внесок на декілька рівнів

1. Складати суворі вимоги збору та специфікації

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

2. Розробники знають, коли функція завершена

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

3. Миттєво виявлені помилки, введені за допомогою нових функцій.

   Вони можуть легко коштувати спринту і вимагати переписування цілої функції, якщо вони не виявляються.

4. Швидший цикл випуску

   Це означає менше коду в польоті, що означає менше злиття, що означає менше роботи та меншу складність для розробників

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

Крім того, ви заощаджуєте на час ручного тестування, а також отримуєте кращий продукт в кінці.

Моя відповідь? Можливо, напевно, ні .

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

Деякі роки тому Блог тестування Google обговорював цю тему. Я можу погодитися лише з автором. Хороший тест повинен бути швидким , надійним та виокремити збої , функції, які EOE тести не здатні доставити вам.

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

Більшу частину часу ми підтримували тести замість того, щоб виловлювати помилки в їх результатах. Дізнайтеся про походження помилки на тесті «наскрізь до кінця» потрібно багато часу. Ми також мали справу з безліччю "хибнонегативних" тестів і мало часу, щоб зрозуміти проблему та її виправити: проблеми з завантаженням Applet Java, очікуваний елемент не знайдений на сторінці (плюс інші проблеми щодо швидкості автоматизації), підтримуємо код запиту, який просто використовуються при тесті пам’яті бази даних (оскільки в оригінальному запиті використовується специфічний код бази даних) тощо.

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

Отже, моя консервативна порада - використовувати тестову піраміду від Google:

Як хороша перша здогадка, Google часто пропонує розділити 70/20/10: 70% одиничних тестів, 20% тестів на інтеграцію та 10% тестів на кінець. Точна суміш буде різною для кожної команди, але в цілому вона повинна зберігати форму піраміди.

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

Розробка програмного забезпечення занадто часто потребує уваги до організаційної політики.

"Загальновідомо, що випробування з метою завершення та інтеграції коштують дорого."

Я думаю, що я не згоден з цим твердженням.

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

По-друге, що стосується інструментарію, E2E, як правило, не сповільнює внутрішню еволюцію продукту і триває довше. Якщо подумати над цим, фактична функціональна поверхня більшості продуктів рідко змінюється настільки сильно, тоді як внутрішньо вона може бути предметом всіляких розробок. Як результат, як тільки тестовий інструментарій буде запущений, він, як правило, триває надзвичайно добре. Як приклад, якщо ми повернемося до аналогії автомобіля. Той самий тестовий випадок "візьміть його за привід" майже би попрацював на Ford Model T, як і на Tesla. Як би інвестиції в прокатні дороги, вітрові тунелі, установки для тестування на герметичність і т. Д. Скільки внутрішніх компонентів випробувань мали б таку хорошу рентабельність інвестицій протягом свого життя?

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

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

Використовуйте будь-яку форму тестування, включаючи E2E, яку ви вважаєте за потрібну. Зосередьтеся на тих, хоча.

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

Вам слід запитати, що є найгіршим випадком помилки, який реально може закінчитися у виробництві через відсутність тестування E2E. І пам’ятайте закон Мерфіса.

Я припускаю, що це питання стосується корпоративних веб-додатків.

Моя рекомендація щодо середньокритичних речей:

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

Я думаю, що більшість тестів має бути на рівні API чи компонентів. Мене не цікавлять одиничні тести, які виконують лише деякі внутрішні функції.