Июль 24

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

Привіт, я Роман Марінський, інженер в автоматизації тестування. Також за сумісництвом 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. Проте більшість інженерів не хотіли приділяли їй час (не можу сказати чому, можете запропонувати свої варіанти