Як проводяться тести програмного забезпечення при технічних стартапах?

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

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

(Я мушу визнати, що хоч я ще на початку своєї кар'єри, але ще не бачу стартапу, який серйозно прагне писати автоматизовані тести)

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

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

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

Тестування програмного забезпечення не є релігією. Це просто дуже гарна ідея.

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

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

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

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

Нещодавно мені запропонували використовувати тестові розробки, і я виявив це повним відкриттям .

Тепер я твердо переконаний , що я «не мають часу , щоб НЕ писати юніт-тестів» .

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

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

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

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

Найкращі практики - це галузь, незалежно від того, чи ви робите бабусі веб-сайт чи створюєте систему наведення супутника. За ними завжди слід дотримуватися тих, хто хоче вважати себе професійним, тому їх називають НАЙКРАЩИМИ практиками.

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

Це не виключно для стартапів, хоча. Один з наших постачальників ІТ-контрагентів навіть не має тестового середовища. Все робиться прямо для життя, і це велика багатонаціональна компанія з програмного забезпечення (страшно!)

Чи повинні вони? Так. Чи роблять це на практиці, не так часто, як слід.

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

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

У деяких компаніях знайдеться хтось, хто робить тестування. Зазвичай це найманий розробник, і, як правило, це хтось із досвідом і, мабуть, хтось, хто має якусь фінансову частку в компанії. Компанія, яка починає цю "ДНК", ймовірно, зробить тестування з самого початку.