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

Сейчас у нас self-hosted продукт, и релизимся мы каждые 28 дней. Следующая цель — перейти на 14. На словах звучит бодро. На практике сразу появляются вопросы: что должно происходить между “разработчик закончил” и “поехали в релиз”, чтобы качество не посыпалось.

С этой болью я и пошел поговорить с Сашей автором канала «тестируй, душни, наслаждайся». Хотел не теории, а практического взгляда со стороны QA: что реально помогает релизиться чаще и где обычно все начинает трещать.

Забрал из разговора несколько полезных мыслей.

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

Отсюда вторая мысль: полезно маркировать задачи, которые вернулись с багом. Не чтобы искать виноватых, а чтобы собирать показатели процесса. Иначе качество обсуждается в стиле “ну вроде нормально” или “что-то часто возвращается”. А когда есть хотя бы простая метрика по возвратам, разговор уже становится предметным.

Еще одна здравая практика — смоук на каждом этапе: - на тестовом окружении, - на pre-prod, - на prod.

Мне понравилась сама логика: не просто “смоук нужен, потому что так принято”, а чтобы понимать, на каком этапе появляется проблема.

Но, наверное, самая полезная часть разговора для меня была про рост тестировщиков.

Потому что “прокликать задачу” — это вообще не описание профессии. Это только самый базовый уровень. Дальше начинается реальная ценность.

Здесь Саша дал очень простую рамку, которая мне прям зашла: - начинающий — понимать - middle — делать - senior — учить

То есть начинающий тестировщик должен понимать базу: API, логи, DevTools, Postman, SQL. Middle — уже использовать это в работе: дергать ручки, проверять данные, копать глубже. Senior — не просто уметь сам, а помогать другим, объяснять и наводить порядок там, где у остальных уже легкая паника.

Мне еще понравилась мысль, что хороший тестировщик — это не человек, который просто пишет “не работает”. Это человек, который глубоко знает продукт и умеет максимально сузить проблему: как воспроизводится, что ожидалось, что получилось, где именно это видно и что уже удалось проверить.

После разговора у меня осталось простое ощущение: частые релизы — это не только про CI/CD и автотесты. Это еще и про довольно земные вещи: нормально нарезанные задачи, понятные смоуки, прозрачные ожидания от QA и команда, где тестировщик не просто “проверяет”, а реально снижает хаос.

Спасибо Саше за разговор — было очень полезно.

А теперь интересно сравнить с вашим опытом: что у вас сильнее всего влияет на возможность релизиться чаще — автоматизация, декомпозиция задач, сильные QA или что-то еще?