Пять лет назад я пришёл в стартап из двенадцати человек первым тестировщиком. Процессов не было вообще: разработчики пушили в основную ветку, релиз выкатывали по пятницам, а баги ловили пользователи в понедельник. Первые два месяца я честно пытался просто кликать по продукту и заводить тикеты, но быстро понял: без системы я утону, а команда так и не поймёт, зачем я вообще нужен.
Первое, что я сделал — перестал гнаться за инструментами. Не нужно начинать с покупки дорогого тест-менеджмента или модного фреймворка. Нужно сесть и выписать, что болит именно сейчас: где чаще всего ломается, какие релизы откатывали, какие баги дороже всего обошлись. У нас такими точками оказались оплата, регистрация и интеграция с внешним сервисом. С них и начали.
Первого QA в команду я бы советовал брать не автотестировщика, а крепкого ручного специалиста с широким кругозором. На старте важнее голова и умение задавать неудобные вопросы, чем навык писать код. Автоматизацию почти всегда включают позже, когда есть стабильные сценарии, которые не меняются каждую неделю. Мы взяли второго человека через четыре месяца после меня, и это произошло ровно в тот момент, когда я перестал успевать в одиночку.
Дальше — минимальный, но железный процесс. Мы завели единый формат баг-репорта, чек-лист на релиз и правило: задача не считается готовой, пока её не проверили. Звучит скучно, но именно эта простота спасла нас от хаоса. Я не строил тяжёлую бюрократию, только то, что реально снижало количество промахов. И да, требования мы начали разбирать вместе с продактами до разработки, а не после.
Отдельная боль — отношения с разработчиками. Если QA воспринимается как полицейский, который только ищет виноватых, ничего не выйдет. Я старался быть партнёром: показывал, как баг выглядит глазами пользователя, помогал воспроизводить, приходил на обсуждения архитектуры заранее. Так называемый сдвиг влево — это не модное слово, а конкретная привычка подключаться к задаче на этапе идеи, а не на этапе готового кода.
Автоматизацию мы начали только на втором году, когда ручная регрессия стала занимать по три дня. Сначала закрыли самые критичные и стабильные сценарии: логин, оплата, регистрация. Отдельно завели метрики — сколько багов утекает в прод, сколько времени занимает релиз, сколько критичных путей покрыто. Гнаться за стопроцентным покрытием бессмысленно, гораздо важнее понимать, какие цифры для бизнеса действительно болевые.
Когда команда выросла до пяти человек, пришлось учиться делегировать и документировать знания. Иначе отпуск или больничный одного человека парализует весь отдел. Мы завели общую базу с чек-листами, договорились о регулярных разборах и стали растить людей внутри, а не только нанимать с рынка. Культура честности важнее любых инструментов: если можно сказать «я не успел», а не спрятать проблему, отдел живёт и развивается.
Если суммировать мой путь: начните с боли, а не с инструментов; наймите сначала ручного универсала; заведите минимальные, но обязательные правила; дружите с разработчиками; автоматизируйте позже и по делу; следите за метриками и растите людей внутри. Никакой магии тут нет, только последовательность и терпение. А теперь вопрос к вам: расскажите, с чего начинался QA в вашем стартапе — что сработало, а что пришлось переделывать с нуля?
Первое, что я сделал — перестал гнаться за инструментами. Не нужно начинать с покупки дорогого тест-менеджмента или модного фреймворка. Нужно сесть и выписать, что болит именно сейчас: где чаще всего ломается, какие релизы откатывали, какие баги дороже всего обошлись. У нас такими точками оказались оплата, регистрация и интеграция с внешним сервисом. С них и начали.
Первого QA в команду я бы советовал брать не автотестировщика, а крепкого ручного специалиста с широким кругозором. На старте важнее голова и умение задавать неудобные вопросы, чем навык писать код. Автоматизацию почти всегда включают позже, когда есть стабильные сценарии, которые не меняются каждую неделю. Мы взяли второго человека через четыре месяца после меня, и это произошло ровно в тот момент, когда я перестал успевать в одиночку.
Дальше — минимальный, но железный процесс. Мы завели единый формат баг-репорта, чек-лист на релиз и правило: задача не считается готовой, пока её не проверили. Звучит скучно, но именно эта простота спасла нас от хаоса. Я не строил тяжёлую бюрократию, только то, что реально снижало количество промахов. И да, требования мы начали разбирать вместе с продактами до разработки, а не после.
Отдельная боль — отношения с разработчиками. Если QA воспринимается как полицейский, который только ищет виноватых, ничего не выйдет. Я старался быть партнёром: показывал, как баг выглядит глазами пользователя, помогал воспроизводить, приходил на обсуждения архитектуры заранее. Так называемый сдвиг влево — это не модное слово, а конкретная привычка подключаться к задаче на этапе идеи, а не на этапе готового кода.
Автоматизацию мы начали только на втором году, когда ручная регрессия стала занимать по три дня. Сначала закрыли самые критичные и стабильные сценарии: логин, оплата, регистрация. Отдельно завели метрики — сколько багов утекает в прод, сколько времени занимает релиз, сколько критичных путей покрыто. Гнаться за стопроцентным покрытием бессмысленно, гораздо важнее понимать, какие цифры для бизнеса действительно болевые.
Когда команда выросла до пяти человек, пришлось учиться делегировать и документировать знания. Иначе отпуск или больничный одного человека парализует весь отдел. Мы завели общую базу с чек-листами, договорились о регулярных разборах и стали растить людей внутри, а не только нанимать с рынка. Культура честности важнее любых инструментов: если можно сказать «я не успел», а не спрятать проблему, отдел живёт и развивается.
Если суммировать мой путь: начните с боли, а не с инструментов; наймите сначала ручного универсала; заведите минимальные, но обязательные правила; дружите с разработчиками; автоматизируйте позже и по делу; следите за метриками и растите людей внутри. Никакой магии тут нет, только последовательность и терпение. А теперь вопрос к вам: расскажите, с чего начинался QA в вашем стартапе — что сработало, а что пришлось переделывать с нуля?