Стажировка в QA редко начинается с красивой схемы процессов и уверенного «можно в релиз». Стажёр-тестировщик команды поиска ПСБ Вероника Железникова описала путь от страха пропустить дефект до самостоятельной работы с тест-кейсами: с первым найденным багом, ошибкой перед релизом и несколькими кругами ревью. Для IT-команд это напоминание о простой вещи: новичка в тестировании выращивают не набором терминов, а качеством обратной связи.
Историей изнутри делится Habr / Карьера. Железникова пришла в тестирование на удалённую стажировку и в первые дни столкнулась с типичным для джунов набором: незнакомая тестовая среда, слова «регресс», «смок», «релиз» и «фича» на созвонах, тревога из-за каждого вопроса в командном чате. Задача оказалась не только технической — нужно было научиться запрашивать контекст, фиксировать сомнения и не воспринимать каждую правку как приговор профессии.
Первый баг — не мелочь, а проверка процесса
Переломным моментом стал дефект в форме, которая не отправлялась. Стажёр несколько раз повторила сценарий, очистила кэш, перезагрузила браузер и только затем оформила баг-репорт со скриншотами, логами и данными об окружении. Разработчик подтвердил воспроизведение и взял проблему в работу. В QA это базовый эпизод, но для человека без опыта он важнее очередного обучающего задания: появляется связь между аккуратно описанной ошибкой и реальным изменением продукта.
Одновременно история показывает, почему фраза «тестировщик просто ищет баги» плохо описывает профессию. Найти сбой недостаточно. Нужно отделить ошибку продукта от некорректного сценария, собрать условия воспроизведения, объяснить ожидаемый и фактический результат, приложить доказательства. Если разработчик отвечает «не воспроизводится», спор решает не громкость аргумента, а точность отчёта. В случае Железниковой повторная проверка, видео и более детальное описание помогли вернуть закрытый дефект в работу.
Самый болезненный урок пришёл после допуска новой страницы к релизу. На продакшене выяснилось, что изображение не отображается в мобильной версии: при проверке в инструментах разработчика не был включён нужный режим. Ошибку не стали превращать в публичную порку. Наставница ограничилась спокойным разбором, а сама стажёрка добавила себе контрольный вопрос — проверить, что будет при других значениях и условиях. Такая реакция полезнее ритуального поиска виноватого: один пропущенный дефект превращается в пункт чек-листа, а не в повод перестать сообщать о рисках.
Тест-кейс как инструмент, а не бюрократия
Отдельной частью стажировки в QA стали тест-кейсы. Первые версии уходили на доработку по три-четыре раза: где-то шаги были расписаны чрезмерно подробно, где-то, наоборот, не хватало условий, логики или иллюстраций. Для начинающего специалиста это одна из самых неприятных зон работы. Кажется, что проверяешь одну кнопку, а документ растёт на страницу; затем ревьюер возвращает его с комментариями, и приходится заново формулировать уже знакомый сценарий.
Но именно здесь формируется навык, который ценен для всей продуктовой команды. Хороший тест-кейс должен позволить другому человеку выполнить проверку без телепатии и не утонуть в лишних действиях. Он фиксирует договорённость о том, как система должна работать, а не просто подтверждает, что автор однажды нажал кнопку и увидел ожидаемый экран. По словам Железниковой, к концу второго месяца число правок сократилось, а затем тест-кейсы начали проходить ревью без замечаний. После этого появилась следующая проблема — рутина: одинаковые поля, повторяющиеся проверки и соблазн написать «всё работает» вместо полноценной фиксации результата.
Удалённый формат делает эту рутину заметнее. В офисе можно быстро показать экран коллеге и спросить, не упущен ли сценарий; дома вопрос приходится формулировать письменно и ждать ответа. У стажёра это легко превращается в лишнюю тревогу: не отвлекаю ли я команду, не слишком ли очевидна проблема, не выглядит ли вопрос глупым. Железникова выстроила простой рабочий ритм — заранее запускать систему, делать паузы между созвонами и отделять окончание дня от постоянного присутствия у ноутбука. Для удалённой команды такие привычки не менее практичны, чем доступы к стендам и шаблон баг-репорта.
Для разработчиков и руководителей вывод тоже вполне прикладной. Онбординг QA не заканчивается словарём терминов и доступом к TestIT: нужны понятные требования, доступная наставническая помощь и культура, в которой баг можно обсудить без защитной реакции. А стажёрам полезно относиться к правкам как к данным для следующей версии работы, а не как к оценке собственной пригодности. Чем раньше команда превращает промахи в проверки и договорённости, тем меньше шансов, что мобильная версия окажется необязательным пунктом перед следующим релизом.
