Автоматизоване тестування: пояснення його ділової цінності

Для початку я не думаю , що це повторення з інших питань на модульному тестуванні . Що я шукаю допомоги - це висловлювати свою цінність команді програмістів, аналітиків, менеджерів і тестерів. За допомогою автоматизованих тестів, я не думаю, що мені потрібно розрізняти одиничні тести (наприклад, JUnit), BDD (наприклад, JBehave, Fitness) та інтерфейс користувача (Selenium, Watir), тому що я думаю, що всі вони надають аналогічну цінність (але не соромтеся напишіть відповідь, яка не погоджується :))

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

1. Економія часу / витрат : написання автоматизованих тестів може зайняти більше часу, ніж письмові тестові випадки. Однак, враховуючи тести, які виконуються кілька разів, гранична робота (тобто вартість / час) для виконання автоматизованих тестів на кілька порядків менша. Те, що автоматичні тести дешеві для запуску, полегшує зміну системи з часом.
2. Документація : немає більш правдивого способу дізнатися, як працює система, ніж її тести. Будь-яка інша документація, як правило, застаріла з моменту її написання, але тести (принаймні ті, що проходять) виявляють, як все насправді працює. Це справедливо як для документації кінцевого користувача, так і для API.
3. Якість коду : тестове написання змушує вас:
   • вважайте клієнтів, оскільки тести - це клієнт
   • розбиває залежності, коли зробити код тестуваним часто означає, що з'ясувати, як зробити для цього коду не потрібну іншу велику систему

Кілька моїх думок:

1. Будьте чесні, що для написання автоматизованих тестів знадобиться більше часу. Якщо ви працюєте з TDD на рівні одиниці (що я рекомендую як вихідну точку, якщо ви збираєтесь інвестувати в автоматичне тестування), ви можете очікувати приблизно 30% додаткового часу, необхідного для кодування функції. Ключовим тут є пояснення того, що ці додаткові 30% (що, мабуть, перевищує 30% на початку, коли ваша команда вчиться писати хороші тести) - це інвестиція, побудована для економії витрат у часі. Як мінімум із рівнем TDD на рівні одиниці, конструкція вашої системи є зв'язаною та дуже згуртованою, що робить вашу систему пристосованою до змін у часі. Нові вимоги та несподівані помилки завжди потребують змін у вашій системі,
2. Існує багато дискусій про значення тестів рівня прийняття та інтерфейсу інтерфейсу, враховуючи кількість часу, необхідного для написання цих тестів, скільки часу потрібно для їх запуску та скільки необхідного технічного обслуговування. Я рекомендую прочитати цю статтю Джеймса Шор про це.
3. У світі автоматизованого тестування є хороші способи і погані способи зробити це. Якщо ви пропонуєте автоматизоване тестування для свого керівництва, я б наголосив на тому, як ви плануєте навчати свою команду в написанні хороших тестів. «Мистецтво одиничного тестування» Роя Ошерове, «Ефективна робота зі спадковим кодексом Майкла Пірса» та «Мистецтво спритного розвитку» Джеймса Шора - все це чудові книги, які безпосередньо чи опосередковано стосуються цих тем. Ви також повинні вивчити якусь тренерську чи офіційну підготовку. Це велика зміна.
4. З точки зору вартості бізнесу, №2 та №3 ваших вище пунктів насправді служать вашій першій точці, тому я забиваю додому пункт №1 та поговорю про те, як №2 та №3 слугують цій кращій точці. Документація робить вашу систему більш зрозумілою, що робить вашу команду швидшою. Якість коду робить вашу систему пристосованою до змін, що робить вашу команду швидшою. Для ділових людей справа в тому, щоб максимально збільшити потік вартості від моменту подання ідеї до моменту подання ідеї як робочого програмного забезпечення.

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

Витрати на тести

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

Надійність тесту

Комп'ютерові можна довіряти виконувати ту саму процедуру тестування кожного разу. Людина схильна робити помилки і лінуватися.

Режими відмов тестування комп'ютера також набагато легше очевидні - він вийшов з ладу (повідомлення про тести перестали з’являтися), у нього була невелика помилка, яка спричинила помилковий результат тестування (повторно проведіть детермінований тест, і результат відрізняється). Якщо людина пропускає крок і перевіряє "ОК", як ми можемо сказати?

Довговічність випробування

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

Значення тесту

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

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

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

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

Існує також точка постійної інтеграції .

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

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

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

Тут є важливим фактором простота рефакторингу. Маючи гарний та читаний (!!!) тестовий блок, ви можете переробити систему, не нервуючи при цьому, порушуючи існуючі функціональні можливості.

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

Я також не можу продати це як аспект документації, такі речі, як Fitnesse, можуть зробити це добре, але поки вони не пережили це, можливо, важко уявити.

Сфери, на які я думаю, можуть продати далі

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

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

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

4. Тести BDD та інтерфейсу можуть уникнути багаторазового натискання кнопок, щоб перевірити всі аспекти, на які могли вплинути ваші зміни, і заощадити вам про запам'ятовування всіх областей.

5. Автоматичні побудови часто виділяють, коли хтось забув перевірити код

6. Тести допомагають уникнути появи нових помилок.

7. Тести підрозділів та гідне глузування означатимуть менше взаємопов’язаного коду та їх буде легше вирішити

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

Хтось повинен вважати, що існує проблема, перш ніж приймати запропоноване рішення цієї проблеми.

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

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

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

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

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

"Те, що я шукаю допомоги, полягає в тому, щоб сформулювати свою цінність для команди програмістів, аналітиків, менеджерів і тестерів. За допомогою автоматизованих тестів я не думаю, що мені потрібно розрізняти одиничні тести (наприклад, JUnit), BDD ( наприклад, JBehave, Fitness) та інтерфейс користувача (Selenium, Watir), тому що я думаю, що всі вони мають подібну цінність (але не соромтесь написати відповідь, яка не погоджується :)) "

Гаразд, я прийму це виклик;)

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

Інструменти BDD / TDD для rspec та testunit є частиною програмування. Ви не розбиваєте їх і не розмовляєте про них окремо керівництву, ви не відкладаєте їх через брак часу, ви включаєте їх у всі свої часові оцінки. Якщо насправді підштовхували, запитували, скільки часу у вас людей, щоб пояснити їм інформатику та програмування. Я не використовую ці тести для передньої частини

GUI / UI / Жасмін / Селен. Це різні. У мене це зроблено людьми, які мають досвід програмування. Ми переконуємося, що тести написані як можна більш надійними та заснованими на вмісті, не макеті. (Можливо, нову) вартість цього слід пояснити як зміщену вартість . Замість того, щоб згодом платити зі зламаним програмним забезпеченням, втраченими клієнтами та дорогими виправленнями, ви платите набагато менше (відносно) за кілька простих практик.

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

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

1. Тести вашої основної функціональності . Тобто, для інструменту моніторингу веб-сайтів це будуть тести сповіщень, які повинні спрацьовувати для веб-сайтів, які ви відстежуєте. Ці тести гарантують, що цей матеріал ніколи не ламається.
2. Димові тести для всієї вашої програми . Наприклад, використовуючи Selenium для навігації по всіх посиланнях / кнопочках у веб-додатку та переконайтесь, що немає помилок з боку сервера. Ці тести дозволяють вам не витрачати час тестувальників на явно пошкоджені склади.
3. Тести будь-якого крихкого коду . Тобто, за цей старий модуль ніхто не хоче торкатися, або складний фрагмент коду, який, здається, завжди має в ньому помилки.
4. Тести, які розробники хотіли написати, щоб підтримати їх роботу . Тому що іноді тести корисні, коли щось пишеш, але не потрапляєш до категорій вище.

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

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