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