Каждый был джуном. Кто-то — 10 лет назад, кто-то — вчера. И почти каждый проходил через одни и те же грабли. Эта статья — для тех, кто только начинает карьеру в QA. Разберём, какие ошибки совершают джуны чаще всего, почему они возникают и как их избежать. Всё — с примерами из практики и конкретными советами.
❌ 1. Поверхностное понимание продукта
Ситуация:
Тестировщик получил таску — протестировать форму заказа. Запустил автотесты, ручками проверил пару кейсов и закрыл задачу. Через два дня баг от клиента: заказ не создаётся, если пользователь — юрлицо.
Почему случается:
Джун не разобрался, как работает бизнес-логика, кто конечный пользователь, и что форма должна вести себя по-разному для разных типов клиентов.
Как избежать:
- Перед тем как приступить к тестированию, обязательно проясни у продакт-менеджеров и разработчиков следующие моменты:
-Кто конечный пользователь и его сценарии?
-Есть ли различия в логике для разных типов клиентов?
-Какие бизнес-ограничения или особенности стоит учесть? Так ты избежишь слепого тестирования и не пропустишь важные кейсы. - Если есть документация — читай, вникай, задавай вопросы. Если её нет — не повод страдать. Помоги её создать: заведи черновик, опиши ключевые сценарии, зафиксируй договорённости. Так ты и сам разберёшься, и другим упростишь жизнь.
- Составляй пользовательские сценарии (user flows), где детально описываешь, как пользователь будет взаимодействовать с системой: от первого клика до последнего действия. Это поможет увидеть скрытые ветки логики и не пропустить важные кейсы.
❌ 2. Неполное покрытие тест-кейсами
Ситуация:
Проверены только "счастливые пути" — корректные данные, верный порядок действий. Ошибки валидации, граничные значения, негативные кейсы — пропущены.
Почему случается:
Нет опыта построения полноценных тест-кейсов, нет шаблона, не хватает времени или уверенности.
Как избежать:
- Применяй техники тест-дизайна: эквивалентное разбиение, анализ граничных значений, таблицы принятия решений, попарное тестирование и другие. Эти подходы помогут структурировать тест-кейсы и находить баги не интуитивно, а методично — как настоящий кибер-Шерлок..
- Создавай чек-листы, особенно если нет времени на тест-кейсы.
- Не бойся предлагать улучшения — «А если пользователь сделает вот так?..»
❌ 3. Плохие баг-репорты
Ситуация:
Заводится баг типа: «Форма не работает». Всё. Без шагов, без скринов, без ожиданий.
Почему случается:
Джун не знает, как составлять баг-репорт так, чтобы разработчик понял и воспроизвёл ошибку.
Как избежать:
Всегда указывай:
- шаги воспроизведения
- фактический результат
- ожидаемый результат
- окружение (браузер, устройство и т.п.)
- скриншоты / видео
- Изучай баг-репорты коллег, перенимай удачные форматы.
❌ 4. Игнорирование нефункционального тестирования
Ситуация:
Форма работает идеально, но при медленном интернете — всё виснет. А с отключённым JS — вообще ничего не грузится.
Почему случается:
Фокус только на функциональность, без учёта реального поведения пользователя в разных условиях.
Как избежать:
- Не ограничивайся только стабильными условиями. Протестируй продукт в условиях слабой сети (например, 3G или Edge), при отключённом JavaScript и в старых или экзотических браузерах. Именно там чаще всего всплывают баги, которые ломают опыт реальных пользователей. Помни: не все сидят на MacBook с гигабитным интернетом и последней версией Chrome.
- Не забудь про производительность и доступность (accessibility) — эти аспекты часто становятся причиной негатива от пользователей. Тормозящий интерфейс и недоступный функционал для людей с ограниченными возможностями — это не просто недочёты, а реальные баги, которые могут дорого обойтись продукту. Проверяй, насколько быстро грузится страница, удобно ли ей пользоваться с клавиатуры, читаются ли тексты скринридером. Используй инструменты вроде Lighthouse и axe DevTools, чтобы автоматизировать такие проверки и находить слабые места.
- Протестируй производительность и доступность с помощью инструментов: Lighthouse — для быстрой оценки скорости загрузки и проблем с доступностью, DevTools — для анализа ресурсов и сетевых запросов, WebPageTest — для более глубокой оценки реального поведения страницы под разными условиями сети. Эти инструменты помогут выявить узкие места, которые могут незаметно убить пользовательский опыт.
❌ 5. Отсутствие коммуникации
Ситуация:
Тестировщик находит баг, но не сообщает команде — думает, «это мелочь», «потом заведу», «не уверен, что это баг».
Почему случается: Неуверенность, страх выглядеть глупо, непонимание процессов.
Как избежать:
- Задавай вопросы. Лучше уточнить, чем молча промолчать.
- Общайся с разработчиками и продактами на всех этапах.
- Создавай культуру открытого QA: делиться — норма.
❌ 6. Недооценка документации
Ситуация:
После релиза никто не может воспроизвести, как именно тестировался определённый кейс. Потому что он был «в голове».
Почему случается:
Джун не видит ценности в документации или не знает, как её правильно вести.
Как избежать:
- Начни с простых чек-листов или тест-кейсов — даже таблички в Notion или Excel подойдут. Главное — фиксируй, что именно ты тестировал, в каком порядке и с какими результатами. Это убережёт от «потерянных» кейсов и спасёт, когда спустя месяц кто-то спросит: «А ты это проверял?».
- Документируй всё, до последнего пикселя: пользовательские сценарии, входные данные, найденные баги, странные гипотезы, даже если они звучат как теория заговора. Потом скажешь спасибо себе из будущего, когда надо будет вспомнить, что ты вообще тестировал три недели назад.
- Это пригодится не только другим — но и тебе самому спустя пару недель.
❌ 7. Отсутствие интереса к автоматизации
Ситуация:
Джун делает всё руками, не пробует Postman, не интересуется CI, не смотрит на автотесты.
Почему случается:
Страх кода, нет опыта, кажется «не моё».
Как избежать:
- Разберись хотя бы с базовыми инструментами: Postman — для API, SQL — чтобы не пугаться баз данных, Charles — чтобы понимать, что за пакеты летают туда-сюда, и Git — чтобы случайно не удалить прод. Это как минимум, без этого в 2025 даже ручному тестировщику тяжко.
- Попробуй запустить простые автотесты — например, UI с помощью Selenium или Playwright, либо API-тесты через Postman/Newman или REST Assured. Даже небольшое погружение даст понимание, как работает автоматизация, какие ошибки ловятся проще в коде, и почему автотесты — не магия, а инструмент. Пусть пока только для экспериментов — но это отличная база на будущее.
- Даже ручник, который понимает автоматизацию — на вес золота.
📌 Заключение
Ошибки джуна — это нормально. Главное — учиться, замечать, анализировать и делать выводы. Тестирование — это не просто кликать кнопки. Это видеть шире, глубже и задаваться вопросом: «А что если?..»
Прокачивай насмотренность, не бойся ошибаться и становись QA, с которым хочется работать.