Поширені помилки автоматизації та як їх подолати. А який ваш топ?

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Yoni Flenner, програміст, який «любить тестувати», створив підбірку поширених збоїв автоматизації. Пропонуємо поглянути на список та обговорити, чи відповідає він дійсності.

❓Розкажіть, які збої автоматизації у вашій практиці — найпоширеніші.

Публікуємо скорочений переклад.

У цій статті я хочу поділитися деякими поширеними помилками автоматизації, які трапляються перед написанням коду.

Ось короткий список:

1. Очікується 100% охоплення продукту автоматизованими тестами.
2. Відсутність встановлених цілей.
3. Поганий вибір продуктів/фіч для автоматизації.
4. Погане планування ресурсів.
5. Надмірна ставка на UI-тестування.
6. Вибір невідповідного інструменту для тестування.
7. Open-source.
8. Мінімальні інвестиції в Running Reports.
9. Брак технічних знань у розробників автоматизації.
10. Погана інфраструктура автоматизації = багато ресурсів на обслуговування коду.
11. Неякісні мануальні тести призводять до поганої автоматизації.
12. Відсутність паралельного тестування.
13. Work Environment — для будь-кого.
14. Відмежування між тестувальниками та розробниками.

1. Очікується 100% охоплення продукту автоматизованими тестами

У більшості випадків у продуктів не існує такого поняття, як 100% охоплення автоматизованими тестами.

Це може звучати дуже круто — «виконання тестів без участі людини». Розробники автоматизації намагаються повністю покрити все автоматизованими тестами, поєднуючи при цьому кілька інструментів автоматизації та кілька різних технологій.

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

2. Відсутність встановлених цілей

Проєкт, який не має показників успіху автоматизації, налаштований на провал ще до того, як він почався.

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

3. Поганий вибір продуктів/фіч для автоматизації

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

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

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

4. Погане планування ресурсів

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

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

5. Надмірна ставка на UI-тестування

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

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

6. Вибір невідповідного інструменту для тестування

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

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

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

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

Коли я запитую — «Чому ви обрали саме цей інструмент?», зазвичай відповідають: «Це з історичних причин, ще до того, як я почав працювати тут, у компанії...».

7. Open-source

Часто вибирають інструменти з відкритим кодом, але чому? Тому що це безкоштовно.

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

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

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

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

8. Мінімальні інвестиції в Running Reports

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

Тому що у нас є чимало збоїв, і часто ці збої визначаються як помилкові тривоги.

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

Хороша система звітів заощадить розробникам автоматизації дорогоцінний час, виділений на інші завдання, замість того, щоб ганятися за своїм хвостом.

9. Брак технічних знань у розробників автоматизації

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

У деяких випадках тестувальникам не вистачає досвіду програмування чи налаштування інфраструктури автоматизації.

10. Погана інфраструктура автоматизації = багато ресурсів на обслуговування коду

Брак знань щодо побудови інфраструктури призведе до створення неякісної інфраструктури як з точки зору її дизайну, так і з точки зору якості коду.

Коли інфраструктура погана — поганий весь проєкт. На останніх етапах проєкту «ремонту» інфраструктури зазвичай уникають, оскільки це матиме вплив на всі ті тест-кейси, які ми вже написали.

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

11. Неякісні мануальні тести призводять до поганої автоматизації

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

12. Відсутність паралельного тестування

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

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

13. Work Environment — для будь-кого

Середовище автоматизації має бути стерильним. Розробники продукту не повинні підключатися до нього «просто для того, щоб перевірити щось в останньому фіксі».

Продакт-менеджери не повинні входити в систему та давати доступ до середовища іншим людям у компанії.

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

Найголовніше — вводити дані не через UI, а через API або завантаження бази даних.

14. Відмежування між тестувальниками та розробниками

Є компанії, в яких команда тестування — на аутсорсі.

Дуже важко досягти успіху в проєкті автоматизації, коли немає взаємодії між командами.