Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Опишіть automation-ціль на шість місяців без прив’язки до нового title.
Додайте очікуваний coverage, потрібний час і спосіб вимірювання користі.
Запишіть критерій, за якого внутрішній перехід вважається заблокованим і починається зовнішній пошук.
Чернетка PDP proposal та явний decision threshold.
Надійність продукту потребує coverage на кількох рівнях: static analysis, unit, integration/component і невеликий набір системних E2E tests. E2E найдовші, найдорожчі в підтримці та найповільніші для локалізації failure, тому ними не варто дублювати всі permutations. На системному рівні залишають business-critical flows, а exhaustive rules перевіряють ближче до коду. Це не фіксована «піраміда заради піраміди»: розподіл залежить від architecture і того, де виникає ризик.
Структура каталогів не визначає правильний рівень coverage. Для сучасних frameworks часто корисніше мислити test trophy або testing landscape: поєднувати static analysis, component/integration tests і лише потрібні end-to-end tests відповідно до ризику конкретної частини системи. У Java типовий layout має `src/main` і `src/test` із packages; Python та TypeScript часто відділяють application/support code від tests простіше. Naming і package layout треба брати з conventions мови та поточного repository, а не переносити механічно з іншого stack.
Перше питання — що саме болить: release speed, regressions, platform drift, backend instability, device coverage чи migration. Далі з’ясовують product architecture, team ownership, roadmap і engineering maturity. Інструмент обирається після цього. Наприклад, планована migration з native на cross-platform або навпаки змінює test seams і робить speculative framework марним.
Питання учасника: якщо `POST` повернув `200 OK` із порожнім body, чи достатньо цього для перевірки створення сутності. В event-driven архітектурі успішна відповідь може означати лише прийняття команди, а фактичний запис з’явиться пізніше, тому наступний `GET` перевіряє спостережуваний результат. Лектор розділяє два типи coverage: сценарій для конкретного ресурсу та повний business flow. CRUD/resource test локалізує помилку в операціях над сутністю; сценарний тест перевіряє, що ланцюжок бізнес-дій працює цілісно. Один тип не замінює інший, бо дефект може проявитися лише на конкретному стику.
Після узгодження behavior загальний scenario треба декомпозувати. Frontend task описує component, validation і UI states; backend task — endpoint, contract і business rule; test task — ризики й потрібне coverage. Для інженера прямий технічний опис часто коротший і точніший за повторення кожної умови через `Given/When/Then`. Проблема починається, коли один формат примусово використовують для всіх ролей. Business не має керувати деталями automation code, а automation engineer не повинен перекладати вже зрозумілий technical contract у довший Gherkin лише для формальної відповідності процесу.
Розповсюдженість мови залежить від ринку, країни й конкретного моменту. Замість абстрактного рейтингу радиться дивитися на актуальні вакансії та стеки продуктів, у яких хочеться працювати. Друга мова корисна під час migration з одного stack на інший: generated translation code все одно треба перевірити на language-specific idioms, concurrency model і зайві конструкції. Для staff/principal/SDET ролей кілька мов дають змогу працювати не лише із зовнішніми tests, а й додавати coverage та testability у frontend і backend repositories.
У прикладі suite для account management містить 12 тестів. Один ручний кейс у середньому займає 8 хвилин, отже повний ручний прогін — 96 хвилин. Автотест виконує кожен кейс приблизно за 10 секунд, а весь suite — за 120 секунд. Таблиця має зберігати щонайменше: - назву test suite або user journey; - кількість автоматизованих кейсів; - середній час ручного кейсу та всього suite; - середній час автоматизованого кейсу та всього suite; - кількість запусків за обраний період; - розраховану дельту часу. Кейси потрібно явно переводити з manual backlog до automation coverage. Інакше легко одночасно рахувати той самий обсяг як ручну та автоматизовану роботу.
Для підготовки до 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.
Знання test design, ризиків, вимог, bug reporting, Agile і тестової стратегії залишаються частиною роботи automation engineer. Quality assurance описується не як відповідальність однієї ролі, а як командний процес; автоматизація допомагає зробити його feedback loop швидшим. Якщо компанія підтримує розвиток, перехід варто зробити видимим: погодити цілі, потрібний час, очікуваний coverage і критерії перегляду ролі. Це краще за невизначене «я трохи пишу автотести», бо дає обом сторонам спостережуваний результат.
У відео test trophy протиставляється механічній testing pyramid: в основі quality gates лежать static analysis і security checks, далі — швидкі unit tests, ширший шар integration tests і невелика кількість end-to-end scenarios. Ідея — інвестувати в той рівень, де система має найбільший ризик і де перевірка дає швидкий надійний сигнал. Важливе уточнення: не слід зменшувати unit coverage лише тому, що продукт використовує Spring, Django або готову database. Не потрібно тестувати код framework; потрібно unit-тестувати власну чисту domain logic, а integration tests залишити для mappings, transactions, SQL, serialization та зовнішніх contracts.