Если вы только входите в профессию и ищете практичные советы начинающим QA, подпишитесь на канал «#ПоварВ IT» — здесь мы не только разбираем технику, но и учимся готовить свою карьеру в тестировании без пригоревших релизов и хрупкого самооценочного суфле.
Помню, как в первый месяц работы я пропустил критический баг: на тестовом стенде кэш был отключён, а в бою — включён. На проде корзина «залипала», и пользователи не могли удалить товар. Я молчал полдня, боялся задать «глупый» вопрос и ещё больше — признаться, что не понимаю, почему в логах всё «тихо».
Если вам знакомо это ощущение растерянности — вы не одни. Эта статья — тот гид, которого не хватало мне тогда. Подпишитесь на «#ПоварВ IT», чтобы не идти этим путём в одиночку: я делюсь разборами, шаблонами и психологическими лайфхаками из реальной практики.
Дальше — пять «банальных» ошибок, которые я делал сам. Банальные — не значит безвредные. Но каждая из них лечится: знанием, системой и заботой о себе. Это не просто техника; это про то, как стать QA, который растёт устойчиво и без выгорания.
Ошибка 1: «Молчание — не золото» (страх задавать «глупые» вопросы)
Суть проблемы: Новичок боится уточнять требования, окружение и ожидания. В итоге тестирует «как понял» и часто мимо цели.
Личная история: На одном проекте мне дали фичу «быстрый заказ». Я не спросил, где хранятся настройки промо-кодов и как они кэшируются. Проверил happy path — всё «зелёное». В интеграции промо не применялись при повторном заказе, а я пропустил, потому что не уточнил сценарии. Прод завис на час в прайм-тайм.
Почему это происходит: Страх оценки («сейчас подумают, что я слабый»), синдром самозванца, перфекционизм («сначала всё выучу, потом спрошу правильно»). Мозг защищается от стыда — и мы выбираем молчание.
Как избежать:
- Введите ритуал «3-минутного вопроса»: если за 3 минуты не находите ответ в документации/истории задач — задайте вопрос.
- Держите «банк вопросов QA» на проект: окружение (стенды, кэш, флаги), данные (seed, маскировка), ограничения (SLA, тайм-ауты), риски (критичные пути).
- Используйте шаблон-подсказчик для чатов: «Чтобы корректно протестировать [фича], мне нужно уточнить: 1) … 2) … 3) …».
- На ретро отмечайте «вопрос недели»: какой вопрос помог команде сэкономить время.
А вам бывало страшно задавать вопросы? Как справлялись? Делитесь в комментариях!
Ошибка 2: Тестируем только «счастливый путь»
Суть проблемы: Проверяем то, как «должно работать», и пропускаем краевые сценарии: нестабильную сеть, не валидные данные, отмены, таймауты.
Личная история: Мы выпускали чек-аут. Я проверил оплату при валидных данных — всё отлично. На релизе села сеть у части пользователей, и платёж зависал. Мы не заложили поведение при таймауте.
Почему это происходит (психология): Мозг любит быстрые победы: happy-path даёт ощущение «я молодец». А ещё страшно заглядывать в зону, где «могу не справиться».
Как избежать:
- Для каждого сценария пишите контр-набор: невалидные данные, отмена, сбой сети, возврат, повтор.
- Используйте технику классов эквивалентности и граничных значений — меньше кейсов, больше смысла.
- Сделайте «три обязательных вопроса» перед тестом: что будет, если всё пойдёт не так / если данных слишком много / если данных нет?
Ошибка 3: Недостаточное документирование
Суть проблемы: Баг найден, но описан туманно: «не работает», «иногда падает». Нет чётких шагов, окружения, логов, вложений. В итоге баг «гуляет» между командами, время теряется, доверие тоже.
Личная история: На одном из проектов я завёл тикет «Платёж не проходит». Без точной версии приложения, без build number, без скриншотов и времени события. Разработчик не воспроизвёл, тикет закрыли как «Cannot Reproduce». Через две недели инцидент вернулся к нам от поддержки, уже с потерями конверсии. Мне было стыдно: всё, что нужно было — приложить Charles-логи и фиксировать окружение.
Почему это происходит (психология):
- Спешка и FOMO: «Скорее бы закрыть баги, иначе отстану».
- Страх «быть занудой»: кажется, что требование деталей — придирка.
- Переоценка эмпатии: «И так понятно, что не работает». Нет, не понятно.
Как избежать:
- Шаблон «идеального» баг-репорта: версия ОС/браузера/устройства, версия приложения, окружение (prod/stage), время, шаги, фактический результат, ожидаемый результат, артефакты (скрин/видео/логи).
- One-click запись окружения: заскриптуйте сбор версии, feature-флагов, локали.
- «Пахнет воспроизводимостью?» — оставьте сеанс в видео (например, с консолями/логами).
- Принцип «один тикет — одна проблема». Связанные кейсы — ссылками.
- Ретро по тикетам раз в спринт: выбирайте лучшие/хуже описанные, улучшайте шаблон.
Какой самый нелепый баг-репорт приходилось видеть вам? Расскажите в комментах!
Ошибка 4: Игнорирование нефункционального тестирования
Суть проблемы: Мы проверяем «что» работает, но забываем «как»: скорость, устойчивость, удобство (UX), доступность (a11y), безопасность. Пользователь чувствует именно это «как».
Личная история: Я проверял поиск по каталогу: всё искалось верно. Но под нагрузкой в пиковое время API отвечал по 4–5 секунд, а на старых устройствах UI лагал. Негатив был в отзывах: «медленно», «зависает». Мне казалось, что это «не моя зона», но оказалось — именно мой шанс помочь бизнесу. Я начал измерять TTFB, время до интерактивности, собрал простые smoke-скрипты для JMeter и чек-лист UX-микроюзабилити. На ретро внезапно услышал: «С такой обратной связью мы приняли решение оптимизировать индексы и скроллинг».
Почему это происходит (психология):
- Сужение роли: «Я же мануальный тестировщик, не перформанс-инженер».
- Страх инструментов: кажется, что это «магия» и порог входа высок.
- Иллюзия «пользователю всё равно, лишь бы работало». Пользователю не всё равно.
Как избежать:
- Для каждого важного сценария определяйте простые метрики: «поиск — до 2 с», «экран логина — первый контент до 1 с».
- Возьмите лёгкие инструменты: DevTools Performance/Network, Lighthouse, WebPageTest; для API — Postman/Newman с базовой нагрузкой; для мобильных — профайлеры платформ.
- Включайте UX-чек-лист: читабельность ошибок, доступность для клавиатуры, контраст, размер кликабельной области, фокус-стейт.
- Фиксируйте результаты как баги/улучшения с цифрами («модалка открывается 900–1200 мс»), а не абстракцией («кажется, тормозит»).
- Сотрудничайте: попросите DevOps/BE прикрутить базовые метрики и алерты, чтобы QA видел реальные SLO/SLA.
Ошибка 5: Сравниваем себя с другими — и выгораем
Суть проблемы: Смотрим на сеньоров и чувствуем, что «никогда так не смогу». Включается бег по чужой дорожке, где финала нет.
Личная история: Я подписался на всех «богов» автоматизации и каждый день ощущал себя хуже: «он пишет фреймворк, а я фикшу POM». Руки опускались, задачи стояли.
Почему это происходит (психология): Мозг видит чужой «финиш» и сравнивает с твоим «стартом». Это искажённая выборка.
Как избежать:
- Сравнивайте себя только с собой вчерашним: ведите дневник успехов (3 пункта в конце дня: сделал/чему научился/что помогло).
- Ставьте цели-действия, а не «быть мидлом»: «покрыть 5 API-сценариев и завести отчёты Allure в CI».
- Делайте ретро с собой раз в неделю: что сработало, что мешало, один эксперимент на следующую.
Мотивационная часть: ошибки — это нормально
Ошибки начинающего тестировщика — не «позор», а топливо для роста. Каждый Senior однажды написал ужасный первый тест и отправил неидеальный багрепорт. Разница лишь в том, что они быстро учились на обратной связи, фиксировали выводы и шли дальше. Фокусируйтесь на прогрессе — на наклоне вашей линии, а не на высоте чужой.
Мини-шпаргалка: как стать QA без лишней боли
- Спрашивай и уточняй. Вопрос сегодня экономит дни завтра.
- Покрывай риски, а не экраны. Границы/классы/негативные сценарии — ваши друзья.
- Документируй по шаблону. Одинаковый формат = быстрое воспроизведение.
- Добавляй нефункциональные проверки. Даже короткие — уже вклад.
- Сравнивай себя с собой. Дневник успехов, ретро, маленькие шаги.
Заключение и призыв к действию
Осознать свои типичные ошибки — уже половина пути к тому, чтобы их не повторять. Разрешите себе ошибаться, но учитесь на ошибках — своих и чужих. Ваш путь в QA только начинается!
А какие ошибки совершали вы в начале пути? Делитесь в комментариях — поможем друг другу пройти этот этап быстрее и спокойнее.
Рекомендую так же взглянуть на:
Мифы о входе в IT после 30 лет. Насколько это реально?
Первое резюме джуна QA — как первый идеально приготовленный стейк.
Куда идти из общепита без математики: 7 вакансий-входов в IT
P.S. Какую тему разобрать следующей? Напишите в комментах:
- Как я учился автоматизации без опыта программирования
- Мои первые 30 дней в QA: детальный разбор
- Как перестать бояться командной строки и полюбить терминал
Подписывайтесь на канал «#ПоварВ IT» — вместе сможем больше: от первого багрепорта до собственного фреймворка!