#testing #automation
Приніс невеличкий, але вкрай важливий пост про автоматизацію тестування. Особливо в часи, коли всюди вакансії одних генералів в QA, яких оцінюють лише за вмінням писати тести на плейрайті на швидкість.
Автоматизація тестування для багатьох команд та менеджерів прирівнюється до наявності якості. Якщо пайплайн зелений - всі в безпеці. Якщо всі тести автоматизовані, то усі ризики покриті. Але таке бачення ... це велика помилка.
Чому автоматизації недостатньо?
1. Автоматизація перевіряє тільки те, про що знає (те, що ви написали в коді, не більше). Зелений пайплайн не означає, що продукт працює. Це лише означає, що автотести успішно виконані.
2. Коли менеджмент хоче швидких результатів, то, часто, автоматизують не те, що важливо, а те, що найлегше автоматизувати. До того ж, інженери концентруються виключно на UI тестах - бо результат легше показати менеджерам (ніж якийсь код в консольці).
3. Як тільки автотест написаний - люди вважають, що сценарій "покритий" повністю. Але якість залежить від того, яку нову інформацію віднайшли під час тестування. Навіть того кейс, який вже автоматизований.
4. Менеджмент ганяється за метриками покриття - покриття коду, покриття вимог. Але забуває про те, що автоматизація - це не просто про покриття чи запуск тестів. Це - про відповідальність.
5. Коли на проєкті мало flaky тестів - на них "забивають". Коли їх стає занадто багато - ніхто не довіряє СІ. Команда звикає ігнорувати сигнали від таких тестів.
Коли автоматизація підсилює мислення тестувальників - вона допомагає будувати впевненість. Якщо ж автоматизація замінює мислення тестувальника - то підсилюються тільки помилки.
Звичайно, у вас на проєкті все не так. У вас цінують тест інженерів. Прислухаються до них. Та не концентруються виключно на автоматизації. 😀
