Найкращі практики автоматизації
У кожній статті свій топ найкращих практик, характеристик хороших тестів тощо, так що я просто скопіював найкорисніші на мій погляд списки.
7 параметрів добре написаних тестів
Тест повністю автоматизований (очевидно): Іноді трапляються такі тести, які не повністю автоматизовані. Найпоширеніші причини: або це дуже складно, або просто неможливо;
Тест повторюємо : тест не ламається, якщо програма не змінилася: Це стосується основ генерації унікальних даних. Наприклад, ми тестуємо реєстрацію. Очевидно, що якщо не генерувати унікальний емейл, то на продакшені такий тест, швидше за все, не працюватиме;
Тест закінчується валідацією : За винятком випадків, де потрібно виконати дії із зачистки даних та подібних дій, завершення валідацією є найкращою практикою. Це допомагає переконатися, що остання дія пройшла успішно;
Тест досить стабільний, щоб його використовувати в CI/CD : Якщо тест регулярно ламається, то він недостатньо стабільний, щоб використовувати його в CI/CD. Так як практично будь-яка компанія намагається добитися CI або навіть CD, то часто такий тест не просто марний, але навіть шкідливий, тому що забирає багато часу і все одно не може використовуватися в CI автоматично;
Тест дуже легко читати : Ми зазвичай не пишемо тести поодинці. Часто це команда людей та нашим колегам теж доводиться підтримувати наші тести. Вкрай важливо, щоб будь-який член команди міг розібратися в структурі тесту, не витрачаючи на це зайву кількість часу. Навіть якщо ми пишемо тести поодинці, іноді буває дуже важко зрозуміти, що тест робить і як, якщо він не написаний спеціально для полегшення розуміння;
Тест вимагає мінімальної підтримки : Пункт очевидний, але не завжди дотримується. Чим менше ми витрачаємо часу на підтримку, тим більше ми маємо часу на те, щоб зробити щось корисне, як, наприклад, написати більше тестів;
Тест працює паралельно з іншими тестами і не ламається : У якийсь момент, особливо для end-to-end тестів, ми стикаємося з тим, що прогін тестів займає занадто багато часу, це знижує швидкість розробки та призводить до таких ефектів, як неоттестований патч. На цьому етапі ми зазвичай замислюємося на паралелізацію, щоб прискорити виконання тестів. Якщо тести були написані так, що вони можуть бути запущені паралельно в будь-якій послідовності і не перетинатися один з одним, це робить завдання паралельного виконання просто завданням налаштування інфраструктури, а не завданням переписування тестів.
Ще десять заповідей автоматизації
Не автоматизуй тільки "за тест-кейсами"
Існує поширена помилка, що тест-автоматизація повинна рости з тест-кейсів. Автоматизатори беруть існуючі або свіжостворені тест-кейси та перетворюють їх на автоматизовані сценарії. Це називається "автокафе". У цьому підході може бути сенс, але інші підходи принесуть не менше, а то й більше зиску. Розширюючи визначення автоматизації за рамки "тест-кейс – інструмент – тест-скрипт" до "продуманого застосування технології з метою допомогти людям виконувати свою роботу", ми можемо використовувати комп'ютерні потужності для завдань, для яких вони призначені, а люди – тестувальники – нехай роблять все інше. На щастя, у більшості завдань, де хороші люди, комп'ютери виступають погано – і навпаки.
2. Поводься з розробкою автоматизації, як з розробкою ПЗ
Розробка автоматизації - і є розробка ПЗ. Навіть якщо ми використовуємо інтерфейс перетягування або запису та відтворення для створення автоматизації, то десь під капотом або за завісою над нашими діями працює код. Ми повинні почати поводитися з автоматизацією як із розробкою ПЗ, інакше ми опинимося з чимось непідтримуваним на руках, і проект помре, щойно народившись. Підхід до автоматизації як до розробки ПЗ означає, що ми повинні враховувати більшість (якщо не всі) процесів та видів діяльності, необхідних для розробки ПЗ. Включно з:
Дизайн - ми повинні вирішити, що впроваджувати та як це робити, щоб це було підтримуваним та придатним до експлуатації.
Впровадження – треба написати код.
Зберігання - код та його артефакти мають десь зберігатися.
Тестування – тестувати тести? Звичайно! Ми повинні бути достатньо впевнені, що автоматизація поводиться так, як хочеться. Якщо ми не довіряємо автотесту, у них немає сенсу.
Баги - у будь-якому ПЗ є баги; автоматизація, як ПЗ, не виняток. Тестування допоможе нам, але не відловить усі баги на світі. Виділіть час на виправлення багів.
Логи – це артерія автоматизації. Без них ми не зрозуміємо, що автоматизація робить, і не зможемо її полагодити, коли вона зламається. До того ж ми не зможемо сказати, чи в автоматизації криється проблема, чи в тестованому ПЗ.
3. Дотримуйся стандартів та ідіом програмування
Крім поводження з автоматизацією як із розробкою ПЗ, ми повинні вбудовувати в неї відповідні ідеї щодо впровадження. Кожен інструмент та мова мають свої власні ідіоми та хитрощі, але загальноприйняті підходи до проектування та впровадження зазвичай годяться для всього. Ця стаття про інкапсуляцію та абстракцію розповідає про зразкові практики, які можна переносити в інші специфічні області.
4. Не забувай про підтримку та обслуговування
ПЗ не ідеально і ніколи не буває повністю готовим; з автоматизацією те саме. У ній будуть баги. Зі зміною програми, що тестується, потрібно буде відповідно змінювати автоматизацію. Ми не можемо цього запобігти, але можемо розробити наше програмне забезпечення так, щоб знизити витрати на його підтримку та обслуговування; і на них також треба виділити час. Ця стаття та цей пост у блозі розповідають про фактори, які треба враховувати, плануючи майбутню підтримку.
5. Не роби скрипти залежними один від одного
Створення тест-скрипту, залежного від результатів іншого тесту - зазвичай потужний анти-паттерн. Якщо скрипти залежать один від одного, їх не можна проганяти поодинці, і це ускладнює дебаг автоматизації та проблем програми. До того ж, залежні скрипти не можна запускати паралельно з тими, від яких вони залежать. Тут є граничний випадок, коли всі скрипти залежать від одного-єдиного. Цей одиничний скрипт зазвичай налаштовує тест-оточення та тестові дані. В умовах сучасних фреймворків автоматизації та безперервної розгортки це все більша рідкість, але цей сценарій може бути доречний у ситуаціях, коли фреймворки недоступні або не підходять для специфічного автоматизаційного завдання.
6. Впроваджуй грамотне логування та звіти
Як описано тут, грамотні логи, результати та повідомлення про помилки критично важливі для розуміння, довіри до та підтримки автоматизації. Ці логи - наш деталізований образ прогону автотестів: що запускалося, як саме, що впало, як воно впало, як воно досягло успіху, і т. д. Звичайно, якщо ми ретельно впровадили грамотне логування, яке дає нам цю інформацію в читабельній формі.
7. Вплив на тестованість та автоматизованість
Тестованість, той ступінь, до якого додаток або фіча можуть бути протестовані, і автоматизованість, ступінь, до якого тест-діяльність може виконуватися автоматично - це не те, що можуть створювати тестувальники, QA та QE, але, звичайно, є речі, на які ми можемо вплинути. Здійснення цього впливу – наше обов'язкове завдання. Розробники не завжди знають, що нам потрібно для тестування та створення автотестів. Ми маємо донести це до них. Статті тут і тут розповідають про деякі аспекти тестування та автоматизованості.
8. Не трапляйся у пастку незворотних витрат
Іноді ми робимо помилки. Іноді це великі помилки. Ми отримуємо максимум з інформації, яку маємо в моменті, але це не завжди спрацьовує. Коли щось у нашому плані йде не так, ми інстинктивно намагаємось це виправити та продовжувати виправляти. Однак іноді варто почати заново, інакше ми ризикуємо викинути хороші гроші за поганими. Це називається "пасткою неповоротних витрат". Якщо коротко, вона полягає у думці, що ми вже витратили стільки грошей на цей проект, що зобов'язані витратити ще для його реабілітації, щоб отримати вигоду з уже витрачених, неповоротних витрат на нього. Можливо, ми емоційно прив'язані до нашої програмної "дитини"; ми витратили на нього стільки часу та грошей, що не в змозі викинути його та почати заново. Можливо, ми боїмося; керівництво, швидше за все, не прийде у захват, захоті ми кинути все і знову зробити "те саме". Ми повинні розглядати такі ситуації з погляду бізнесу, а не вдаватися до емоцій.
9. Остерігайся хитромудрих пристроїв
Машини Руба Голдберга - це складні машини, що виконують порівняно прості завдання, на кшталт "Автономної хусточки". У світі автоматизації створення таких машин – дуже весела справа, і вони можуть робити круті штуки на кшталт ув'язування разом різних інструментів для виконання тест-завдань. Мінус у тому, що це складно розуміти та підтримувати; треба побоюватися створення того, що складніше підтримувати, ніж виконувати ці завдання вручну. Ця стаття розповість більше про автоматизовані машини Руба Голдберга; ця посада розмірковує про стан "автоматизованості".
10. Не роби тестові дані залежними від тимчасових даних
Скрипт, з яким я зіткнувся нещодавно, одного дня почав падати. Досліджуючи питання, ми з'ясували, що падав він через зміну місяця з липня на серпень. Скрипт був написаний таким чином, що оракул перевіряв дати в липні, і в липні все було добре – програма повертала дати поточного місяця, липня. Коли дата змінилася на серпень, програма почала повертати дати серпня, і тест падав. В цьому випадку треба не жорстко кодувати дати липня, а динамічно генерувати дані на підставі цього місяця.
Як можна і не можна автоматизувати
Не можна :
Автоматизувати всі ручні тести : ручні тести прекрасні - вони знаходять проблеми, про які ви навіть не думали. Але ручний підхід до тестування не завжди можна перенести безпосередньо на автоматизовані перевірки. Можливо, варто створити нові сценарії спеціально для автоматизації.
Робити автотести завданням однієї-єдиної людини : коли ви тільки починаєте, найм консультанта з автоматизації - хороша думка, проте переконайтеся, що відповідні знання доступні всім учасникам проекту. В один прекрасний день консультант або ключовий виконавець залишить вас, і розбиратися з тест-набором доведеться решті.
Автоматизувати все на світі : сценарій автоматизується не просто так – на це є причини, його автоматизація якимось чином цінна для проекту. Почніть із рутинних завдань, які все одно виконуються щодня - і ви відразу побачите першу, миттєву вигоду від зусиль з автоматизації.
Автоматизувати, просто щоб автоматизувати : подумайте, що вам потрібно, і що потрібно прямо зараз. Якщо ви налаштовані на 80-100% автоматизацію у всіх проектах просто тому, що "це круто і так хоче генеральний директор, або "це добре звучить на зборах ради директорів", то ви даремно витрачаєте час і гроші.
Купувати лідируючий по ринку, найкращий інструмент автоматизації : знайдіть інструмент, який підходить під ваші завдання, і переконайтеся, що він справді робить те, що обіцяє. Не піддавайтеся на умови продавців купити дорогу програму, яка дуже крута прямо зараз у цьому конкретному проекті або на цій конкретній платформі. І не змушуйте інші проекти використовувати інструмент, якщо він їм не потрібний.
Думати в термінах "пройшов" і "упав" : у вас будуть кейси, що впали. Це не означає, що є помилка. Не сприймайте тест, що впав, як сигнал про багу - вам потрібно розібратися, ЧОМУ тест впав. Також подумайте, чи дійсно категорії "пройшов/упав" підходять для звітування про автотести? Можливо, чи варто подумати про іншу класифікацію, яка краще опише те, що відбувається?
Запускати все підряд щоразу : подумайте про мету прогону ваших тестів. Якщо вам не потрібно тестувати окрему область - не робіть цього, тестуйте тільки ту функціональність, яка цього потребує. Інше тестування - це зайва трата часу та сил, яка засмітить ваш звіт непотрібними даними. Звичайно, деякі перевірки можуть ганятися постійно, але переконайтеся, що це виправдані заходи.
Забувати тестувати власні тести : звикайте до ідеї тестувати свої тести. Автоматизований тест-сценарій не повинен випускатися у світ, доки ви не побачили, як він кілька разів упав. Запускайте тест в обставинах, коли він, безумовно, впаде, щоб врахувати це, коли він буде випущений у реліз.
Недооцінювати зусилля щодо підтримки автоматизованого набору тестів : автоматизований тест-сьют - не та штука, яку зробив і забув, а вона бігає собі там. Ваша система постійно змінюється, і тест-набір потрібно оновлювати та поповнювати безперервно. Не звалюйте цю відповідальність на єдиного тех-тестувальника у вашій компанії.
Потрібно :
Дробити тести на незалежні сценарії : куди легше визначити, де гніздяться проблеми та помилки, якщо ваш тест-набір складається з коротких, конкретних тест-сценаріїв. Не намагайтеся впхнути все в один сценарій. Дуже, дуже важко розібратися, що ж пішло не так, якщо вам треба докопатися до всього на світі, що перевіряється у вашому тесті. Нехай тести будуть короткими та простими.
Зробити автоматизацію завданням усієї команди проекту : чому б не дати можливість усім, а не лише тестувальникам, впливати на набір автотестів? Розробники, менеджери проекту, продакт-оунери – всім їм є що сказати на предмет автоматизованого тестування, і вони можуть принести йому користь.
Донести інформацію про результати автоматизованого тестування до всіх – і подумати, хто отримує ці результати : надайте різну інформацію різним людям у проекті. Розробнику потрібна специфічна інформація про прогін автотестів, і вона байдужа менеджеру проекту. Опитайте всіх зацікавлених осіб, з'ясуйте, яка інформація їм потрібна.
Починати з простих речей і поповнювати тест-сьюти по ходу справи : почніть з того, що вам необхідно, і слідуйте по проекту проекту. Проекти постійно змінюються – не треба витрачати час, сили та гроші на те, що не буде використано чи зміниться в останній момент. Створюйте набір тестів по шматочках, крок за кроком.
Змусити ваш фреймворк працювати на зношування : ви придбали дорогу програму, налаштували її і витратили час на створення та оновлення наборів тестів. Користуйтесь цим! Створіть набір, який може проганяти часто І при цьому цінний для проекту! Набір автотестів, який не запускається – це марна трата грошей.
Враховувати проектні та організаційні зміни : знайдіть програму, яка здатна рости разом з вашими проектами та вашою організацією, і з'ясуйте, що ви можете – і не можете – з нею робити. Якщо вона вам не підходить, відкиньте її. Немає сенсу витрачати сили та час на невідповідні ресурси.
Розвантажити ручних тестувальників : думайте про набір автотестів як про допомогу мануальним тестувальникам. Звільніть їх від нудних завдань, що повторюються, нехай вони роблять те, в чому вони зірки - тестують, а не тупо слідують сценаріям.
Зробити запуск тестом простим і швидким : налаштування та старт набору автотестів має бути простим завданням та давати миттєвий зворотний зв'язок. Якщо ваш тест-набір уповільнений або дуже складний, люди просто не морочаться із запуском.
Постійно оновлювати тест-набір : якщо змінюється ваш код – змінюються автотести, і це ваше золоте правило. Воно правильне для ВСІХ змін бази коду. Виправлення багів, використання фіч - все це веде до змін тест-набору.
Про патерни проектування/архітектури є посилання в дод. матеріалах нижче. Про створення фреймворку в темі про види та інструменти.
Джерела:
Дод. матеріал:
Last updated