Основні помилки в автоматизованому тестуванні
Привіт! Мене звати Олексій, я Senior Test Automation Engineer у Sigma Software. Маю
Почавши в Sigma Software як інтерн та пройшовши тут усі етапи зростання, я переважно спиратимуся на досвід, отриманий на 20+ проєктах (завершених з моєю участю). Глибший аналіз та розбір помилок, що згадані в статті, а також інші важливі аспекти автоматизованого тестування будуть на моєму авторському курсі Automation Testing, тому запрошую всіх зацікавлених поринути в цю тему разом.
Що таке автоматизація тестування
Автоматизація тестування не тільки дає змогу прискорювати процес верифікації та виявлення дефектів, а й стоїть у перших рядах забезпечення якості продукту, гарантує його стабільну роботу та відповідність заявленим вимогам. Вона вирішує низку ключових завдань: швидкість і ефективність тестування, повторюваність перевірок, пошук помилок на ранніх етапах, процес безперервної інтеграції. Прогресивні компанії виділяють значні ресурси на впровадження автоматизації, розуміючи, що без неї неможливо здобути високу швидкість виходу нових релізів і водночас зберегти якість продукту.
Проте, всупереч безлічі переваг, без правильного розуміння та підходу автоматизація може стати джерелом несподіваних проблем і витрат.
Далі я розгляну найпоширеніші помилки, з якими можуть зіткнутися майбутні або теперішні фахівці-автоматизатори (і з якими стикався я сам) під час спроби впровадження автоматизованого тестування, та надам рекомендації щодо їх уникнення.
Помилка № 1. Неправильне розуміння цілей автоматизації
Зі свого досвіду я знаю, що однією з найпоширеніших причин збоїв в автоматизації тестування є викривлене або неповне розуміння її цілей. Багато команд помилково розглядають автоматизацію як просто спосіб скорочення часу тестування або заміни людського фактора, зменшення витрат на оплату тестувальників. Вони запускають процес автоматизації без чіткого розуміння того, що вони хочуть досягти. Це може призвести до спрямування зусиль на не ті завдання і, як наслідок, до неефективності всього процесу. Адже без чітко визначених цілей відбувається «автоматизація заради автоматизації».
Наприклад, одного разу я став свідком того, як автоматизацію в стартапі додали за бажанням клієнта лише через те, що в його знайомого теж була автоматизація. На іншому проєкті розробили фреймворк для вельми складного і мінливого UI тільки для того, щоб покрити кілька smoke-сценаріїв.
І це призводить до таких можливих негативних наслідків:
- Даремна витрата бюджету. Ви можете змарнувати десятки й сотні годин на продукт, який не приноситиме жодної користі, а часто навіть буде забирати додатковий час на свою підтримку.
- Втрата довіри до автоматизованих тестів. Коли автоматизовані тести перевіряють не те, що потрібно, то часто вони «ламаються» або пропускають дефекти. І тому команда розробки та замовник можуть ставитися скептично до результатів автоматизації.
- Неправильне покриття тестами. Неправильний вибір тестового скоупа може спричинити те, що автоматизовані будуть некритичні сценарії, які не несуть особливої користі і навіть можуть бути прибрані з release scope. На таких тестах автоматизація просто не окуповується.
Як уникнути подібних проблем?
- Насамперед визначте основні цілі автоматизації перед початком роботи. Це може бути: зменшення часу регресійного тестування, автоматизація трудомістких для ручного тестування сценаріїв, автоматизація критичних сценаріїв тощо.
- Обговоріть з командою й упевніться, що автоматизація справді допоможе скоротити витрати ручного тестування на виконання таких завдань.
- Переконайтеся, що ваш продукт технічно можливо автоматизувати.
Помилка № 2. Не зроблено Proof of concept перед стартом автоматизації
Багато команд, злетівши на крилах ентузіазму від ідеї автоматизації, нехтують важливим етапом — Proof of Concept (PoC) або доказ концепції. Цей етап — невеликий експеримент, який допомагає визначити життєздатність обраної стратегії автоматизації та інструментів для конкретного проєкту.
Нехтування PoC може призвести до того, що команда обере невідповідні інструменти або підходи, а це, в свою чергу, спричинить безліч проблем і може значно збільшити вартість проєкту. PoC дає змогу команді на ранньому етапі оцінити ризики, виявити потенційні проблеми та визначити, наскільки обрані інструменти та підходи відповідають вимогам і чи можливо взагалі автоматизувати продукт наявними на ринку засобами.
Наприклад, уже створивши фреймворк, ви можете зіткнутися з проблемою логіна в систему (різні капчі, двофакторна авторизація, яку не можна вимкнути тощо). Це зробить неможливим подальше тестування або сильно обмежить можливий обсяг робіт, і вам доведеться взагалі відмовитися від уже готового фреймворка або витратити додаткові зусилля на зміни.
До яких негативних наслідків це призводить:
- Витрати на переробку фреймворка. За відсутності PoC команда може змарнувати багато часу та ресурсів на інструменти або методології, які згодом доведеться змінити або відмовитися від них.
- Втрата часу. Час, згаяний на спроби адаптації до невідповідного інструменту, міг би бути використаний набагато продуктивніше.
- Фрустрація команди. Невдалі спроби впровадження можуть призвести до розчарування і демотивації команди.
Мої рекомендації:
- Перш ніж узятися за PoC, чітко визначте, що ви хочете отримати від автоматизації та які основні вимоги висуваються до інструментів.
- Обмежте часові рамки. PoC не повинен затягуватися. Він служить для швидкої оцінки, а не для повного впровадження.
- Аналізуйте результати. Після проведення PoC ретельно проаналізуйте отримані результати, враховуючи як технічні, так і бізнес-аспекти.
Proof of Concept — це не просто ще одна формальність, а важливий крок, який може заощадити масу часу, грошей і зусиль у майбутньому. Не нехтуйте цим етапом, якщо хочете, щоб ваш проєкт з автоматизації тестування був успішним і приносив очікувану користь.
Помилка № 3. Занадто рання автоматизація
Наступна поширена помилка, якої припускаються команди, — поспішне впровадження автоматизації. Це може відбуватися з різних причин, наприклад, через тиск із боку бізнесу, бажання випередити конкурентів або простого ентузіазму. Але починати автоматизацію до того, як продукт або функціональність достатньо стабілізуються (якщо, звісно, ви не впевнені в собі на 100%), — стратегія, що може призвести до маси проблем.
Ранні дії часто означають, що команда починає автоматизувати тестові сценарії для функціональності, яка ще може значно змінюватися. Це тягне за собою необхідність постійного доопрацювання та коригування автоматизованих тестів або навіть ядра фреймворку, що може стати джерелом великих часових і фінансових витрат.
Можливі негативні наслідки цього:
- Часте доопрацювання тестових сценаріїв. Функціональність або продукт, який активно розвивається, вимагатиме постійних змін в автоматизованих тестах.
- Збільшення витрат. Постійні зміни та доопрацювання тестів можуть призвести до збільшення витрат на їх підтримку.
- Нестабільні результати тестів. Постійна зміна функціоналу призводитиме до провалів тестів. Ви часто отримуватимете червоні звіти, які будуть демотивувати як команду, так і виставлятимуть автоматизацію не в найкращому світлі перед клієнтом.
Рекомендації як запобігти цьому:
- Оцініть стабільність продукту. Перш ніж почати автоматизацію, переконайтеся, що основна функціональність продукту або застосунку досить стабільна і не буде часто змінюватися.
- Почніть із критичних сценаріїв. Якщо ви все ж таки вирішили почати ранню автоматизацію, сфокусуйтеся на найбільш критичних і стабільних сценаріях. Наприклад, можна почати з тестування API, а UI-тестування відкласти до стабілізації користувацького інтерфейсу.
- Плануйте зміни. Якщо ви знаєте, що якісь частини продукту будуть змінюватися в найближчому майбутньому, врахуйте це під час планування автоматизації.
Початок автоматизації в правильний час — це ключ до її ефективності та цінності. Особливо важливо виважити готовність продукту до автоматизації та розпочати її лише тоді, коли це справді доцільно і принесе найбільшу вигоду.
Помилка № 4. Занадто складні тестові сценарії
Однією з типових помилок в автоматизації є створення надмірно складних і довгих тестових сценаріїв, надто коли йдеться про end-to-end (Е2Е) тестування користувацького інтерфейсу. Коли команди починають покладатися здебільшого на E2E-тести, минаючи інші рівні тестування, може виникнути низка проблем.
E2E-тести перевіряють систему загалом, імітуючи дії реального користувача. Вони справді важливі, але вони також є найдорожчими та потребують найбільше часу. Ускладнення сценаріїв і надмірне захоплення Е2Е-тестами може затьмарити необхідність інших типів тестування, як-от модульні або інтеграційні тести.
Можливі негативні наслідки:
- Довгий час виконання. Велика кількість довгих Е2Е-тестів збільшує час їхнього виконання, що може сповільнити процес розробки.
- Більше помилкових спрацьовувань. E2E-тести, як правило, менш стабільні через безліч зовнішніх залежностей, що призводить до частих помилкових спрацьовувань.
- Високі витрати на підтримку. Через їхню складність і довжину, Е2Е тести вимагають значних зусиль не тільки на створення, а й на підтримку.
Рекомендації від мене:
- Піраміда тестування. Дотримуйтесь принципу піраміди автоматизованого тестування: велика база швидких модульних тестів, менше інтеграційних тестів і ще менше E2E-тестів на вершині.
- Скорочення та оптимізація. Розгляньте можливість розбиття довгих E2E-сценаріїв на кілька коротких або об’єднання кількох тестів в один.
- Використовуйте паралельне виконання. Якщо у вас все ж таки багато E2E-тестів, розгляньте можливість їхнього паралельного виконання для прискорення процесу тестування.
Хоча Е2Е-тести є важливою частиною стратегії, не варто покладатися на них як на основний інструмент. Правильне поєднання різних рівнів тестування допоможе створити ефективну та стійку автоматизовану систему.
Помилка № 5. Відсутність метрик і звітності
З досвіду можу сказати, що автоматизоване тестування без належного моніторингу та аналізу — це як подорож незнайомою місцевістю без компаса. Хоча ваша система автоматизації може успішно виконувати тести, відсутність правильних метрик і звітності робить вас сліпими щодо реальної ефективності та цінності вашого тестування.
Метрики та звіти не тільки допомагають відстежувати статус і результати тестування, а й надають зворотний зв’язок щодо проблемних областей, які потребують уваги. Вони виявляють патерни, пов’язані з частими збоями, і можуть допомогти команді ухвалювати поінформовані рішення про те, де поліпшити код або тести.
Можливі негативні наслідки:
- Неможливість визначити проблемні зони. Без метрик важко визначити, які області застосунку найбільш уразливі або часто ламаються.
- Складність у визначенні ROI. Відсутність звітності ускладнює доказ ефективності та окупності впровадження автоматизації.
- Погіршення якості продукту. Без розуміння, як і де найчастіше виникають помилки, у команди менше можливостей для їхнього усунення.
Рекомендації:
- Визначте ключові метрики. Вирішіть, які метрики найважливіші для вашого проєкту. Це може містити відсоток успішних тестів, час виконання, кількість виявлених дефектів тощо.
- Використовуйте інструменти для звітності. Інтегруйте системи звітності у ваш pipeline автоматизації для автоматичного створення звітів після кожного прогону.
- Регулярно аналізуйте дані. Приділіть час постійному перегляду й аналізу метрик, щоб визначити можливі поліпшення.
Правильно обрані метрики та ефективна система звітності можуть стати маяками на шляху до високоякісної та ефективної автоматизації. Вони надають команді потрібний зворотний зв’язок і спрямовують зусилля на найважливіші сфери для поліпшення.
Висновки
Автоматизація тестування — це потужний інструмент, який, за правильного використання, може стати запорукою успішного та якісного продукту. Але без чіткого розуміння своїх цілей, вибору правильних механізмів і постійної підтримки, цей інструмент може обернутися проти вас. Дотримуючись вищевказаних рекомендацій, ви зможете уникнути основних помилок і зробити ваш процес автоматизації максимально ефективним.
13 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів