Python мануфактураJavaDesign Patterns для автоматизаторів

Java · Сесії: AMA та PMP · 10:30–13:30

Домашні завдання через GitHub

[Дивитися з 10:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=630s). Щотижня очікується один або кілька нових tests. Перша домашня робота публікується як repository link; наступні — в окремих branches і pull requests порівняно з `main`. Це дає reviewer-у точний diff конкретного модуля, а учневі — невеликий, але реальний portfolio artifact. Якщо PR уже merged, треба чітко вказати commit або зміни, які відповідають домашній роботі.

Практика курсу на YOY, домашні завдання та формат ПМП →

Java · Сесії: AMA та PMP · 0:00–0:50

Гілки як знімки стану кожного модуля

[Дивитися з 00:00](https://www.youtube.com/watch?v=FQsfjR_iHoE&t=0s). Для Java- та Python-прикладів підготовлено репозиторії, де окремі гілки відповідають модулям курсу. Перемкнувшись на потрібну гілку, учень бачить реалізацію в тому стані, у якому вона була під час запису заняття. Це дає змогу звірити структуру проєкту, налаштування й код, якщо пояснення у відео було надто швидким або незрозумілим.

Репозиторій як довідник до модулів →

Java · Сесії: AMA та PMP · 2:10–5:30

Чому один Appium-сценарій не гарантує однаковий тест

Appium і WebdriverIO дають спільний зовнішній API для iOS та Android, але додають кілька шарів комунікації між тестом, Appium server, platform driver і device. Через це сценарії повільніші, а діагностика instability складніша, ніж у native tests. Одна бізнес-дія також може мати різний UI на різних платформах: date picker, введення числа, back navigation і переходи між екранами підпорядковуються різним design guidelines. Відрізняється й lifecycle: після згортання або повернення екран може відновити state з local storage чи повторно звернутися до backend. Спільний тест часто все одно отримує platform-specific branches або окремі page/screen objects.

Типи мобільних застосунків та мобільна автоматизація →

Java · Advanced: API-автоматизація · 55:00–1:05:00

Engineering process і test levels

Перед test strategy аудитять build pipelines, review, static analysis, release gates і ownership. Чим краще developers покривають domain/component behavior, тим менше QA-level E2E потрібно для тих самих branches. Це не повна «довіра» до senior developers. Позитивні critical flows і integration boundaries все одно потребують independent evidence; міняється лише обсяг duplicated low-level checks.

Стратегія тестування мультиплатформних систем →
Запитати в чаті про «branches» →