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