Основні помилки в автоматизованому тестуванні

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

Привіт! Мене звати Олексій, я Senior Test Automation Engineer у Sigma Software. Маю 10-річний досвід у сфері інформаційних технологій, 7 з яких в автоматизованому тестуванні, тож можу впевнено стверджувати: автоматизація тестування стає наріжним каменем успішного та ефективного життєвого циклу продукту, особливо в епоху бурхливого зростання IT-індустрії та високих темпів розробки програмного забезпечення.

Почавши в 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
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Корисна стаття, все логічно

Все по ділу, сподобалось.

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

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

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

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

Хіба ця послідовність не визначається т. зв. test pyramid?Якщо вже мова про вибір критичних або пріоритетніших сценаріїв, то в межах API чи UI

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

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

Тестова піраміда просто вказує нам на оптимальне розподілення по тестах, а не встановлює пріоритети в написанні конкретних видів тестів (unit > api > ui).

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

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

Декілька разів брала участь у fix-i тестів на новому для мене проєкті,
щоб зробити їх стабільними і приймала участь у процесі, який напевно краще назвати «ампутація» —
бо більше половини коду прийшлося видалити. І замовник/клієнт/компанія були дуже засмучені,
бо не розуміли навіщо їм end2end автоматизація,
яка дуже сильно flaky/дуже дорога/ доооовгаааааааа + ще й build-и завжди червоні.
Або навпаки, є дуже критична бага — а тести зелені і «все добре».

«Помилка 3 — занадто рання автоматизація»
Тут хочу лишити коммент, що я вважаю доречним написання автоматизації навіть на POC / MVP, але написати 1-2 тести,
У цьому випадку буде готова структура фреймворку. Можна зробити СI частину.
Також вже буде зрозуміло зі стратегією тестування (на якому environment ми будемо тестувати, що ми будемо/не будемо мокати, що ми НЕ зможемо протестувати)
Узяти дуже маленьке покриття (1 smoke test — Чому б не написати?)

«Помилка 5 — відсутність метрик»
Дуже згодна. Наприклад у нас ми додали DataDog (Grafana)
Зручно розуміти скільки ми тестів запускаємо — як часто, які тести нестабільні, які тести дуже довгі і так далі.
У двох словах — після тестів reports з кожного pipeline надсилаються у систему, що моніторить і потім дуже зручно бачити цілу картину. Дуже зручно дивитися, як виглядає тестова піраміда з усіх етапів тестування (Unit-test, integration, contract, api, end2end, etc) — можна зробити дашборд зручний.

Від себе хочу додати, що вважаю важливим:

  • Запускати тести часто / на кожен commit (якщо це НЕ дуже дорого) . Якщо дуже дорого — на кожен commit у мастер. Але краще на кожен commit у кожен бранч
  • Тести мають бути частиною pipeline де збирається build. Дуже часто роблять end2end на умовному Jenkins, а build збирає GitHub Actions/CircleCI/etc. І на Jenkins ніхто не дивиться взагалі (крім Automation QA). Набагато краще працює коли, наприклад, build збирає GitHub Actions -> значить і тести запускаємо прямо тут прям в тому ж pipeline.
  • Завжди повинні бути reports з кожного прогону тестів. На жаль, дуже багато бачила ситуації, коли reports не має (вони не згенерувалися/ зламалися/ не надіслалися/ віртуальна машина втратила Інтернет/ відпала). Був випадок, коли звіти надсилалися на пошту лише одній людині. Більше їх ніхто ніколи не міг знайти . Будь ласка ніхто ніколи не робіть так. Завжди запустили тести на CI —> attach reports після виконання . Щоб кожен міг їх знайти і подивитися.
  • Кожен у команді має змогу запустити тести локально на своєму комп‘ютері (без танців з бубном). Зручно, швидко і зрозуміло. Кожен, а не лише automation QA запускає end2end. Можливо треба створити класну доку. Можливо написати допоміжні bash/shell скрипти. Але кожен має мати розуміння і скіл запустити любий тест. Так само automation QA повинен досить легко/часто і впевнено запускати не лише end2end але й unit/ api/contract/etc . Тоді він буде добре розуміти , що тестується в тих тестах і будe легко будувати тестову піраміду.

Олексій, дякую,що підняли цю тему.

Дякую за Ваш відгук Катерина. Згоден з вашим коментарем.
По «Помилка 3 — занадто рання автоматизація» і згоден і ні. Тут треба проаналізувати проект, знайти дійсно стабільну частину і вже можна автоматизувати її. Але якщо є хочаб невеликі сумніви краще не стартувати, навіть простий РоС. Особливо якщо це fixed price.
В мене є як досвід дуже вдалго проекту на 4 місяці та автоматизацією з самого старту. Але також є і такі де ми переробляли взагалі все.
Тому треба аналізувати та прораховувати ризики.

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

Маєте поради що можна почитати в цьому напрямі?

Тут все залежить від мети тестування. У мене був випадок, коли продукт мав пройти держ. сертифікацію. Там метрика була у кількості покритих вимог і фіч.
Або можна дивитися на покриття коду: condition, decision, condition and decision, MCDC покриття.

А от час виконання і кількість дефектів — це, на мою думку, шкідлива практика.

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

Нажаль ні. По автоматизації взагалі, нажаль, дуже мало літератури.
Тут треба виходити з очикувань команди та кастмара від автоматизації. Які показники є найбільш важливими.

Якщо інтегрувати ваші звіти по авто тестам в testrail то це доволі гарний інструмент для аналізу і метрик. Є багато інфо як це можна зробити для конкреного тест фреймворка та мови програмування

Підписатись на коментарі