Manual Testing

БЛОК 10. Инструменты и практическая работа QA — 27. Инструменты тестировщика

📚 25 вопросовПройти тест →
Лекция

БЛОК 10. Инструменты и практическая работа QA — 27. Инструменты тестировщика

Manual Testing

БЛОК 10. Инструменты и практическая работа QA — 27. Инструменты тестировщика

🧭 Введение: почему без инструментов QA работает вслепую

Когда QA только начинает, кажется, что достаточно открыть экран, нажать кнопки и увидеть баг.
На практике этого мало: нужно доказать проблему, показать контекст и быстро передать команде факты.
Именно поэтому у тестировщика есть рабочий набор инструментов: для проверки, для диагностики, для фиксации дефектов и для управления покрытием.
💡 Совет:
Смотри на инструменты как на систему: один помогает найти проблему, второй подтвердить причину, третий передать работу дальше.
✅ Вывод:
Сильный QA — это не «человек, который кликал», а специалист, который умеет собрать доказательства через правильные инструменты.

⚠️ Проблема -> решение

Проблема: junior QA часто знает названия инструментов, но использует их фрагментарно.
В итоге баги оформляются слабо, проверки не повторяются, а команда тратит время на уточнения.
Решение: собрать базовый стек QA и применять его как единый процесс:
  • проверка в UI и сети (DevTools);
  • подтверждение по логам;
  • API-проверка (Postman);
  • фиксация и трекинг дефекта (Jira/YouTrack);
  • управление тестовым покрытием (TestRail/Qase).
🟢 Если совсем просто:
Инструменты QA — это цепочка «нашёл -> доказал -> оформил -> проконтролировал».
🎯 Как понять, что этап прошел успешно:
Разработчик может воспроизвести проблему без созвона, а команда понимает статус качества по тестовой документации.

🛠️ Чем помогает и как работает

Когда инструменты связаны между собой, QA перестаёт терять контекст между проверкой, багом и релизом.
Как это работает:
  • Шаг 1: QA проверяет поведение в интерфейсе и сети через DevTools.
  • Шаг 2: Если есть ошибка, собирает технические признаки (status code, payload, консоль, timing).
  • Шаг 3: Перепроверяет API-сценарий в Postman, чтобы отделить UI-ошибку от серверной.
  • Шаг 4: Заводит баг в Jira/YouTrack с фактами и шагами воспроизведения.
  • Шаг 5: Привязывает кейс/чек-лист в TestRail или Qase, чтобы покрытие не потерялось.
  • Шаг 6: На ретесте использует те же артефакты и быстро подтверждает фикc.
✅ Вывод:
Инструменты QA работают лучше всего не по отдельности, а как единый рабочий поток.

📚 Ключевые термины (простыми словами)

  • DevTools — встроенный набор инструментов браузера для проверки DOM, CSS, network и console.
  • Console log — технические сообщения клиента (ошибки JavaScript, предупреждения, debug-вывод).
  • Network tab — список HTTP-запросов/ответов: URL, метод, статус, заголовки, body, время.
  • Postman — инструмент для ручной проверки API: отправка запросов, проверка ответов, коллекции.
  • Bug tracker (Jira/YouTrack) — система, где дефект получает статус, приоритет, владельца и историю.
  • Test management (TestRail/Qase) — система для хранения и прогона тест-кейсов, чек-листов и отчетов.
  • BrowserStack/Sauce Labs — облачные устройства/браузеры для compatibility-проверок.
  • Charles/Fiddler — прокси-инструменты для анализа и перехвата HTTP/HTTPS трафика.
  • Git basics для QA — минимальные навыки работы с ветками и коммитами для понимания, что именно попало в сборку.

1. DevTools: первая линия диагностики

Большая часть ежедневной QA-работы начинается с браузера.
Если QA не умеет читать network и console, он часто видит только «что-то не работает», но не понимает, где именно сбой.
🟢 Если совсем просто:
DevTools показывает, что реально происходит между экраном и сервером.
🎯 Как понять, что этап прошел успешно:
Ты можешь назвать конкретный упавший запрос, его статус и место ошибки в интерфейсе.
Назначение:
Быстро обнаружить техническую причину проблемы на уровне браузера.
Простыми словами:
Это «рентген» страницы: видно, какие запросы ушли и какие ошибки вернулись.
Для новичка:
Если кнопка «Сохранить» не работает, сначала открой Network и Console, а не пиши сразу «всё сломано».
Аналогия:
Как приборная панель в машине: без неё ты слышишь, что «что-то не так», но не понимаешь почему.
Пример:
UI: Нажали "Save profile" -> на экране ничего не изменилосьDevTools Network: PATCH /api/profile -> 422 Unprocessable EntityDevTools Console: validation error: phone is required
🔎 Как это происходит на практике:
QA воспроизводит сценарий, фиксирует запрос и ответ, делает скриншот Network + Console и прикладывает это в баг.
Характеристики:
  • встроен в браузер;
  • даёт факты по UI и сети;
  • незаменим для первичной диагностики.
Когда использовать:
Практически всегда при проверке web-функционала.
✅ Вывод:
DevTools — базовый инструмент QA, без которого сложно доказательно разбирать дефекты.

2. Логи: доказательство серверной стороны

Даже если в браузере видно ошибку, команде нужно понимать, что произошло на backend.
Логи помогают подтвердить, какой именно сервис, метод или интеграция привели к сбою.
🟢 Если совсем просто:
Логи отвечают на вопрос «что именно случилось внутри системы».
🎯 Как понять, что этап прошел успешно:
По логам можно точно связать пользовательский шаг и техническую ошибку на сервере.
Назначение:
Подтвердить техническую причину дефекта на стороне сервера или интеграции.
Простыми словами:
Это «журнал событий» системы: кто, что и когда вызвал, и чем это закончилось.
Для новичка:
Если в UI «Ошибка 500», найди лог по времени запроса и request ID — это ускорит фикc в разы.
Аналогия:
Как запись с камер в магазине: можно восстановить, где именно произошёл инцидент.
Пример:
2026-03-09 10:22:11 ERROR payment-servicerequestId=3f8a... timeout to bank-gatewayorderId=84721
🔎 Как это происходит на практике:
QA фиксирует время ошибки и request ID в баге, разработчик находит соответствующую строку в логах и быстро локализует причину.
Характеристики:
  • показывают backend-контекст;
  • полезны для интеграционных дефектов;
  • критичны для 5xx/timeout-ошибок.
Когда использовать:
Когда UI показывает технический сбой или результат не совпадает с фактом в БД/API.
✅ Вывод:
Логи превращают «симптом на экране» в конкретную техническую причину.

3. Postman: проверка API без UI-шумов

Иногда непонятно, баг в интерфейсе или в API.
Postman позволяет проверить endpoint напрямую и понять, где именно проблема.
🟢 Если совсем просто:
Postman нужен, чтобы проверить сервер отдельно от экрана.
🎯 Как понять, что этап прошел успешно:
Ты видишь воспроизводимый запрос и можешь сравнить expected/actual по статусу и body.
Назначение:
Тестировать API-контракт: методы, статусы, структуру ответа и валидации.
Простыми словами:
Это инструмент, где ты вручную отправляешь HTTP-запрос и сразу видишь ответ сервера.
Для новичка:
Если фронт «завис», проверь тот же endpoint в Postman. Так ты поймешь, жив ли backend.
Аналогия:
Как тест звонка напрямую в поддержку, минуя автоответчик.
Пример:
POST /api/login{  "email": "user@example.com",  "password": "wrong"}-> 401 Unauthorized{  "error": "invalid_credentials"}
🔎 Как это происходит на практике:
QA собирает коллекцию smoke-запросов в Postman и перед каждым релизом быстро проверяет критичные endpoints.
Характеристики:
  • поддержка коллекций и окружений;
  • быстрый ручной API smoke;
  • удобно для проверки негативных сценариев.
Когда использовать:
При API-проверках, интеграционных сбоях и triage дефектов между frontend/backend.
✅ Вывод:
Postman помогает QA отделять UI-проблемы от серверных и говорить с backend на одном языке.

4. Jira / YouTrack: управление дефектами и статусами

Найти баг недостаточно — нужно довести его до фикса и ретеста.
Для этого баг должен жить в трекере с понятным статусом, приоритетом и историей.
🟢 Если совсем просто:
Bug tracker нужен, чтобы дефект не потерялся и дошёл до закрытия.
🎯 Как понять, что этап прошел успешно:
По тикету без созвона понятно, что сломано, как воспроизвести, в каком статусе задача и кто ответственный.
Назначение:
Сделать процесс работы с дефектом управляемым и прозрачным.
Простыми словами:
Это «доска задач», где баг проходит путь от находки до проверки фикса.
Для новичка:
Если баг оформлен слабо, его вернут на доработку, и команда потеряет время.
Аналогия:
Как трек-доставка посылки: видно, где она находится сейчас и что будет дальше.
Пример:
Title: [Checkout] Duplicate charge after timeout + retryEnvironment: staging, build 2026.03.09-rc2Steps: ...Expected: one chargeActual: two chargesSeverity: CriticalPriority: High
🔎 Как это происходит на практике:
QA заводит дефект в Jira/YouTrack, команда на triage определяет priority, разработчик фиксит, QA делает retest и закрывает тикет.
Характеристики:
  • статусы и workflow;
  • приоритизация дефектов;
  • история решений и обсуждений.
Когда использовать:
Для всех подтвержденных дефектов и задач качества, требующих командной работы.
✅ Вывод:
Без баг-трекера даже хороший найденный дефект легко теряется в коммуникации.

5. TestRail / Qase: контроль покрытия и прогонов

Когда задач много, в голове невозможно удержать, что уже проверено, а что нет.
Test management инструмент нужен, чтобы фиксировать покрытие и качество релиза системно.
🟢 Если совсем просто:
Это место, где видно, какие тесты есть и с каким результатом они прошли.
🎯 Как понять, что этап прошел успешно:
Команда видит актуальный набор кейсов, результат прогона и риски перед релизом.
Назначение:
Управлять тест-кейсами, чек-листами, тест-ранами и QA-отчетом.
Простыми словами:
Это «рабочий журнал QA-команды», а не просто папка с текстом.
Для новичка:
Если не фиксировать прогоны, потом невозможно доказать, что именно было проверено.
Аналогия:
Как маршрутный лист в доставке: видно, что уже сделано и что ещё в работе.
Пример:
Test Run: Release 2026.03.09-rc2- Login happy path: Passed- Checkout with promo: Failed- Refund flow: Blocked (gateway unstable)
🔎 Как это происходит на практике:
QA запускает targeted regression run, отмечает статусы кейсов и в конце формирует QA summary для релизного решения.
Характеристики:
  • централизованное хранение тестов;
  • видимость покрытия и прогресса;
  • удобная отчетность для релиза.
Когда использовать:
На регрессе, релизных прогонах и при командной работе нескольких QA.
✅ Вывод:
Test management инструмент делает качество измеримым, а не «на ощущениях».

6. Дополнительные инструменты: когда базового стека мало

Есть задачи, где стандартного набора DevTools + Postman недостаточно.
Тогда подключаются специализированные инструменты под конкретный риск.
🟢 Если совсем просто:
Дополнительные инструменты нужны для узких, но критичных проверок.
🎯 Как понять, что этап прошел успешно:
Для каждого дополнительного риска выбран подходящий инструмент, и его вывод понятен команде.
Назначение:
Покрыть compatibility, сетевые аномалии и рабочую синхронизацию с разработкой.
Простыми словами:
Это «усилители» QA, когда базовой диагностики уже недостаточно.
Для новичка:
Не нужно использовать всё сразу. Подключай инструмент только под конкретный риск.
Аналогия:
Как набор специальных насадок для ремонта: обычная отвертка помогает не всегда.
Пример:
BrowserStack: проверка оплаты на Safari iOSCharles/Fiddler: перехват и анализ редкого timeout-ответаGit log: проверка, какие фиксы реально вошли в build
🔎 Как это происходит на практике:
Перед релизом QA формирует риск-лист: по compatibility запускает BrowserStack, по нестабильной интеграции — Charles/Fiddler, по спорным фиксам сверяется с Git-историей.
Характеристики:
  • точечное применение;
  • полезны на сложных дефектах;
  • экономят время на спорных кейсах.
Когда использовать:
При высокорисковых изменениях, нестабильных интеграциях и multi-device проверках.
✅ Вывод:
Дополнительные инструменты нужны не всегда, но в сложных релизах часто решают исход проверки.

🆚 Сравнение: какой инструмент под какую задачу

СитуацияИнструментЧто получаем
Кнопка не работает в UIDevTools (Network + Console)Статус запроса, client error, детали валидации
Ошибка 500/timeoutЛоги + DevToolsТехническая причина и связка UI <-> backend
Нужно проверить API без фронтаPostmanЧистая проверка контракта endpoint
Нужно передать дефект в работуJira / YouTrackУправляемый workflow и ответственность
Нужно показать покрытие релизаTestRail / QaseПрозрачный статус прогонов и риски
Нужно проверить устройства/браузерыBrowserStack / Sauce LabsCompatibility-факты
✅ Вывод:
Один инструмент редко закрывает задачу полностью; чаще нужен связанный набор.

✅ Must-know факты

  • Один и тот же дефект часто проверяется разными инструментами: UI (DevTools), API (Postman), процесс (Jira), покрытие (TestRail/Qase).
  • Хороший баг-репорт почти всегда содержит артефакты из инструментов: статус запроса, лог-фрагмент, шаги, окружение.
  • Инструмент выбирается под риск, а не «потому что так привыкли».
  • Postman не заменяет UI-тестирование, а дополняет его.
  • Jira/YouTrack без качественного описания не спасает: слабый тикет всё равно тормозит фикc.
  • Test management система полезна только если кейсы и статусы актуальны.

❌ Частые мифы

❌ Миф: QA-инструменты нужны только senior-специалистам.
✅ Как правильно: Базовый стек (DevTools, Postman, bug tracker) нужен уже junior QA с первых задач.
📎 Почему это важно: Без него растет доля «неподтвержденных» и невоспроизводимых дефектов.
❌ Миф: Если UI работает, API проверять не нужно.
✅ Как правильно: UI может быть зеленым при сломанном контракте API и наоборот.
📎 Почему это важно: Проверка только через UI оставляет слепые зоны интеграции.
❌ Миф: Достаточно написать в баге «не работает».
✅ Как правильно: Нужны шаги, окружение, expected/actual и доказательства из инструментов.
📎 Почему это важно: Автономный баг-репорт резко сокращает цикл фикса.
❌ Миф: TestRail/Qase — это «лишняя бюрократия».
✅ Как правильно: Это рабочий инструмент видимости покрытия и контроля регресса.
📎 Почему это важно: Без фиксированного покрытия команда не понимает реальный риск релиза.

💬 Часто спрашивают на собеседованиях

❓ Вопрос: Чем DevTools отличается от Postman в работе QA? ✅ Ответ: DevTools показывает, что произошло в браузере и сети при пользовательском действии, а Postman проверяет API напрямую без UI-слоя.
❓ Вопрос: Какие минимум данные нужны в баг-репорте? ✅ Ответ: Environment, build/version, шаги воспроизведения, expected/actual, severity/priority и evidence (скриншоты, логи, network-фрагменты).
❓ Вопрос: Зачем QA нужен bug tracker, если можно написать в чат? ✅ Ответ: Трекер дает статус, владельца, приоритет, историю и контроль выполнения; чат это не обеспечивает.
❓ Вопрос: Когда подключать BrowserStack или Sauce Labs? ✅ Ответ: Когда есть риск несовместимости между браузерами/устройствами или релиз затрагивает критичный mobile/web поток.
❓ Вопрос: Что делать, если баг не воспроизводится у разработчика? ✅ Ответ: Перепроверить environment, build, тестовые данные, preconditions и добавить более точные артефакты из DevTools/логов/Postman.

🚨 Типичные ошибки

  • использовать инструмент «по привычке», а не по риску задачи;
  • заводить баг без технических артефактов;
  • смешивать в одном прогоне несколько сред и терять воспроизводимость;
  • путать retest бага и новый exploratory прогон;
  • не фиксировать связь «кейсы -> баги -> релизный вывод».

🌟 Best Practices

  • держи базовый личный чек-лист: DevTools -> logs -> Postman -> bug tracker -> test run update;
  • при каждом дефекте фиксируй однотипный набор контекста (env, build, data set, evidence);
  • поддерживай в Postman небольшую smoke-коллекцию критичных API;
  • в Jira/YouTrack используй понятные title по формуле: [Где] + Что сломалось + При каком условии;
  • в TestRail/Qase отмечай не только pass/fail, но и blocked с причиной;
  • не перегружай процесс: бери ровно те инструменты, которые закрывают текущий риск.

🧾 Заключение

Инструменты тестировщика — это не «дополнение к тестированию», а рабочий каркас QA-процесса.
Когда QA умеет правильно применять DevTools, логи, Postman, bug tracker и test management, команда быстрее находит причины проблем и увереннее выпускает релиз.
✅ Вывод:
Для junior QA ключевая цель — не знать все инструменты в мире, а стабильно и доказательно использовать базовый набор в каждом рабочем цикле.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 10. Инструменты и практическая работа QA — 27. Инструменты тестировщика»

Пройти тест →