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

Python мануфактура · Сесії: AMA та PMP · 14:30–17:00

Test trophy і правильний розподіл перевірок

У відео 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.

Автомтизація баз даних та що з тим робити та що знати →

Python мануфактура · Сесії: AMA та PMP · 18:40–21:25

Balanced coverage замість сотень E2E scenarios

Надійність продукту потребує coverage на кількох рівнях: static analysis, unit, integration/component і невеликий набір системних E2E tests. E2E найдовші, найдорожчі в підтримці та найповільніші для локалізації failure, тому ними не варто дублювати всі permutations. На системному рівні залишають business-critical flows, а exhaustive rules перевіряють ближче до коду. Це не фіксована «піраміда заради піраміди»: розподіл залежить від architecture і того, де виникає ризик.

Чому критикують BDD і Cucumber →

Java 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.

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