Один QA в команде — это не QA Lead. Это просто один QA

Вступление

Есть довольно распространённая история: человек приходит в компанию, а там он единственный QA в команде. Иногда единственный QA на продукте. Иногда вообще единственный QA во всей обозримой вселенной.

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

С другой стороны, есть нюанс.

Когда вы один QA в команде, вы очень быстро становитесь всем сразу: ручным тестировщиком, автоматизатором, QA Lead, QA Architect, QA Head, отделом контроля качества, комитетом по релизам и иногда человеком, который просто «посмотрит, почему на проде всё красное».

И вот тут начинается самое интересное.

Сначала кажется, что это рост

Первые месяцы в такой роли могут быть очень полезными.

Вы быстро становитесь самостоятельнее. Начинаете лучше понимать продукт, бизнес-логику, команду, релизный цикл. Учитесь не ждать, пока кто-то принесёт готовый процесс, а строить его сами.

• Нужно договориться с разработчиками? Договариваетесь.
• Нужно описать регрессию? Описываете.
• Нужно понять, какие автотесты нужны? Решаете.
• Нужно разобраться, почему после релиза пользователи нашли то, что вы не нашли? Тоже к вам.

Это правда развивает. Особенно если до этого человек работал в большой QA-команде, где всё уже было придумано до него: тест-менеджмент, процессы, автотесты, релизные критерии, отчётность, зоны ответственности. Когда вы один, спрятаться не за кого. И в этом есть большой плюс.

Вы начинаете видеть продукт целиком, а не только свой маленький кусок. Учитесь думать не задачами, а рисками. Не «я проверил тикет», а «мы вообще можем это выпускать или нет?».

Проблема начинается чуть позже.

Потом свобода превращается в вакуум

Когда вы долго работаете один, у вас почти нет профессионального зеркала.

• Некому сказать: «Слушай, а почему ты тестируешь только happy path?»
• Некому спросить: «А зачем здесь E2E, если это можно закрыть интеграционным тестом?»
• Некому подсветить: «У тебя автотесты вроде есть, но они проверяют не поведение системы, а то, что сегодня случайно совпало с моками».
• Некому провести нормальное ревью тест-дизайна, а не просто посмотреть, что в коде нет лишнего пробела.

И это очень коварная штука.

Потому что внешне всё может выглядеть хорошо. Задачи тестируются, баги заводятся, регрессия проводится, автотесты какие-то есть, команда довольна. Разработчики говорят: «Ну вроде нормально». Менеджер говорит: «Класс, у нас есть QA». Бизнес говорит: «Главное, чтобы не падало».

А внутри постепенно формируется ощущение: «Я тут вообще-то весь QA-процесс построил. Я, получается, уже почти QA Lead». И формально даже не поспоришь. Если вы один, то вы действительно главный QA. Просто потому что других нет.

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

Это разные вещи.

Разработчики не всегда могут заменить QA-ревью

Часто в таких командах говорят: «Ну у нас же разработчики ревьюят автотесты». И это хорошо. Лучше так, чем вообще никак.

Но здесь есть важный момент: разработчик чаще всего смотрит на тесты как на код. Он может заметить плохое именование, дублирование, странную структуру, неудачный абстрактный класс, кривой await или магическую константу.

Но QA-ревью — это не только про код. QA-ревью — это вопрос: а мы вообще то проверяем?\

• Покрываем ли мы реальные риски?
• Есть ли негативные сценарии?
• Не спутали ли мы интеграционный тест с E2E?
• Не строим ли мы огромную пирамиду из UI-тестов, потому что так проще думать?
• Не проверяем ли мы в автотестах реализацию вместо поведения?
• Не создаём ли мы такой набор тестов, который через полгода будет страшно трогать?

Разработчик может быть очень сильным инженером, но он не обязан развивать вас как QA. У него другая профессиональная оптика. Он может помочь сделать код лучше, но не всегда поможет сделать лучше именно тестирование.

И если рядом нет сильного QA, который задаёт неудобные вопросы, человек начинает вариться в собственном подходе. А собственный подход без критики очень быстро начинает казаться единственно правильным.

«Я всё это уже видел»

Самая опасная фраза после нескольких лет одиночной работы: «Я всё это уже видел».

На самом деле человек видел не всё. Он видел свой продукт, свою команду, свой релизный процесс, свои ограничения, свою боль и свои костыли. Это ценный опыт, но это не вся индустрия.

Можно три года быть единственным QA в команде и ни разу нормально не столкнуться с контрактным тестированием. Можно пять лет писать автотесты и не понимать, чем E2E отличается от интеграционного теста. Можно годами проводить регрессию и не уметь объяснить, как она должна встраиваться в релизный цикл. Можно быть «QA Lead» на бумаге и никогда не проводить ревью чужого тест-дизайна, потому что чужого тест-дизайна просто не было.

А потом человек приходит на собеседование в более зрелую команду — и реальность начинает неприятно хрустеть.

Его спрашивают не про то, как он «проверял задачи», а как он принимал решения о покрытии.
Не просто «писал ли автотесты», а почему выбрал именно такой уровень тестирования. Не «есть ли регрессия», а как она формируется, кто её поддерживает, как она связана с рисками и релизами. Не «работали ли с CI/CD», а какие проверки должны запускаться на pull request, какие перед релизом, какие ночью, а какие вообще не надо гонять постоянно.

И вот тут выясняется, что человек действительно много работал, много делал, много тащил — но развивался в очень узком коридоре. Просто этот коридор был настолько длинным, что начал казаться целым миром.

Проблема не в одиночной работе, а в отсутствии сравнения

Важно: сама по себе работа единственным QA — не зло.

Иногда это нормальный этап. Маленькая команда, ранний продукт, ограниченный бюджет, стартап, внутренний сервис, быстрый рост. Не всегда можно сразу нанять полноценный QA-отдел, лида, автоматизаторов, тест-аналитиков и человека, который будет красиво рисовать тестовую пирамиду на митингах.

Проблема не в том, что QA один.

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

• Полезным — потому что он закрывает кучу задач.
• Уязвимым — потому что не понимает, где его реальные границы.

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

Ещё одна побочка — тяжёлая адаптация к команде

После нескольких лет одиночной работы бывает сложно попасть в QA-команду.

Потому что там внезапно есть правила. Есть ревью. Есть договорённости. Есть чужие мнения. Есть зоны ответственности. Есть люди, которые могут сказать: «Нет, мы так не делаем». И это может восприниматься почти как личное оскорбление.

Человек привык, что он сам решает, как правильно. А тут оказывается, что правильность нужно обсуждать, аргументировать и иногда менять свою точку зрения. В одиночной роли легко привыкнуть к позиции: «Я отвечаю за всё, значит, я лучше знаю». В команде так не работает. Там важно не только уметь делать, но и уметь договариваться, объяснять, принимать критику, ревьюить других и самому проходить ревью без внутреннего пожара. Это тоже навык. И он не появляется автоматически только потому, что человек много лет «тащил QA».

Что делать, если вы тот самый один QA?

Первое — не обесценивать свой опыт.

Если вы один закрывали тестирование продукта, это действительно сильный опыт. Вы наверняка научились самостоятельности, ответственности, коммуникации с разработчиками и пониманию продукта. Это не «ненастоящий опыт». Но важно не путать его с полной картиной индустрии.

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

Очень полезно задавать себе неприятные вопросы:

• Почему мы тестируем именно так?
• Какие риски мы не покрываем?
• Какие тесты у нас лишние?
• Что сломается, если продукт вырастет в два раза?
• Смог бы другой QA разобраться в моих автотестах?
• Я правда выбрал хороший подход или просто привык к нему?
• Что я не знаю из того, что уже давно считается базой в других командах?

И, наверное, главный вопрос: если бы завтра в команду пришёл сильный QA Lead, сколько моих решений он бы оставил без изменений?

Ответ может быть неприятным. Но именно с него обычно и начинается рост.

Вместо вывода

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

Самое опасное в одиночной работе не нагрузка. И даже не отсутствие QA Lead над головой. Самое опасное — отсутствие зеркала. Потому что без него очень легко перепутать рост с привычкой, ответственность с экспертизой, а одиночество в роли — с лидерством.

И если вы один QA в команде, это не значит, что всё плохо. Но это точно значит, что развиваться придётся не только внутри проекта, но и за его пределами. Иначе однажды можно обнаружить, что вы несколько лет были QA Lead, QA Architect и QA Head одновременно — правда, только в компании из одного человека.