Автоматизація тестування на проектах: роль та результати впровадження 8 Автоматизація тестування на проектах: роль та результати впровадження 9 Автоматизація тестування на проектах: роль та результати впровадження 10

Автоматизація тестування на великих проектах: для чого і як ми її здійснюємо

#Бізнес #Розробка

До випуску "в люди" будь-який програмний продукт (сайт, додаток) проходить довгий шлях перевірок і допрацювань, доки він на 100% не відповідатиме сподіванням користувачів. Перевірка якості ПЗ, відповідності заявлених до нього вимог і реальної функціональності, пошук і виправлення помилок (багів) і усунення дефектів — ці та інші задачі вирішує тестування. Воно потрібно як самим розробникам, щоб побачити готовність продукту до ринку, так і замовникам — щоб переконатися, щоб бюджет витрачений не даремно.

Різниця між ручним і автоматизованим тестуванням

Ручне тестування (manual testing) — класичний метод оцінки якості ПЗ, коли тест-кейси запускаються без використання засобів автоматизації: тестувальники вручну проходять тестові сценарії і складають звіти про помилки. Цей процес досить трудомісткий і тривалий, без поєднання з автотестами використовується тільки на невеликих проектах. 

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

Щоб говорити про автоматизацію тестування предметно, розглянемо приклади її впровадження в наших проектах: системі управління школою дистанційного навчання (на базі Source LMS), healthcare-проекті та великому онлайн-магазині.  

Для чого потрібні автотести на великих проектах? Наш досвід

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

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

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

Що входить в критичний і некритичний функціонал проекту

Критичні сценарії — сценарії, помилки в роботі яких принесуть клієнтові збиток, завадять отримати очікуваний прибуток. Наприклад, для e-commerce проектів це процес пошуку і покупки товару, реєстрація і авторизація. 

Так, в автоматизації проекту інтернет-магазину в основні сценарії входить додавання товару до кошика з різними параметрами, перехід у картку товару і перевірка правильності даних в ній, оформлення замовлення з вибором опцій доставки та оплати. В роботі healthcare-порталу ці сценарії включають роботу з купонами (завантаження, покупка, отримання, відображення) для зареєстрованих і незареєстрованих користувачів.

Приклад одного з автоматичних тестів в системі управління школою: авторизація на сайт, вибір зі списку контролю знань необхідної перевірки (набір питань з варіантами відповідей), повне проходження контрольного завдання і отримання результату (оцінки в балах). Його ми розглянемо нижче.

contact Evergreen

Чи треба тестувати некритичні сценарії? 

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

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

Коли ми проводимо автотестування?

Перевірки за допомогою автотестів проводяться перед релізами, а також планово за розкладом: 

  • на healthcare-проекті автотести запускаються щодня о 3 годині ночі (час вибрали емпірично);
  • для проекту онлайн-школи запуск тестів обов’язково здійснюється в ручному режимі на тестовому середовищі (до релізу), а потім на продакшені (після релізу). Специфіка проекту і характер релізів не вимагають постійного моніторингу — тести не використовуються в якості підтримки;
  • на проекті онлайн-магазину автотести інтегровані у всі процеси: запуск до релізу на тестовому середовищі, на продакшені після релізу, періодичний запуск у якості моніторингу.

Для всіх проектів можна запустити тести вручну шляхом виконання скрипта з консолі або з використанням інтерфейсу Gitlab.  

Техстек та вибір поточних рішень

Репозиторії з автотестами для всіх проектів лежать, а як основний стек був обраний Playwright + Jest. Такий варіант має ряд переваг: 

  • великий набір вбудованих інструментів, який добре підтримується, дозволяє швидко писати тести без необхідності створювати перевантажену архітектуру фреймворка;
  • тести розгортаються на необхідному середовищі з мінімальними затратами часу, офіційний Docker image;
  • надає список доступних пристроїв і браузерів, який легко конфігурується і повністю покриває потреби на проектах;
  • підтримка для автоматичних тестів потрібна рідко і не займає багато часу;
  • Playwright швидко розвивається, використовується в багатьох компаніях і має добру підтримку.

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

На проекті інтернет-магазину випробували стек Java + Selenium. Наш відділ тестування зупинився на ньому, щоб розширити використовувані технології в автотестуванні та створити більш складний по архітектурі фреймворк. Цей стек зарекомендував себе при написанні найрізноманітніших тестів і відмінно підходить для перевірки end-to-end сценаріїв.

При створенні автотестів для healthcare-порталу ми обрали зв’язку Python + Selenium. Це перший проект, на якому з'явилася автоматизація тестування в компанії, і вибір мови програмування і фреймворка саме такий в силу експертизи команд розробки, тестування і DevOps.

Як відбувається автотестування

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

Сам процес автоматизації тестування зазвичай проходить так: 

  • запуск (ручний або автоматичний за розкладом) зі стандартними/обраними параметрами;
  • виконання тесту: автоматично покроково виконуються сценарії згідно з тестовою документацією;
  • отримання результатів тесту;
  • аналіз отриманих результатів. 

На нашому healthcare-проекті тести перезапускаються автоматично, якщо на одному з кроків сталася помилка.

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

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

Приклад автоматичного проходження уроку в онлайн-школі:

1. Автотест запускається вручну або автоматично за розкладом на сервері.

2. Автоматично відкривається браузер, вибраний в скрипті для запуску (будь-який, наприклад, Chromium). При запуску за розкладом із сервера автотест працює в headless-режимі.

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

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

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

6. Коли урок пройдений, на сторінку виводиться оцінка “автостудента”. Очікуваний результат — 12/12 балів.

7. Після закінчення тесту вікно браузера автоматично закривається, а інформація виводиться в консолі:

  • результат PASS або FAILED;
  • тип браузера;
  • кількість пройдених і запущених тестів (у прикладі — 1);
  • час проходження.

автотест прохождение урока

Результати можна зберігати в базі, передавати на пошту, виводити коментарем до задачі.

Автотест перевірки роботи калькулятора вартості аналізів на healthcare-порталі:

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

2. На головній сторінці сайту автоматично вводяться реєстраційні дані для входу в особистий кабінет.

3. З кабінету скрипт переходить в калькулятор і випадковим чином вибирає місто для підрахунку вартості пакета аналізів.

4. Додавання декількох аналізів до кошика, розрахунок оптимальних тарифів. На екран виводяться підібрані знижки і вибрані пропозиції.

5. Дії повторюються для інших випадково вибраних міст.

автотест калькулятор анализов

Результати проходження виводяться на екран або надсилаються на пошту. 

Результати після впровадження автотестів на проектах:

Скоротили час на тестування

По проекту онлайн-школи час тестування скоротився в середньому на 20%: 

  • без автотестів проходження кейсу вручну займає від 15 до 30 хвилин, ще 10-15 хвилин — підготовка тестових даних (у разі помилки кейс доведеться проходити повторно);
  • з автотестами кейс виконується за 1 хвилину, на запуск і перегляд результатів витрачається 10 секунд. Не треба готувати тестові дані, що економить час і виключає помилки при підготовці тестів.

На healthcare-проекті до автоматизації ручне виконання тестових сценаріїв займало 30-40 хвилин і було обов’язковим при кожному циклі тестування. Тоді як автотести повністю відпрацьовують за 10-12 хвилин.

Покращили тестове покриття   

При тестуванні функціоналу онлайн-школи частину кейсів все одно потрібно виконувати вручну. Однак кейс з автоматизацією покриває в середньому 15-20% всього тестування для більшості релізів. У рідкісних випадках (при відсутності змін в модулях, не покритих автотестами) цей показник може доходити до 60%.

Розвантажили команду

На healthcare-проекті автотести скоротили час на тестування на 99% — тестувальник залучається на проект вкрай рідко, і якщо залучається, перевіряє результати виконання тестів. 

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

Постійно моніторимо стан системи

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

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

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

25.02.2021
Зображення, використані в статті, були взяті з відкритих джерел і використовуються як ілюстрації.
Хочете обговорити ваш проект або замовити розробку?
Отправить
Цей сайт є українською мовою. Ви можете переключити мову у меню, або зробити це зараз.