Привіт, я — Марінський Роман, інженер в автоматизації тестування. Також за сумісництвом я – 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, але більшість інженерів не хотіли приділяти їй час (не можу сказати, чому так, можете запропонувати свої варіанти 😉) та “закинули” цю ідею.
Тому, на жаль, я не зробив автоматичну публікацію стану регресій по всіх продуктах на реліз.
Результат
Скільки саме я зекономив часу (грошей) компанії — я не рахував, оскільки я тоді не розумівся на метриках, як оцінювати ці інвестиції робочого часу інженерів у тестуванні у навчання у робочий час. Я знаю, що більшість з них успішно працюють як інженери в автоматизації тестування. Проєкт із тестами далі розвивався вже без мене (досі живий та підтримується), оскільки я перейшов працювати в іншу класну компанію. В новій компанії я консультував один грузинський банк щодо впровадження автоматизації тестування. Про це, скоріше за все, розповім уже в наступній статті!
