Небольшая команда начинает разбираться в новой для компании доменной области. Казалось бы, что может пойти не так, ведь у нас есть отработанные процессы разработки и тестирования для ключевых продуктов. Но... Поначалу наш внутренний стартап собирал грабли: задачи появлялись в последний момент, дедлайны постоянно сжимались, времени на регресс хватало не всегда.

Расскажу, какие шаги помогли нам перейти от хаотичной разработки к предсказуемым и стабильным релизам, сделать процессы управляемыми и научиться избегать критических ошибок, встроив тестирование в каждый этап разработки.

Вас ждет история о том, как бэкенд-разработчик исправлял и дорабатывал e2e-тесты для фронтенда.

Мне досталось SPA-приложение на Angular, частично покрытое автотестами, созданными с помощью Playwright. Расскажу о его плюсах и минусах, методах борьбы с неоптимальными тестами, таймаутами, попапами и обновлениями самого инструмента.

Сегодня об AI-ассистентах для разработки и тестирования не высказывается разве что ленивый: кто-то с надеждой, кто-то — с тревогой, третьи и вовсе не верят в перспективы таких инструментов. Я руковожу командой, создающей AI-ассистент для автоматизации тестирования, а также активно слежу за успехами конкурентов. Опираясь на этот опыт, я расскажу:

- Как мы пытались решать подобные задачи без AI и что из этого получалось.
- Как устроены современные "умные" решения, сколько в них AI на самом деле.
- Как понять, стоит ли доверить написание тестов ассистенту в вашем проекте и сохранить при этом приватность кодовой базы.