Каково работать тестировщиком: плюсы, минусы и реальность

В первой статье я рассказал, что нужно знать тестировщику и как вообще войти в профессию. Во второй — как составить резюме и найти первую работу. Но есть вопрос, который не закрывает ни одна из них: а каково реально QA работать каждый день?

До IT я успел поработать в магазине медтехники (где начальник сидел у меня прямо за спиной), в автосалоне УАЗ (где начальник мог прийти на работу в изменённом состоянии сознания) и в нескольких других местах, которые объединяло одно: ощущение, что ты просто винтик, который легко заменить.

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

В этой статье я расскажу то, чего не найдёшь ни в одном описании вакансии: что реально приятно удивляет, что бесит, как устроена работа изнутри и куда можно расти. Всё из личного опыта — Мегафон, Rambler, Okko, Т-Банк, Яндекс.

Если ты ещё не определился с профессией — начни с первой статьи про то, как стать тестировщиком. Если уже учишься и думаешь о трудоустройстве — вторая статья про резюме и стратегию поиска. А здесь мы поговорим о том, что ждёт тебя после оффера.

Что приятно удивляет

Когда приходишь в IT из другой сферы, некоторые вещи кажутся нереальными. Вот три, которые удивили меня больше всего.

Тебя никто не контролирует

Свой первый рабочий день в IT я запомню навсегда. Я написал ментору в Slack: «А можно я отлучусь на часик пообедать?» Он ответил: «Мне всё равно, чем ты занимаешься — главное, чтобы задачи были выполнены».

Чтобы вы понимали контраст: на предыдущей работе в автосалоне я должен был делать вид, что занимаюсь рабочими делами, даже когда клиентов нет. В магазине медтехники я должен был быть на рабочем месте с 9 до 21, причем на другие дела не отвлечешься — начальник за спиной, поэтому сидишь, заполняешь сайт картинками товаров и их описаниями часами напролет (сейчас это все сделала бы нейросеть быстрее и намного лучше). А тут, в тестировани — полная свобода, лишь бы результат был.

И это не уникальная история моей компании — это стандарт индустрии. В большинстве IT-компаний ты сам решаешь, когда обедать, когда делать перерыв, в каком порядке делать задачи. Есть спринт, есть обязательства — а дальше ты взрослый человек. Конечно, и в IT встречаются индивидуумы, которые любят микроконтроль, — но это скорее исключение, чем правило.

За ошибки не штрафуют

На первой работе я случайно разбил тестовый айпад. Приготовился к худшему — штраф в размере стоимости (с зарплатой джуна это больно) и выговор. Так всегда было на работах, на которых я работал, и у всех в окружении.

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

Ну какой джун не клал базу данных на проде? (Если ты не знаешь, что это значит — считай, что это один из самых страшных косяков, который можно допустить.). У меня есть несколько друзей-айтишников, у которых было и это, но никаких наказаний — разбор полётов, выводы, изменение процесса, чтобы такое не повторилось. Но не наказание. В нормальных командах никого не штрафуют за ошибки.

Сравните это с розницей или общепитом, где за разбитую тарелку вычитают из зарплаты. Или с моим автосалоном, где каждая царапина на машине — это потенциальный вычет из зарплаты менеджера или препродажника. В IT такого просто нет как массового явления (опять таки, за каждую работу не ручаюсь, но общий паттерн понятен).

Твоё мнение реально учитывается

В IT есть такая штука — ретроспектива. Это регулярная встреча, на которой любой член команды может вывалить проблемы и рассчитывать, что их решат. Не «начальник решает, остальные молчат», а реальное обсуждение, где мнение джуна вполне может цениться наравне с мнением сеньора (с поправкой на конкретных людей, конечно).

Допустим, тебя бесит, что разработчики кидают задачи в тестирование за час до конца спринта. Ты говоришь об этом на ретро — и команда договаривается о правиле: задачи отдаются в тестирование минимум за день. И это реально начинает работать (а если нет — ещё пару раз им скажешь и им придется учитывать твое существование)

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

Что неприятно удивляет

Было бы нечестно рассказывать только про плюсы. Вот обратная сторона, о которой редко предупреждают.

Встречи ради встреч

Груминги, ретро, планинги, препланинги, говнонинги — и ты сидишь и умоляешь: дайте мне просто что-то потестировать.

В типичной команде у тестировщика может спокойно быть 3–5 регулярных встреч каждый день, не считая внеплановых созвонов, синков с другими командами и «давай быстро обсудим». Каждая — от 15 минут до часа. В сумме — легко теряешь полтора-два рабочих дня в неделю просто на разговоры.

А вот что действительно пугает: все лиды, которых я знаю, проводят 6–8 часов в день на созвонах. Это не преувеличение — это реальность. Когда ты растёшь до лида, твоя работа постепенно превращается из тестирования в управление коммуникациями. Но об этом позже.

Таймтрекинг

Во многих крупных компаниях существуют таймшиты — каждый день ты должен расписать свои 8 рабочих часов по задачам. Работал над задачей 2 часа — значит, надо вписать это в таймшит. Остальные 6 часов тоже нужно чем-то заполнить.

Казалось бы — мелочь. Но когда ты каждый день вынужден "подбивать" рабочее время задачками — а если у тебя реально не было задач на 8 часов работы, то приходится придумать, чем эту табличку заполнить. Даже если с задачами всё ок, то жестко трекать то, чем занимался и сколько времени на что потратил — это по факту еще одна работа, которая съедает и время, и нервы. Особенно весело, когда уходишь в отпуск — и даже на отпуск нужно списать рабочее время (да, с отдельным кодом задачи «отпуск»). А если забыл заполнить таймшит за пятницу — в понедельник прилетает напоминание от менеджера.

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

Впрочем, когда я работал в Т-Банке, там вся активность считалась автоматически — какие задачи ты трогал, что в них писал, какие статусы ставил, как взаимодействовал с гитом, сколько времени у тебя был включен корпоративный ноутбук — удобно, если ты реально работаешь все 8 часов, и очень неприятно, когда это не так.

Рутина — но другая, чем ты думаешь

Когда говорят «рутина в тестировании», обычно имеют в виду «снова и снова проходить одни и те же тесты». И это правда — но лишь половина правды.

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

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

Но, как и в любой работе, остаётся то, что делать не хочется.

Как устроена работа изнутри

Окей, плюсы и минусы разобрали. Теперь — то, о чём почти никто не рассказывает: как вообще устроена ежедневная работа в IT-команде. Этому не учат на курсах, а на собеседованиях об этом не спрашивают. Но именно это определяет твой рабочий день.

Процессы, о которых не рассказывают на курсах

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

Вот как выглядит типичный рабочий цикл в IT-команде:

Спринт (1–2 недели) — это отрезок времени, за который команда берётся сделать определённый объём работы. Все задачи планируются на спринт заранее, и в идеале к его концу они должны быть выполнены.

Стендап (15-30 минут каждый день) — короткая ежедневная встреча, где каждый отвечает на три вопроса: что сделал вчера, что буду делать сегодня, есть ли блокеры. На практике это часто превращается в «повторяю то же, что вчера» и «блокеров нет». Но иногда именно на стендапе выясняется, что половина команды заблокирована одной задачей.

Груминг (1–2 часа) — встреча, на которой команда разбирает будущие задачи: обсуждает требования, задаёт вопросы, оценивает сложность. Тестировщик здесь — один из ключевых участников, потому что именно ты первым видишь слабые места в требованиях (ведь в хорошей компании мы подключаемся ещё на этапе, когда у нас просто есть текст — и ничего больше).

Демо (30–60 минут) — обычно это такое шоу для стейкхолдеров (руководителей, инвесторов и прочих менеджеров), где в конце спринта команда показывает, что получилось. Разработчики демонстрируют фичи, тестировщик может показать найденные баги или рассказать о покрытии тестами. Но, справедливости ради, тестировщику редко получается показать что-то интересное, и мы обычно просто смотрим — но иногда полезно знать, чем же там занимаются другие команды.

Ретроспектива (1 час) — та самая встреча, о которой я уже говорил. Что пошло хорошо, что плохо, что можно улучшить. Это место, где ты как тестировщик можешь влиять на процесс.

На первый взгляд кажется, что встреч много. И это правда — их много. Но каждая из них нужна, чтобы команда из 5–10 человек двигалась в одном направлении. Без них начинается хаос. К сожалению, это необходимый tradeoff за отсутствие пермаментного контроля за каждым человеком — в ситуации, когда результат твоей работы далеко не всегда виден невооруженным взглядом.

Фича-команды vs технические команды

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

Фича-команда — отвечает за конкретный кусок продукта: каталог товаров, корзину, личный кабинет, платежи. У вас есть свои задачи, свой бэклог, свои пользователи. Работа понятная: прилетела фича — разобрали требования — разработали — протестировали — выпустили.

Техническая команда — ориентирована не на пользователей, а на другие команды. Это может быть команда логирования, инфраструктуры, рефакторинга или debug-меню. Здесь совсем другая специфика: много ресёрчей, неограниченные зоны ответственности и высокая неопределённость. Зато — если справляешься, это жирный плюс при повышении грейда.

Куда тебя определят — по большому счёту, гэмблинг. Две команды, которые на бумаге выглядят одинаково, изнутри могут быть полными противоположностями. В одной — дружная команда с адекватным лидом, в другой — токсичная атмосфера и вечный аврал. И ты не узнаешь заранее, куда попадёшь.

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

Впрочем, само знание о том, что команды бывают разные, — уже преимущество. Если на первом месте тебе не повезло с командой — это не значит, что вся профессия такая. Иногда достаточно перейти в соседнюю команду, чтобы всё изменилось.

Куда расти дальше

Один из самых частых вопросов: «А что потом? Я буду всю жизнь ручками тестить фичи?» Нет — если не захочешь. Тестирование даёт несколько чётких направлений роста. Зарплаты по грейдам я уже разбирал в первой статье — здесь поговорим про развилки.

Вертикально — лид и менеджмент

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

Но будь честен с собой: лид — это 6–8 часов созвонов в день. Я не преувеличиваю. Все лиды, которых я знаю, большую часть дня проводят в митингах: синки с командой, синки с менеджерами, 1-на-1 с каждым подчинённым, планирования, эскалации. Тестировать руками ты почти перестаёшь.

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

Горизонтально — глубже в технику

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

Тестировщик, который умеет в автоматизацию и перформанс — редкий и дорогой зверь. Таких специалистов на рынке мало, и компании готовы платить им на уровне сеньор-разработчиков. При этом ты остаёшься «руками в коде», а не «головой в митингах».

Вбок — смена профессии

Тестирование — отличный трамплин в другие IT-профессии. И это не просто слова — я видел десятки таких переходов:

QA → разработка. Особенно если ты занимался автоматизацией — переход в разработку становится естественным. Ты уже пишешь код, понимаешь архитектуру, знаешь, как работает продукт.

QA → аналитика. Тестировщик отлично понимает требования, умеет находить противоречия и задавать правильные вопросы. Это ровно то, чем занимается аналитик.

QA → продакт-менеджмент. Ты уже знаешь продукт вдоль и поперёк, понимаешь пользовательские сценарии и разбираешься в процессах. Для перехода в продакты это мощная база.

Главное преимущество тестирования как стартовой точки — низкий порог входа при высоком потолке роста. Ты можешь начать с ручного тестирования за 50–70 тысяч, а через несколько лет зарабатывать 300+ в любом из направлений.

Заключение

Тестирование — не идеальная работа. Здесь есть рутина, бесконечные встречи и таймшиты. Но для меня (и для тысяч других людей, которые пришли из «обычных» профессий) плюсы перевешивают минусы с огромным запасом.

Свобода вместо микроконтроля. Уважение вместо штрафов. Возможность влиять на процессы вместо «делай что сказали». И чёткие пути роста — хоть в менеджмент, хоть в глубокую технику, хоть в другую профессию.

Если ты читаешь эту статью — значит, ты как минимум думаешь о тестировании. И это уже первый шаг. Теперь ты знаешь не только что учить и где искать работу, но и что реально ждёт тебя по ту сторону оффера.

Хочешь попробовать — начни с бесплатного краш-курса. Уже определился — полная программа с поддержкой до трудоустройства (да и после стараюсь помогать, на самом деле).

Программа «Инженер по тестированию» · Telegram канал