Привіт, я — Марінський Роман, інженер в автоматизації тестування. Також за сумісництвом – Test Engineering Lead в Intellias, член програмних комітетів конференцій Selenium Camp та QA Fest. А ще разом з Альоною Тудан, Діаною Пінчук та Александрою Зубаль розвиваємо теплу львівську спільноту тестувальників QA Club Lviv.
Я хочу поділитись з вами своїм досвідом автоматизації тестування в одній із минулих компаній. Це був кінець 2016 року, була зима, коли я перейшов із маленької команди продуктової компанії з 5-ма різними інтернет-магазинами у велику компанію з багатьма продуктами Tickets Travel Network (tickets.ua). За плечима я мав приблизно 2 роки досвіду, і мені дали завдання автоматизувати все, бо дуже багато часу витрачалось на регресійне тестування. Дуже багато — це приблизно 10 днів * ~10 інженерів = 100 людино-днів.
Що ж, швиденько зібравши дані по компанії, по наявних продуктах, пріоритетах та проблемах, намалювалась приблизно така картина:
~10-15 інженерів у тестуванні;
~60-80 розробників;
~50 сайтів (локалізацій) із різним набором продуктів;
корпоративні рішення із різним набором продуктів;
нативні мобільні додатки;
~10 метапошуковців;
Моноліт із приблизно 3 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 для адресної книги та виконати основні операції із Git. 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 інженерів та після автоматизації займало 1 день у 2-3 інженерів, щоб перевірити розташування у пошуку та ще деякі деталі.
Після навчання автоматизації API тестування через Rest-Assured я вже мав приблизно 8 готових молодших інженерів з автоматизації тестування, які могли бути напівавтономні в автоматизації своїх продуктів. І це приблизно через пів року часу.
Спростити тестування
Для них я готував та розвивав проєкт, щоб спростити тестування їхніх продуктів. До прикладу, було корисно зробити "хелпери" для адмінки (щоб змінювати налаштування систем), хелпери для реєстрації користувачів із потрібними даними, скасування броні, створення броні тощо.
Була також своєрідна проблема в інженерів — вони не розумілися на тестуванні суміжних продуктів. Як тестування виконується, які є залежності та який  загалом стан продуктів по компанії.
Тому я запровадив практику парного тестування для всіх інженерів між різними продуктами та календар парних сесій. Сесія тривала 1-2 години для >=2 інженерів, був один інженер як власник, інший чи інші (бувало по 2-3) — як гість. Власник першу половину сесії розповідав ввідні дані по продукту, гість слухав. Друга частина сесії призначена для тестування гостем продукту "власника".
Що це дало:
універсальність інженерів для підтримки "коли що",
краще розуміння, чим живуть інші інженери та загалом компанія,
нові ідеї для тестування і "гостеві", і "власнику".
Власне системи тест-менеджменту не було, тільки чеклісти в ґуґл-доках. Тім-лід вважала, що тест-менеджмент беззмістовно використовувати в їхній ситуації, тим паче, що попередня спроба була невдалою.
Але я вирішив усе ж перевірити це. Бюджету на систему тест-менеджменту не було виділено, тому пройшовся по ринку безкоштовних систем та дуже дешевих, оцінив і спробував упровадити систему тест-менеджменту TestCaseLab — система мала мінімальний набір функціоналу та API, але більшість інженерів не хотіли приділяти їй час (не можу сказати, чому так, можете запропонувати свої варіанти 😉) та “закинули” цю ідею.
Тому, на жаль, я не зробив автоматичну публікацію стану регресій по всіх продуктах на реліз.
Результат
Скільки саме я зекономив часу (грошей) компанії — я не рахував, оскільки тоді не розумівся на метриках, як оцінювати ці інвестиції робочого часу інженерів у тестуванні у навчання у робочий час. Я знаю, що більшість з них успішно працюють як інженери в автоматизації тестування. Проєкт із тестами далі розвивався вже без мене (досі живий та підтримується), оскільки я перейшов працювати в іншу класну компанію. В новій компанії я консультував один грузинський банк щодо впровадження автоматизації тестування. Про це, скоріше за все, розповім уже в наступній статті!
