Як наодинці автоматизувати тестування у продуктовій ІТ-компанії: покрокова інструкція

Привіт, я Роман Марінський, інженер в автоматизації тестування. Також за сумісництвом Test Engineering Lead в Intellias, член програмних комітетів конференцій Selenium Camp і QA Fest. А ще разом з Альоною Тудан, Діаною Пінчук та Олександрою Зубаль розвиваємо львівську спільноту тестувальників QA Club Lviv.

Хочу поділитись своїм досвідом автоматизації тестування в одній з минулих компаній. Це був кінець 2016 року, я перейшов з маленької команди продуктової компанії з 5 інтернет-магазинами у велику компанію з багатьма продуктами Tickets Travel Network (Tickets.ua). За плечима мав приблизно два роки досвіду, і мені поставили завдання автоматизувати все, бо дуже багато часу йшло на регресійне тестування. Дуже багато — це приблизно 10 днів * ~10 інженерів = 100 людино-днів.

Що ж, я швиденько зібрав дані щодо компанії, продуктів, пріоритетів і проблем, і намалювалась приблизно така картина:

• 10-15 інженерів у тестуванні;
• 60-80 розробників;
• 50 сайтів (локалізацій) із різним набором продуктів;
• корпоративні рішення із різним набором продуктів;
• нативні мобільні додатки;
• 10 метапошуковиків;
• моноліт із приблизно трьома API різного призначення;
• 10 методів оплати (на кожному сайті різні набори).

Ну і, звісно ж, розробники не писали unit та integration тести, було мало документації, відсутні тест-кейси і тест-менеджмент система. Ми мали тільки чек-листи.

Знадобився рік, щоб автоматизувати все. Що для цього треба було зробити?

Визначити пріоритети

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

Тому насамперед поговорив із Team Lead тестувальників, потім із продукт-менеджерами окремих продуктів. Так з’ясував, що саме «кульгає» в тестуванні та окремих продуктах у масштабі компанії.

Дійшли висновку, що нам потрібна автоматизація:

• купівлі авіаквитків на пріоритетних напрямках (визначені наявною аналітикою);
• купівлі залізничних квитків;
• всіх інших роздрібних продуктів компанії;
• корпоративних рішень;
• переходів з метапошуковиків (Aviasales, Momondo, Skyscanner).

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

Перше, за що взявся, — це автоматизація купівлі авіаквитків на найприбутковіших для компанії сайтах. Таких платформ було 8. Щоб спростити собі завдання, оформив документ, в якому описав, де та на яких елементах має бути дата-атрибут та з яким значенням, і вклав його в таск для FE-розробників.

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

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

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

Для навчання інженерів я підготував план занять, передусім з вивчення Java, а потім для обгортки над Selenium — Selenide. Також після того спеціалісти проходили курси з JMeter, Postman та Rest Assured. Такому набору є просте пояснення:

• із цим стеком добре ознайомлений;
• багато готових матеріалів з навчання;
• чимало інженерів на ринку (досвідчених і не дуже досвідчених);

Я не використовував інструмент Selenium IDE і keyword-driven підхід, оскільки вони не дуже гнучкі, а цільові системи не тривіальні.

Програма курсів містила:

• основи Java та ООП;
• Git;
• автоматизацію перевірок UI з Selenide та патерни;
• основи API тестування з Postman;
• тестування працездатності з JMeter;
• автоматизацію перевірок API з Rest Assured.

Після кожного заняття давав домашню роботу, щоб поза лекцією інженери приділили час навчанню. Укінці спеціалісти писали «курсову», адресну книгу з Java. Наприклад, завдання для роботи Git — це створити репозиторії у Bitbucket для адресної книги та виконати основні операції. UI/API автоматизація — це домашки, пов’язані з продуктами, з якими спеціалісти стикалися під час роботи.

Перший курс із Java був для всіх інженерів, 14 спеціалістів. Після перших 2-3 зустрічей стало зрозуміло, що потрібно ділити їх на кілька груп: хтось краще засвоював інформацію, хтось гірше. Сформував на свій розсуд групи по 4-5 людей, відповідно до рівня компетенції. На тиждень була запланована одна лекція та індивідуальна домашка. Всі заняття відбувалися у робочий час.

Спочатку я читав лекцію для «найматьоріших», потім для середнячків, відтак для найслабших. Такий підхід сприяв кращому засвоєнню матеріалу в кожній групі. Іноді бували «рокірування» учнів, дехто мав бажання відвідувати заняття двічі на тиждень. Коли вже почали вивчати автоматизацію дій у браузерах через Selenide, більшості стало цікавіше виконувати домашні завдання, оскільки вони стосувалися реальних продуктів, з якими колеги працювали. Також частину навчального матеріалу давав на самостійне вивчення, так спеціалісти проходили матеріал з іншою подачею. Варіативність подання матеріалу в навчанні — це дуже ефективна штука, як виявилось.

Організація проєкту з автотестами

Щоб легше підтримувати та розвивати проєкт з автоматизованими тестами, організував його на основі різних Java-модулів: core, core_ui, core_api, avia, railway, insurance тощо. І під кожен продукт компанії або під кожного інженера був окремий модуль, в якому можна було працювати та писати автоматизовані тести. А я спостерігав за роботою через Merge requests, консультував і стежив, що ще можна винести в core-модулі для повторного використання.

Автоматизація перевірки переходів з метапошуковиків

Також був великий шмат роботи для інженерів: ручна перевірка переходів з метапошуковиків (Aviasales, Momondo, Skyscanner тощо) за визначеними маршрутами на визначені сайти.

Оскільки метапошуковики мали антибот-захист, то тільки через UI це неможливо було виконати. Для цього потрібно було використати наявний API, через який вони здійснювали пошук у нашій системі з різними параметрами. Був складений напівавтоматично, на основі даних з адмінки, досить великий JSON-файл із переліком даних: метапошуковик, службові параметри, найпопулярніші маршрути, цільовий сайт для редиректу.

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

• чи виконується редирект на відповідний сайт;
• скільки часу виконувався запит;
• які методи оплати доступні.

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

Після навчання автоматизації API-тестування через Rest Assured я вже мав приблизно 8 підготовлених молодших інженерів, які працювали напівавтономно в автоматизації своїх продуктів. І це приблизно за пів року.

Спростити тестування

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

Крім того, в інженерів була проблема — вони не розумілися на тестуванні суміжних продуктів. Як тестування виконується, які є залежності та який загалом стан продуктів.

Тому я впровадив практику парного тестування для всіх інженерів між різними продуктами та календар парних сесій. Сесія тривала 1-2 години для щонайменше двох інженерів. Один інженер у ролі власника, інший чи інші (бувало й 2-3) — у ролі гостя. Власник першу половину сесії розповідав вхідні дані щодо продукту, а гість слухав. Друга частина сесії призначена для тестування гостем продукту.

Що це дало:

• універсальність інженерів для підтримки «раптом що»;
• краще розуміння, чим живуть інші інженери та загалом компанія;
• нові ідеї для тестування.

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

Але я вирішив все ж перевірити це. Бюджету на тест-менеджмент систему не виділили, тому пройшовся по ринку безкоштовних і дуже дешевих систем, оцінив і спробував упровадити тест-менеджмент систему TestCaseLab. Вона мала мінімальний набір функціоналу та API. Проте більшість інженерів не хотіли приділяли їй час (не можу сказати чому, можете запропонувати свої варіанти 😉) та закинули цю ідею.

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

Результат

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

Ретроспектива

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

Що було зроблено добре:

• визначення пріоритетів на основі наявної аналітики та поставлених вимог від СЕО, менеджерів і тестувальників;
• навчання всіх інженерів з тестування автоматизації перевірок UI та API;
• динамічна адаптація навчання під бажання та можливості інженерів;
• впроваджена практика парного тестування. Хай вона була в активній фазі тимчасово, проте це поліпшило майбутню колаборацію інженерів між проєктами;
• Безкоштовна спроба впровадити тест-менеджмент систему.

Що можна було б поліпшити?

Спрямувати частину автоматизації на розробників (Shift Left)

Беручи до уваги методи Shift Left і Shift Right, я зробив би так, щоб саме розробники використовували результати прогону автоматизованих перевірок. Ба більше — підходив би ближче до технологічного стека розробників.

Тобто бекенд — мовою бекенду, фронтенд — мовою фронтенду. Що зрозуміліші результати прогону перевірок розробникам, то вища імовірність того, що спеціалісти регулярніше будуть цей інструмент використовувати у повсякденні. Це були б інтеграційного рівня тести з «моками» та «стабами» внутрішніх чи зовнішніх сервісів. Це технологічно складніше, але результати прогону таких тестів розробники отримують швидше.

Front-end

Автоматизував би за допомогою Playwright або Cypress або Puppeteer, залежить від того, що більше сподобається розробникам. Оскільки «селеніумом» не так просто перевіряти надіслані запити та «мокати» відповіді від сторонніх сервісів, щоб перевірити більшу кількість станів UI-компонента.

Back-end

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

Залежно від архітектури та технологічного стека є свої обмеження.

• Не все так грамотно розроблено, щоб усе можна було замокати.
• Не все так легко підняти для локального запуску системи.
• Не все так легко підняти в Docker.

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

Operations

CI/CD pipeline

• Впровадити статичний аналіз коду як Quality gate для кожного коміту. Оскільки статичні аналізатори коду працюють швидше за компіляцію та збірку проєкту, статичні аналізатори швидше сповіщають про потенційні проблеми в коді. Та відповідно статичний аналіз коду буде як перший крок пайплайну.
• Запуск unit та integration тестів.
• Код-рев’ю із погодженням одного або більше інженерів.
• На Pull/Merge Request підіймати динамічне оточення із новими змінами, для якого будуть запускатись smoke та sanity набори тестів, щоб розробники швидше розуміли, чи не зламані базові можливості системи, та власноруч в ізольованому оточенні перевіряли руками оновлений функціонал.
• DEV та SIT оточення тримати у стабільному стані. Це можливо, якщо взяти це за правило та невпинно дотримуватися цього.
• Частіше деплоїтись на продакшн, хай і з малими змінами. Що менші зміни, то менша імовірність зламати зворотну сумісність системи (залежить від архітектури та, звісно, розташування зірок на небі 😉)

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU