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