Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Окрім технічних умінь, важлива здатність прямо комунікувати проблеми з developers і managers. Рівень найму залежить від процесів: що гірше організовані documentation, buddy support і onboarding, то досвідченішу людину доведеться брати для самостійного проходження невизначеності. Сильні процеси дозволяють успішно інтегрувати менш досвідченого спеціаліста.
Автор навчає автоматизації з 2017 року. Раніше типовий курс починався з теорії мови програмування, потім переходив до ООП і патернів, а лише після цього — до автоматизації. На практиці такий довгий шлях виявився складним не лише для початківців, а й для людей із певним досвідом. Цей курс побудовано інакше: практична ціль з’являється раніше за повне теоретичне пояснення. Теорія вводиться тоді, коли вже зрозуміло, яку проблему вона допомагає розв’язати.
Окремий generator може повертати не одне поле, а цілісний `User`, `Company` або `Product` з усіма значеннями, які тест перевірятиме далі. Частина полів випадкова, частина належить до обмеженого набору, частина приймається як parameter. Такий обʼєкт є очікуваною моделлю даних сценарію; окремі actions використовують його для onboarding, create або update через API чи UI.
Базовий onboarding для всіх рівнів включає documentation, доступи, checkout репозиторію та перевірку Jira/CI. Наступну невелику задачу варто обрати за конкретним плюсом, заради якого людину наймали: fintech, maps, CAPTCHA, OTP чи інша domain expertise. Від senior очікується ширше дослідження infrastructure, access, environments і rate limits; middle може зосередитися на локальній реалізації.
Для підготовки до mobile testing перелічено не лише UI automation: типи застосунків, real device проти simulator/emulator, cloud device farms, network variability і traffic sniffing, distribution builds, роботу з Android Studio та Xcode, device fragmentation і різницю між Android та iOS design guidelines. Функціональне покриття має враховувати OAuth/login, in-app purchases, notifications, offline та error handling, deep links, різні клавіатури, clipboard, permissions під час onboarding, дзвінки та перемикання між apps, screen rotation, GPS simulation, installation/update compatibility і localization. Окремий шар — mobile performance: CPU, GPU, memory, battery і device logs.
Business зазвичай цікавить, чи можна продемонструвати й продати ключовий flow, чи стабільний продукт і чи не блокують bugs інвестиції або клієнтів. Формат внутрішньої документації другорядний, доки він допомагає команді передбачувано delivery-ити результат. Додаткові process artifacts стають виправданими, коли зменшують реальну проблему: часті incidents, втрату domain knowledge, складний onboarding або неоднозначні requirements. Сам по собі Gherkin не виправляє низьку якість implementation чи відсутність coverage.
Для складних API-тесів недостатньо знати request syntax. Потрібно «занурюватися» у систему: знаходити природу помилки, відтворювати ланцюжок залежностей і розуміти, де закінчується контракт однієї частини і починається інша. Автор радить підтримувати живу діаграму у Figma або Miro: ліворуч — архітектура і зв’язки, праворуч — test baselines і шаблони перевірок для окремих components. Така карта покращує онбординг, локалізацію дефектів і планування покриття.
У banking та інших регульованих доменах onboarding може проходити довгий Business Process Management flow з compliance-перевірками. Одна сутність не завжди може одночасно рухатися двома переходами стану, тому паралельні тести на спільному профілі конфліктують або блокують processing. Для стабільної автоматизації потрібно знати state machine, зовнішні залежності та правила блокування. Якщо динамічне створення неможливе, керований pool тестових сутностей має враховувати їх поточний стан, reservation, recovery після падіння тесту та регулярне відновлення після refresh середовища.