QA Инженер

Парсите JSON JSON Formatter (плагин для браузера), jq в консоли --- 6. Главные ошибки новичков · Смотрят только UI и пишут баг «не работает», а нужно показать конкретный ответ API или запрос. · Бухтят в БД без транзакции (загрязняют данные, мешают другим тестам). · Не берут логи в момент воспроизведения (а через час они уже перезаписаны). · Путают 400 (ошибка клиента) и 500 (ошибка сервера) — разные команды на починку.

Это золотой стандарт QA выше среднего. Когда вы перестаёте верить UI и лезете «под капот» — вы становитесь настоящим инженером. UI может врать, а логи, БД и API показывают правду. Давайте разберём каждый слой детально. --- 1. Анализ API (Backend без интерфейса) Что проверяете: · Статус-коды (200 OK, 400 Bad Request, 500 Internal Error, 401 Unauthorized). · Тело ответа (JSON/XML) — структура, типы данных, значения. · Заголовки (Content-Type, Authorization, CORS). · Время ответа (если > 2 сек — уже повод задуматься). Главные инструменты: · Postman / Insomnia — ручные запросы + коллекции а…

· Пишут заголовок «Не работает» — бесполезно для поиска. · Не обновляют статус после проверки фикса (забивают). --- 8. Шпаргалка-памятка Запомните аббревиатуру STAR для бага: · S — Steps (шаги) · T — Test data (данные) · A — Actual (что было) · R — Result expected (что должно быть)

Баг-трекер — это не просто «тулза для записи косяков», а центр управления качеством. Через него коммуницируют все: менеджер ставит приоритеты, разработчик видит, что чинить, а QA отслеживает историю продукта. Вот полный разбор для QA: --- 1. Популярные системы (ваш выбор) · Jira — стандарт индустрии (гибкая, кастомизируемая, интеграции с Confluence, TestRail, Git). · YouTrack — легковесный, удобный для агile-команд, от JetBrains. · Redmine — бесплатный, но устаревший интерфейс. · Trello / Asana — для маленьких команд (вместо досок). · Bugzilla / Mantis — классические, бесплатные, но редко…

Автоматизация тестирования — это не «замена ручек роботами», а инвестиция в скорость и повторяемость. Рука проверит 10 сценариев за час, а авто — 1000 за 5 минут, но только если они стабильны и не меняются каждый день. Вот полный разбор для QA: --- 1. Что именно автоматизируем (пирамида) · Модульные тесты (Unit) — пишут разработчики (JUnit, PyTest). Проверяют функции изолированно. Самый дешёвый и быстрый слой. · API-тесты — ваш главный фокус (Postman/Newman, REST Assured, SoapUI). Проверяют логику без UI. Стабильны и быстры. · UI-тесты — через браузер (Selenium, Playwright, Cypress). Самые…

Ручное тестирование (Manual Testing) — это не «нажимать на кнопки наугад», а осознанная исследовательская деятельность. Автоматизация проверяет то, что вы уже знаете, а руками вы находите неизвестное. Вот полная картина: --- 1. Виды ручного тестирования (по целям) · Функциональное — работает ли так, как написано в ТЗ? (клик → результат). · Регрессионное — не сломали ли старые фичи новым кодом? (выборочная проверка ядра). · Смоук (Smoke) — «дымит ли» билд? (критический путь за 10–15 минут, чтобы дать зелёный свет команде). · Санитарное (Sanity) — узкая проверка конкретной фиксации бага. · И…

Тест-дизайн — это не «придумывание рандомных тестов», а научный подход к выбору минимального количества тестов, которые найдут максимум багов. Это математика и логика, а не творчество. Вот полная картина для QA: --- 1. Зачем это нужно? — Невозможно проверить все значения (например, поле «возраст» от 0 до 150 — это 151 вариант, а если 3 поля — уже миллионы). — Тест-дизайн сокращает количество тестов в 10–100 раз, сохраняя покрытие критичных сценариев. --- 2. Базовые техники (обязательный минимум) Классы эквивалентности (Equivalence Partitioning) — Делим входные данные на группы (классы),…

Анализ требований (Requirements Analysis) — это фундамент QA. Если требования плохие, то даже идеальный код не спасёт: вы проверите «не то» и «не так». Вот как это выглядит в работе QA-инженера по шагам: 1. Роли и артефакты Вы работаете с: — Бизнес-требованиями (что хотим получить). — Функциональными требованиями (как система должна работать). — Макетами/дизайном (как это выглядит). — User Stories и Acceptance Criteria (критерии готовности). 2. Что именно анализируем? QA смотрит на текст как «адвокат дьявола»: — Полнота — описаны ли все сценарии? (Что при пустом поле? Что при обрыве сети?)…

ТЕОРИЯ Инженер по обеспечению качества (QA) — это «адвокат пользователя», который проверяет, что продукт работает корректно, безопасно и удобно. Он не просто «находит баги», а предотвращает дефекты на всех этапах разработки. Ключевые области (чем занимается): · Анализ требований — поиск противоречий еще до написания кода. · Тест-дизайн — придумывание сценариев (позитивных, негативных, граничных). · Ручное тестирование (функциональное, регрессионное, исследовательское). · Автоматизация (если это AQA) — написание кода на Python/Java/JS для автотестов. · Работа с баг-трекерами (Jira, YouTrack)…

Пост без текста