Кто это и зачем нужен
QA Engineer (manual) не даёт дефекту дойти до пользователя — проверяет продукт глазами и руками до релиза. Его миссия — мыслить как пользователь (в т.ч. «вредный») и как скептик: не «работает ли счастливый путь», а «что я могу сломать». Ручной тестировщик ловит то, что не видно из кода: неудобство, странное поведение на краях, нелогичность флоу.
Боль, которую он закрывает: разработчик проверяет, что код делает то, что задумано; QA проверяет, что продукт делает то, что нужно пользователю — и не делает того, что не нужно. Это разные взгляды, и второй ловит баги первого.
Что ломается без него: баги доходят до пользователей (потеря доверия и денег), краевые случаи не проверены, регрессии всплывают на проде, «у меня работает» становится релизным стандартом.
День из жизни
Утро. Разбирает историю и критерии приёмки. Делает тест-дизайн: какие сценарии проверить (happy path + края + ошибки), составляет чек-лист/тест-кейсы. День. Проверяет фичу руками по сценариям, активно ломает: пустые поля, огромные значения, двойные клики, нет сети, неверные данные. Сверяет с критериями приёмки. Находит дефект — воспроизводит и оформляет баг-репорт. Вечер. Прогоняет регресс (не сломалось ли соседнее), уточняет с разработчиком найденное, перепроверяет фиксы, обновляет чек-листы.
Ключевые навыки
Hard: тест-дизайн (классы эквивалентности, граничные значения, таблицы решений), техники тестирования, работа с критериями приёмки, оформление дефектов, регресс, основы SQL/DevTools/логов, чтение требований. Soft: скептицизм и любопытство («а что если…»), мышление пользователя, внимание к деталям, въедливость, чёткая коммуникация дефекта, терпение.
Артефакты, которые пишет
- Тест-план — что, как, в каком объёме (см.
Тест-план). - Тест-кейсы — проверяемые сценарии (см.
Тест-кейс (BDD/Gherkin)). - Баг-репорты — воспроизводимые дефекты (см.
Баг-репорт). - Чек-листы — быстрые наборы проверок.
Все шаблоны — в группе «Артефакты» базы. Проверяет по критериям из
User Story; релиз-готовность —Definition of Done.
Как ИИ/вайб-кодинг усиливает роль
- Тест-кейсы из истории. Промт: «По user story и критериям приёмки <вставить> сгенерируй тест-кейсы: happy path, граничные значения, негативные и ошибочные сценарии. В формате Given/When/Then.»
- Краевые случаи. Промт: «Какие краевые и неочевидные сценарии легко упустить при тестировании фичи <…>? Дай список «а что если…».»
- Баг-репорт по симптому. Промт: «Помоги оформить баг-репорт: симптом <…>. Структурируй: шаги воспроизведения, ожидаемое, фактическое, severity/priority, окружение.»
- Чек-лист регресса. Промт: «Изменили <модуль>. Составь чек-лист регресса: что рядом проверить, чтобы убедиться, что не сломалось.»
- Подсказки «что ещё». Промт: «Я проверил фичу <…> по этим сценариям <…>. Что я мог упустить (безопасность, доступность, производительность, мобильный, локали)?»
Путь развития: Junior → Middle → Senior → Lead
- Junior: тестирует по готовым кейсам, оформляет баги, осваивает техники тест-дизайна.
- Middle: сам делает тест-дизайн, ловит сложные края, ведёт регресс, начинает автоматизировать рутину.
- Senior: проектирует стратегию тестирования области, глубокая экспертиза в продукте, наставляет; часто растёт в QA Automation/SDET.
- Lead → QA Lead: отвечает за процесс и качество (см. роль QA Lead).
Частые ошибки и как избежать
- Только happy path. → Края, негатив, ошибки — там живёт большинство багов.
- Невоспроизводимый баг-репорт. → Чёткие шаги, ожидаемое vs фактическое, окружение, доказательство (лог/скрин/видео).
- Severity = priority. → Это разное (важность дефекта vs срочность исправления); проставляй оба.
- Не проверил регресс. → Изменение могло сломать соседнее; гоняй регресс.
- «Проверил» без критериев. → Сверяйся с критериями приёмки, а не «вроде работает».
Что освоить (мини-программа)
- Концепции: техники тест-дизайна (эквивалентность, границы, попарное), пирамида тестирования, severity/priority, регресс, чек-листы, основы баг-менеджмента.
- Инструменты: TestRail/Allure, Jira, DevTools, Postman (API), SQL-клиент, скриншот/запись экрана.
- Почитать: «Тестирование dot com» Р. Савин (RU-классика); «Lessons Learned in Software Testing»; ISTQB Foundation syllabus.
Зарплатные ориентиры (RU)
- Junior QA (manual): ~60–110 тыс ₽/мес.
- Middle QA: ~110–190 тыс ₽/мес.
- Senior QA: ~190–300 тыс ₽/мес.
Manual обычно ниже automation; зависит от грейда, города и года — проверяй актуальное.
Маппинг на агента Laskoff
Отдельного mapsTo нет: проверку диффа в доме берёт на себя агент quest-verifier (адверсариальная проверка: happy path + края + ошибки + регресс соседнего), а перед закрытием задачи действует обязательный браузерный прогон (Playwright) — ровно «проверить руками глазами», только автоматизированно. Дом не закрывает задачу «на веру».
🤖 Промт-персона
Ты — въедливый QA-инженер, мыслишь как пользователь и как скептик. Помогаешь мне находить дефекты до пользователя. По любой фиче делай тест-дизайн: happy path плюс обязательно края, негатив и ошибки («а что если пусто/огромно/нет сети/двойной клик»). Сверяйся с критериями приёмки, а не «вроде работает». Баг-репорты оформляй воспроизводимо: шаги, ожидаемое vs фактическое, severity и priority раздельно, окружение, доказательство. Напоминай про регресс (не сломалось ли соседнее) и подсказывай неочевидные зоны (безопасность, доступность, мобильный, локали).