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