Блог https://yakorqa.ru ru Tue, 10 Mar 2026 15:14:27 +0300 Баг-репорты и тест-кейсы: примеры и шаблоны для QA https://yakorqa.ru/tpost/bug-report-i-test-case https://yakorqa.ru/tpost/bug-report-i-test-case?amp=true Tue, 28 Oct 2025 13:54:00 +0300 Учимся писать баг-репорты и тест-кейсы: структура, приоритеты, шаблоны. Готовые примеры для портфолио начинающего тестировщика.

Баг-репорты и тест-кейсы: примеры и шаблоны для QA

Баг-репорты и тест-кейсы для портфолио: примеры и шаблоны

Хочешь стать тестировщиком? Тогда научись писать баг-репорты и тест-кейсы. Без них на работу не возьмут.
Я покажу, как оформить документы для портфолио. Дам шаблоны. Разберу примеры. После статьи сможешь сделать свои первые документы и показать их на собесе.

Что такое баг-репорт

Баг-репорт — документ с описанием ошибки. Нужен, чтобы разработчик понял проблему и исправил.
Плохой пример:
❌ "Кнопка не работает"
Хороший пример:
✅ "Кнопка 'Купить' не реагирует на клик. Товар не добавляется в корзину. Проверял в Chrome, Windows 10."
Чувствуешь разницу? Во втором случае понятно где баг, как повторить, на каком устройстве.

Из чего состоит баг-репорт

ID и заголовок

ID — номер бага. Генерируется системой автоматически.
Заголовок — краткое описание. Формула: "Где + Что случилось".
Примеры:
✅ "Корзина: товар исчезает после перезагрузки"
✅ "Регистрация: нет ошибки при пустом email"

Шаги воспроизведения

Самая важная часть. Пиши по шагам:
  1. Открыть сайт example.com
  2. Нажать "Войти"
  3. Ввести email: test@mail.ru
  4. Ввести пароль: 123456
  5. Нажать "Отправить"
Каждый шаг с новой строки. Нумеруй.

Ожидаемый и фактический результат

Ожидаемый — как должно работать.
Фактический — что происходит.
Пример:
  • Ожидал: попаду в личный кабинет
  • Получил: ошибка 500

Окружение

Где баг появился:
  • ОС: Windows 10 / macOS 13
  • Браузер: Chrome 118 / Safari 16
  • Версия приложения: v2.3.1
Добавь скриншоты. Желательно видео. И логи консоли.

Priority и Severity — разные вещи

Многие путают. Объясняю:
Severity — насколько серьёзен баг для системы.
Priority — насколько срочно исправлять.
Priority:
  • High — исправить сейчас
  • Medium — можно отложить
  • Low — когда будет время
Пример: опечатка на главной странице = Severity: Trivial, но Priority: High. Потому что главную видят все.

Жизненный цикл бага

Баг проходит статусы:
New → создан, не назначен
Open → назначен разработчику
In Progress → разработчик чинит
Resolved → исправлено, отдано на проверку
Closed → проверил, всё ок
Reopened → не исправлено, вернул обратно

Пример готового баг-репорта

ID: BUG-245
Заголовок: Корзина: кнопка "Оформить" не работает при 10+ товарах
Severity: Major
Priority: High
Status: New
Окружение: Windows 10, Chrome 118, 1920x1080
Шаги:
1. Открыть https://example.com
2. Добавить 10 товаров в корзину
3. Перейти в корзину
4. Нажать "Оформить заказ"
Ожидал:
Открылась страница оформления
Получил:
Кнопка серая, не кликается.
Повторяется 10 из 10 раз.
Вложения:
- screenshot.png
- video.mp4
- console.log

Что такое тест-кейс

Тест-кейс — инструкция для проверки функции. В отличие от баг-репорта (описывает ошибку), тест-кейс описывает как проверять.
Когда нужен:
✅ Регрессия — проверяешь каждый раз одинаково
✅ Передача знаний — новичок может взять и выполнить
✅ Автоматизация — тест-кейсы переводят в автотесты
Когда не нужен:
❌ Исследовательское тестирование
❌ Разовые проверки

Из чего состоит тест-кейс

1. ID — номер (TC-001, TC-002)
2. Название — что проверяем
3. Предусловия — что сделать до теста
4. Шаги — пошаговая инструкция
5. Входные данные — какие данные вводить
6. Ожидаемый результат — что должно случиться
7. Фактический результат — заполнишь после проверки
8. Статус — Passed/Failed

Чек-лист vs тест-кейс

Правило: чек-лист — для скорости, тест-кейс — для точности.

Виды тест-кейсов

Позитивные — проверяют правильную работу:
✅ Ввёл корректный email → зарегался
Негативные — проверяют обработку ошибок:
✅ Ввёл пустой email → показало ошибку

Примеры готовых тест-кейсов

Пример 1: Авторизация

ID: TC-001
Название: Проверка входа с правильными данными
Приоритет: High
Предусловия: Пользователь зарегистрирован
Шаги:
1. Открыть https://example.com/login
2. Ввести email: test@mail.ru
3. Ввести пароль: Qwerty123
4. Нажать "Войти"
Ожидаю:
- Перешёл на /dashboard
- Вижу "Добро пожаловать, Test User!"
- Аватар в правом верхнем углу
Результат: [заполню после проверки]
Статус: [Passed/Failed]

Пример 2: Корзина

ID: TC-015
Название: Добавление товара в корзину
Приоритет: High
Шаги:
1. Открыть главную
2. Найти "Смартфон XYZ"
3. Нажать "В корзину"
4. Нажать иконку корзины
Ожидаю:
- "Смартфон XYZ" в корзине
- Количество: 1
- Цена совпадает с карточкой

Ошибки в баг-репортах

1. Непонятные шаги
❌ "Нажал кнопку, не работает"
✅ "Нажал 'Добавить' → ошибка 500"
2. Нет скриншотов
Всегда прикладывай картинку.
3. Эмоции
❌ "Ужасная кнопка!"
✅ "Кнопка не работает при заполненной форме"
4. Размытый заголовок
❌ "Проблема с формой"
✅ "Форма регистрации: не проверяет телефон"
5. Забыли окружение
Разработчик не поймёт где искать баг.

Инструменты

Для работы:
  • Jira — самый популярный
  • TestRail — для тестов
  • Qase — удобный
  • TestIT — российский
Для портфолио:
Хватит Excel или Google Sheets. На работе освоишь Jira.

Как оформить портфолио

Нужно 5-10 примеров:
Баг-репорты (3-5 штук):
  • Разной серьёзности: Blocker, Major, Minor
  • С разных проверок: UI, API
  • Со скриншотами
Тест-кейсы (5-10 штук):
  • Позитивные и негативные
  • На разные функции: логин, корзина, поиск
  • В едином стиле
Где взять проекты:
✅ Тестируй сайты (магазины, банки)
✅ Краудтестинг (Testbirds, uTest)
✅ Учебные проекты

Вопросы

Сколько нужно тест-кейсов?
5-10 хороших. Лучше меньше, но качественных.
В какой программе делать?
Google Sheets хватит. Потом изучишь Jira.
Можно тестировать чужие сайты?
Да. Только не публикуй баги открыто, только в портфолио.
Как описать баг без причины?
Опиши симптомы: что делал, что случилось. Причину найдёт разработчик.
Severity vs Priority?
Severity — насколько серьёзно. Priority — насколько срочно.
Нужны ли тест-кейсы для всего?
Нет. Для разовых проверок хватит чек-листа.

Что делать дальше

Теперь знаешь как писать баг-репорты и тест-кейсы. Это база профессии.
План действий:
  1. Подготовь шаблоны
  2. Протестируй 3-5 сайтов
  3. Оформи найденные баги
  4. Составь 10 тест-кейсов
  5. Собери в Google Drive
Хочешь учиться на реальных проектах?
На моём курсе ты:
✓ Напишешь 50+ тест-кейсов с ментором
✓ Оформишь 20+ баг-репортов
✓ Получишь портфолио для резюме
✓ Подготовишься к собесам
Еще больше полезных материалов в моем телеграм-канале https://t.me/yanaoqa
]]> Виды тестирования: полный список с примерами https://yakorqa.ru/tpost/vidy-testirovaniya-polnyy-spisok https://yakorqa.ru/tpost/vidy-testirovaniya-polnyy-spisok?amp=true Sat, 08 Nov 2025 15:38:00 +0300 Разбираем все виды тестирования: функциональное и нефункциональное, ручное и автоматизированное. Примеры и когда применять каждый тип.

Виды тестирования: полный список с примерами

Виды тестирования: полный список с примерами

Начал учить тестирование? Запутался в терминах: smoke, sanity, regression, функциональное, нефункциональное?
Я дам полный список видов тестирования. С примерами. Просто. Без заумностей.
После статьи поймёшь какой вид когда применять. И не спутаешь на собесе.

Краткий ответ: основные виды тестирования

Вот 5 главных, которые нужно знать:
  1. Функциональное — проверяет функции приложения
  2. Нефункциональное — производительность, безопасность, юзабилити
  3. Модульное — тестирует отдельные компоненты кода
  4. Интеграционное — проверяет взаимодействие модулей
  5. Системное — тестирует всю систему целиком
А теперь подробно про каждый.

По каким критериям делят виды

Тестирование классифицируют по разным параметрам:
По целям: что проверяем (функции или качества)
По уровню: на каком этапе разработки
По доступу к коду: видим код или нет
По времени: когда проводим
По сценарию: позитивный или негативный
По автоматизации: руками или скриптами
Дальше разберём каждый.

Функциональное и нефункциональное

Функциональное тестирование

Что проверяет: работают ли функции приложения.
Примеры:
✅ Кнопка "Войти" открывает личный кабинет?
✅ Добавление товара в корзину работает?
✅ Поиск находит нужные товары?
Проверяешь ЧТО делает система.

Нефункциональное тестирование

Что проверяет: качества системы — скорость, безопасность, удобство.
Виды нефункционального:
Performance (производительность):
Сайт открывается за 3 секунды или зависает?
Security (безопасность):
Можно ли взломать или утечь данные?
Usability (юзабилити):
Удобно ли пользоваться? Понятен ли интерфейс?
Compatibility (совместимость):
Работает в Chrome? А в Safari?
Проверяешь КАК работает система.

По уровню детализации

Модульное (Unit Testing)

Что: проверка отдельных функций кода.
Кто делает: разработчики.
Пример:
Функция calculatePrice(item, discount) считает цену правильно?

Интеграционное (Integration Testing)

Что: проверка как модули работают вместе.
Пример:
Корзина правильно передаёт данные на страницу оплаты?

Системное (System Testing)

Что: проверка всей системы целиком.
Пример:
Весь процесс покупки: от выбора товара до оплаты и подтверждения.

Приёмочное (Acceptance Testing)

Что: проверка соответствия требованиям заказчика.
Пример:
Заказчик проверяет: "Да, это то что я хотел".

По доступу к коду

Чёрный ящик (Black Box):
Не видишь код. Проверяешь как пользователь.
Пример: тестирую сайт, не зная как он устроен изнутри.
Белый ящик (White Box):
Видишь код. Проверяешь логику.
Пример: разработчик смотрит покрытие кода тестами.
Серый ящик (Grey Box):
Частичный доступ к коду.
Пример: знаешь структуру базы данных, проверяешь запросы.

По времени проведения

Smoke Testing (дымовое)

Что: проверка базовых функций после сборки.
Когда: получил новую версию — проверь что не сломалось критичное.
Пример:
Приложение запускается? Логин работает? Основные кнопки кликаются?
Если smoke не прошёл — не тестируй дальше. Верни разработчикам.

Sanity Testing (проверка здравомыслия)

Что: быстрая проверка конкретного исправления.
Когда: разработчик исправил баг — проверь что починил.
Пример:
Баг: кнопка "Купить" не работала.
Sanity: проверяешь только эту кнопку.

Regression Testing (регрессионное)

Что: проверка что новые изменения не сломали старое.
Когда: перед релизом, после больших изменений.
Пример:
Добавили новую функцию оплаты. Проверяешь что старая оплата картой всё ещё работает.

Позитивное и негативное

Позитивное:
Проверяешь правильные сценарии.
Пример: ввёл корректный email → зарегистрировался.
Негативное:
Проверяешь неправильные сценарии.
Примеры:
❌ Пустой email → показало ошибку?
❌ Неверный пароль → не пустило?
❌ SQL-инъекция → защита сработала?
Новички часто забывают про негативное. А это важно.

Ручное и автоматизированное

Ручное:
Проверяешь руками. Кликаешь, вводишь, смотришь.
Плюсы: гибкость, находишь неочевидные баги.
Минусы: долго, скучно повторять.
Автоматизированное:
Пишешь скрипт — он проверяет за тебя.
Плюсы: быстро, можно повторять.
Минусы: дорого в разработке, не найдёт неочевидное.
Правило: регресс автоматизируй, исследовательское — руками.
Подробнее про переход в автоматизацию "Программа обучения по автоматизации".

По этапу разработки

Альфа-тестирование:
Проверка внутри команды разработки. Ранние версии.
Бета-тестирование:
Даём продукт реальным пользователям. Собираем фидбек.
Pre-production:
Финальная проверка перед выкаткой на боевой сервер.

Специализированные виды

Security Testing (безопасность):
Проверка уязвимостей, SQL-инъекций, XSS-атак.
Инструмент: OWASP ZAP.
Performance Testing (производительность):
Нагрузочное, стресс-тестирование.
Инструмент: JMeter, Gatling.
Usability Testing (юзабилити):
Удобство интерфейса. Понятность для пользователя.
Compatibility Testing (совместимость):
Работа на разных браузерах, ОС, устройствах.
Localization Testing (локализация):
Проверка переводов, форматов дат, валют.
API Testing:
Проверка взаимодействия между сервисами.
Инструмент: Postman, REST Assured.

Таблица: когда применять

Инструменты для разных видов

Ручное тестирование:
Jira, TestRail, Qase — управление тестами и багами.
Автоматизация UI:
Selenium, Playwright, Cypress — для веб.
Appium — для мобильных.
API тестирование:
Postman, REST Assured, SoapUI.
Performance:
JMeter, Gatling, Locust — нагрузка.
Security:
OWASP ZAP, Burp Suite — поиск уязвимостей.
Мобильное:
BrowserStack, Sauce Labs — кросс-браузерное и мобильное.
Хочешь научиться работать с этими инструментами? В статье про баг-репорты и тест-кейсы я показываю как документировать результаты проверок.

Ошибки начинающих

1. Путают smoke и sanity
Smoke — всё базовое. Sanity — конкретное исправление.
2. Забывают про негативное тестирование
Проверяют только правильные сценарии. А багов больше в неправильных.
3. Не делают regression
"Исправили одно — сломали другое". Регресс обязателен перед релизом.
4. Пытаются автоматизировать всё
Не всё нужно. Исследовательское — только руками.
5. Не понимают зачем разные уровни
Модульное → интеграционное → системное. Последовательность важна.

Чек-лист: с чего начинать новичку

Если ты Junior QA, начни с этих видов:
☐ Smoke — научись быстро проверять базовые функции
☐ Функциональное — основа работы тестировщика
☐ Позитивное и негативное — научись думать об ошибках
☐ Regression — как проверять что ничего не сломалось
☐ API тестирование (Postman) — базовый навык для Junior
☐ Кросс-браузерное — проверка в Chrome, Firefox, Safari
Освоил эти — переходи к автоматизации.
💡 Лайфхак: Заведи таблицу в Excel. По каждому виду запиши 2-3 примера проверок. Это будет твоя шпаргалка к собесу.

Как выбрать вид для задачи

Шаг 1: Что нужно проверить?
  • Функцию → функциональное
  • Скорость → performance
  • Безопасность → security
Шаг 2: На каком этапе?
  • Новая фича → smoke → функциональное
  • Исправление → sanity
  • Перед релизом → regression
Шаг 3: Есть доступ к коду?
  • Да → белый ящик
  • Нет → чёрный ящик
Шаг 4: Повторяющаяся проверка?
  • Да → автоматизируй
  • Нет → руками

Вопросы и ответы

В чём разница smoke и sanity?
Smoke — базовые функции всего приложения. Sanity — конкретное исправление.
Когда делать regression?
Перед каждым релизом. После больших изменений. Когда есть риск что-то сломать.
Что важнее: функциональное или нефункциональное?
Оба важны. Сначала функциональное (работает ли). Потом нефункциональное (хорошо ли работает).
Нужно ли знать все виды тестирования Junior QA?
Не обязательно. Знай основы: функциональное, smoke, regression, API. Остальное освоишь на работе.
Можно ли автоматизировать все виды?
Нет. Исследовательское, юзабилити, некоторые security-проверки — только руками.
Что спрашивают на собесе про виды тестирования?
"В чём разница smoke и regression?", "Что такое белый/чёрный ящик?", "Приведи пример функционального тестирования".
Подробнее про подготовку к собеседованиям есть в моем Boosty

Что дальше

Теперь знаешь основные виды тестирования. Не путаешь термины.
План действий:
  1. Сохрани таблицу — используй как шпаргалку
  2. Попрактикуйся на реальных проектах
  3. Выучи различия между smoke, sanity, regression
  4. Подготовься к вопросам на собесе

Как я могу помочь

Обучение и поддержка в Boosty

У меня есть 3 уровня подписок для разных задач:
🔹 Уровень 1. Базовый минимум.
Пошаговый план обучения, общение и поддержка

• Повышение хардов (hard skills)

• Видео с разбором тем по тестированию

• Задачи (дз) для закрепления умений и навыков

• Ответы на вопросы по темам обучения

• Созвоны 1-2 раза в месяц на которых решаем вместе рабочие задачи

• Ранний доступ к обучающим постам на бусти
🔹 Уровень 2. Роскошный максимум.
Все то, что есть в "Базовом минимуме" +

• Общий чат по поиску работы и карьере

• Роадмап по трудоустройству: Гайды по резюме, самопрезентации, общению с hr, на hard и soft собеседовании.

• Роадмап по повышению ЗП

• Разбор твоего резюме

• Помощь в поисках работы

• Рефералки в IT компании

• Обновляемая база вопросов собеседований от топовых компаний
🔹 Уровень 3. Далеко пойдешь
Всё то, что есть в подписках выше +

2 часа на разбор твоих вопросов и проработку твоего кейса

Доступ к консультации в личном чате, 1to1

Если хочешь реально поблагодарить меня за то что я делаю
[Посмотреть условия подписок на Boosty →]

Полный курс ручного тестирования

Хочешь попрактиковаться в разных видах тестирования?
На курсе ручного тестирования:
✓ Научишься применять smoke, sanity, regression на практике
✓ Попрактикуешься в функциональном и нефункциональном
✓ Освоишь API тестирование в Postman
✓ Поймёш когда какой вид применять
✓ Подготовишься к вопросам на собесе
Формат: индивидуальное обучение 1:1
Срок: 2 месяца до оффера
Оплата: постоплата после трудоустройства
[Узнать о программе курса →]

Консультации и подготовка к собесам

Нужна разовая помощь?
Мок-собеседование (14К ₽):
  • 1.5 часа реального интервью
  • Вопросы про виды тестирования
  • Разбор ошибок
  • Скрипты правильных ответов
Разбор резюме (16К ₽):
  • 2 часа консультации
  • Исправим резюме
  • Подготовим самопрезентацию
  • План подготовки к собесам
Бесплатная консультация (30 минут):
  • Оценим твой уровень
  • Составим план обучения
  • Ответим на вопросы
[Записаться на консультацию →]
Читай также:
Обновлено: 8 ноября 2025
Еще больше полезных материалов в моем телеграм-канале https://t.me/yanaoqa
]]> Как стать тестировщиком с нуля https://yakorqa.ru/tpost/kak-stat-testirovschikom-s-nulya https://yakorqa.ru/tpost/kak-stat-testirovschikom-s-nulya?amp=true Wed, 19 Nov 2025 22:26:00 +0300 Реальный план как стать тестировщиком за 2-3 месяца. Что учить, какие инструменты, сколько стоит, как найти первую работу. Без воды.

Как стать тестировщиком с нуля

Как стать тестировщиком с нуля за 2-3 месяца: план 2025

Хочешь в IT? Думаешь про тестирование? Не знаешь с чего начать?
Я дам честный план. Без обмана про "легко" и "быстро". Расскажу сколько времени, денег и сил нужно. Покажу что работает, а что нет.
За 1.5 года я помогла 20+ людям стать тестировщиками. Средняя зарплата после обучения — 120-150К. Срок от нуля до оффера — 2-3 месяца.

Краткий ответ

Да, реально стать тестировщиком с нуля за 2-3 месяца:
Неделя 1-2: изучи теорию (виды тестирования, баг-репорты, тест-кейсы)
Неделя 3-4: освой инструменты (Postman, SQL, DevTools)
Неделя 5-6: собери портфолио (20+ баг-репортов, 10 тест-кейсов)
Неделя 7-8: подготовь резюме, готовься к собесам
Неделя 9-50: ищи работу (20-30 откликов/день)
Стоимость: от 0₽ (сам) до 150К₽ (курсы)
Нагрузка: 2-3 часа/день
Результат: Junior QA, 80-150К₽

Реально ли стать тестировщиком с нуля

Да. Но не для всех.
Подойдёт если:
✅ Готов учиться 2-3 часа каждый день
✅ Внимателен к деталям
✅ Не боишься критиковать чужую работу
✅ Готов к монотонной работе
✅ Нужна удалёнка и стабильность
НЕ подойдёт если:
❌ Хочешь "быстро и легко"
❌ Терпеть не можешь рутину
❌ Нет 2-3 часов в день
❌ Ждёшь чуда за неделю
Тестирование — самый доступный вход в IT. Не нужно писать сложный код. Не нужно высшее образование. Но нужна дисциплина.

Сколько времени нужно

Интенсив (2-3 месяца):
3-4 часа в день. 7 дней в неделю. Полная концентрация.
Результат: оффер через 8-12 недель.
Комфортный (4-6 месяцев):
1.5-2 часа в день. 5 дней в неделю. Параллельно с работой.
Результат: оффер через 16-24 недели.
Медленный (6-12 месяцев):
1 час в день. Когда получается. Без давления.
Результат: оффер когда-нибудь (или никогда).
Я рекомендую интенсив. Чем быстрее — тем меньше шанс бросить.

Сколько стоит обучение

Вариант
Стоимость
Срок
Плюсы
Минусы
Самообучение
0 - 5к руб
6 - 12 мес
Дешево
Долго, непонятно, что учить, долгое трудоустройство
Курсы
40 -150к
6 - 12 мес
Структура, сертификат
Поверхностный материал, поток от 20 человек, низкая вовлеченность преподов, разбираться все равно самому, консультаций нет
Менторство
80к-200к
2 - 3 мес
Индивидуально, полная поддержка, доведение до результата. Есть рассрочки
Дороже курсов
Менторство с пост-оплатой
Небольшая предоплата, рассрочки
2 - 3 мес
Индивидуально, полная поддержка, доведение до результата, оплата после трудоустройства. Есть рассрочки от банка
Не все менторы работают по такой схеме
Обучение по подписке
1,6к - 9к
3 - 4 мес
Максимально удобный формат попробовать, поддержка и консультации, работа в своем темпе
Меньше индивидуальной работы
Я предлагаю менторство с постоплатой: основная оплата — после твоего оффера. И пробный вариант с подпиской от 1400 рублей в месяц Условия →

Пошаговый план на 8-12 недель

Неделя 1-2: Теория основ

Что изучить:
Результат: понимаешь базу, можешь объяснить что такое баг и тест-кейс.

Неделя 3-4: Инструменты

Что освоить:
  • Postman — тестирование API (GET, POST запросы)
  • SQL — базовые запросы (SELECT, WHERE, JOIN)
  • DevTools — консоль браузера, вкладка Network
  • Jira — создание задач и багов (попробуй бесплатную версию)
  • Git — базовые команды (clone, commit, push)
Где практиковаться:
  • Postman: бесплатные API для тренировки (JSONPlaceholder)
  • SQL: sqltest.net, sql-ex.ru
  • DevTools: открой любой сайт, изучи запросы
Результат: умеешь работать с основными инструментами.

Неделя 5-6: Практика и портфолио

Что делать:
  1. Выбери 3-5 реальных сайтов (интернет-магазины, банки)
  2. Протестируй их вручную
  3. Найди 20+ багов
  4. Оформи баг-репорты по шаблону
  5. Составь 10-15 тест-кейсов
Где брать сайты:
  • Небольшие интернет-магазины
  • Стартапы
  • Свои проекты друзей
Результат: портфолио из 20 баг-репортов и 10 тест-кейсов.
Подробнее про портфолио: Баг-репорты и тест-кейсы

Неделя 7-8: Резюме и подготовка к собесам

Резюме:
  • Опиши учебные проекты как опыт
  • Добавь ссылку на портфолио (Google Drive)
  • Укажи инструменты: Postman, SQL, Jira, Git
  • Напиши о себе: переходишь в IT, мотивирован
Подготовка к собесам:
  • Выучи 50 частых вопросов
  • Примеры: "Что такое smoke?", "Приоритет vs серьезность?", "Когда regression?"
  • Практикуй ответы вслух
  • Подготовь примеры из портфолио
Результат: готовое резюме, уверенные ответы на базовые вопросы.

Неделя 9-12: Поиск работы

Где искать:
  • hh.ru, Работа.ру
  • Telegram-каналы: Job for QA, QA Jobs
  • LinkedIn (не только английский)
Как откликаться:
  • 30-45 откликов каждый день
  • Отправляй на все вакансии Junior/Intern/Trainee
  • Пиши сопроводительное письмо
  • Не жди ответа — продолжай искать
На собесе:
  • Честно говори что новичок
  • Покажи портфолио
  • Расскажи что готов учиться
  • Торгуйся за зарплату (хотя бы на 10-20%)
Результат: 10-30 собесов, 1-2 оффера через 10-15 недель.

Что нужно изучить: минимальный стек

Для Junior QA достаточно:
Теория:
✓ Виды тестирования
✓ Баг-репорты, тест-кейсы
✓ Клиент-серверная архитектура (базово)
✓ HTTP/HTTPS, REST API
Инструменты:
✓ Postman
✓ DevTools
✓ SQL (SELECT, WHERE, JOIN)
✓ Jira или аналог
✓ Git (базово)
НЕ нужно сразу:
❌ Автоматизация (Python, Selenium)
❌ CI/CD (Jenkins, GitLab)
❌ Продвинутый SQL
❌ Программирование
Автоматизацию освоишь потом, когда наберёшь опыт. Подробнее про переход в автоматизацию

Книги и ресурсы для обучения

Топ-5 книг:
  1. Святослав Куликов "Тестирование ПО. Базовый курс"
  2. Роман Савин "Тестирование Дот Ком"
  3. Гленфорд Майерс "Искусство тестирования программ"
  4. Сэм Канер "Тестирование программного обеспечения"
  5. Борис Бейзер "Тестирование черного ящика"
Полезные сайты:
  • testit.software — блог про QA
  • software-testing.ru — статьи и материалы
  • qa.studio — вебинары и гайды

Как собрать портфолио без опыта

Что должно быть:
Баг-репорты (20+ штук):
  • Разной серьёзности: Blocker, Critical, Major, Minor
  • С разных сайтов
  • Со скриншотами
  • По шаблону
Тест-кейсы (10-15 штук):
  • Позитивные и негативные
  • На разные функции: логин, корзина, поиск, оплата
  • В едином формате
Где хранить:
Google Drive с открытым доступом. Ссылку вставляй в резюме.
Лайфхак: оформи 2-3 примера особенно красиво. На собесе покажешь их первыми.

Как составить резюме начинающего QA

Структура:
1. ФИО, контакты
2. Желаемая должность: Junior QA Engineer / Стажёр-тестировщик
3. О себе:
"Изучаю тестирование 3 месяца. Прошёл курсы. Собрал портфолио из 20 баг-репортов. Готов к стажировке. Мотивирован развиваться в QA."
4. Навыки:
  • Виды тестирования: функциональное, регрессионное, smoke, sanity
  • Инструменты: Postman, SQL, DevTools, Jira, Git
  • Оформление: баг-репорты, тест-кейсы, чек-листы
5. Учебные проекты:
"Протестировал интернет-магазин XYZ: нашёл 25 багов, составил 15 тест-кейсов. Портфолио: [ссылка]"
6. Образование
7. Курсы
Что НЕ писать:
❌ "Быстро обучаюсь" (все так пишут)
❌ "Коммуникабельный" (покажи на собесе)
❌ Ложь про опыт

Частые ошибки новичков

1. Думают что достаточно курса
Сертификат ≠ работа. Нужны портфолио, практика, подготовка к собесам.
2. Не практикуются
Теория без практики не работает. Тестируй всё что видишь.
3. Шаблонное резюме
"Прошёл курсы, ищу работу". Нужна конкретика: какие проекты, какие инструменты.
4. Откликаются только на "без опыта"
Откликайся на все Junior-вакансии. Даже если пишут "опыт 1 год".
5. Сдаются после 10 отказов
Норма — 100-200 откликов на 1 оффер. Не сдавайся.
6. Не готовятся к собесам
"Авось пронесёт". Не пронесёт. Учи вопросы.
7. Боятся торговаться за зарплату
Работодатель предлагает 80К? Проси 100К. В худшем случае скажут нет.

Зарплаты тестировщиков в 2025

Москва:
  • Стажёр/Intern: 40-80К
  • Junior: 80-150К
  • Middle: 150-250К
Санкт-Петербург:
  • Стажёр: 30-60К
  • Junior: 60-120К
  • Middle: 120-200К
Регионы:
  • Стажёр: 20-50К
  • Junior: 50-100К
  • Middle: 100-180К
Удалёнка:
Зарплаты как в Москве, но конкуренция выше.
После 6-12 месяцев опыта переходишь в Middle. Зарплата +50-100%.

Реальные истории: от нуля до оффера

Игорь, 28 лет — бариста → Junior QA

Срок: 10 недель
Нагрузка: 3 часа/день
Результат: оффер 170К, удалёнка
"Учился по вечерам после работы. До этого проходил курсы, очень поверхностно. Яна помогла закрыть пробелы в знаниях, подтянуть необходимое, помогла с резюме, готовила к собесам и потом помогала на испытательном. Получил 3 оффера, выбрал лучший. Сейчас работаю 4 месяца, уже на испытательном тим-лид сказал, что я очень крут для джуна ."

Ольга, 31 год — бухгалтер → Junior QA

Срок: 12 недель
Нагрузка: 2 часа/день
Результат: оффер 150К, офис
"Боялась что не справлюсь. Но методично шла по плану. Портфолио делали с Яной на реальных проектах. На собесе зашло. Рада что решилась."

Максим, 24 года — без опыта → Junior QA

Срок: 12 недель
Нагрузка: 4 часа/день
Результат: оффер 165К, удалёнка
"Учился интенсивно. Постоплата мотивировала и меня и Яну получить крутой оффер. Прошёл 8 собесов за 3 недели. Выбрал компанию с хорошей командой."

Менторство vs самообучение vs курсы

Мой вывод:
Если хочешь результат за разумные сроки — менторство и наставшичество.
Если есть лишние деньги, время — курсы.
Если нет денег, есть время — самообучение.
💡 Узнай про менторство по подписке →

Чек-лист готовности к поиску работы

Проверь себя перед отправкой откликов:
☐ Знаю что такое smoke, sanity, regression
☐ Умею писать баг-репорты по шаблону
☐ Умею составлять тест-кейсы
☐ Знаю базовый SQL (SELECT, WHERE, JOIN)
☐ Умею работать в Postman
☐ Понимаю клиент-серверную архитектуру
☐ Есть портфолио 20+ баг-репортов
☐ Есть портфолио 10+ тест-кейсов
☐ Готово резюме со ссылкой на портфолио
☐ Выучил 50 частых вопросов на собесах
☐ Готов откликаться 10-15 раз в день
☐ Готов к отказам и продолжать искать
8+ галочек — можно начинать поиск
Меньше 8 — доучись ещё 1-2 недели

Вопросы и ответы

Реально ли с нуля за 2 месяца?
Да, если учишься 3-4 часа каждый день. Без перерывов. С ментором быстрее.
Нужно ли высшее образование?
Нет. 80% вакансий не требуют. Важнее навыки и портфолио.
Нужен ли английский?
Будет плюсом, но не обязательно.
Можно ли работать удалённо?
Да. Но на Junior-позиции чаще берут в офис или гибрид. После года опыта — больше удалёнки.
Какая конкуренция?
Высокая. 1000-2000 откликов на 1 вакансию. Но с правильной подготовкой выделишься.
Что делать если нет времени учиться?
Найди 1.5-2 часа в день. Убери сериалы, соцсети. Или откладывай мечту до лучших времён.
Сколько нужно откликов для оффера?
В среднем 200-300. Некоторым хватает 20, другим нужно 150.
Стоит ли идти на курсы?
Если есть деньги и нужна структура — да. Но курсы не гарантируют работу. Важна твоя практика.
Чем менторство лучше курсов?
Индивидуальный подход. Помощь с резюме. Подготовка к собесам. Торги за оффер. Поддержка на испытательном.

Следующие шаги

Теперь знаешь реальный план. Без обмана.
Что делать:
  1. Реши точно: хочешь или нет
  2. Выбери путь: сам, курсы или менторство
  3. Начни сегодня. Не завтра. Сегодня
  4. Учись каждый день
  5. Не сдавайся после отказов

Как я могу помочь

Бесплатная консультация (30 минут)

Запишись на созвон. Обсудим:
✓ Твою ситуацию
✓ Реальные шансы
✓ Примерную зарплату через 2-3 месяца
✓ План действий
Записаться на консультацию →

Менторство 1:1 с постоплатой

Формат: индивидуальное обучение
Срок: 2-3 месяца до оффера
Оплата: предоплата + оплата после оффера
Что входит:
✓ Теория + практика
✓ Портфолио 20+ баг-репортов
✓ Резюме и самопрезентация
✓ Подготовка к собесам
✓ Торги за оффер
✓ Поддержка на испытательном
Узнать условия →

Boosty подписки

3 уровня:
Уровень 1: Закрытый чат, обучение (все необходимое)
Уровень 2: Обучение тестированию с поддержкой при трудоустройстве (шаблоны, поддержка, резюме, собесы)
Уровень 3: Максимальный тариф с индивидуальными консультациями (резюме, собесы, оффер)
[Посмотреть подписки →]
Читай также:
Еще больше полезных материалов в моем телеграм-канале https://t.me/yanaoqa
]]> Selenium Python: первый автотест за 30 минут для QA https://yakorqa.ru/tpost/selenium-python-pervye-shagi https://yakorqa.ru/tpost/selenium-python-pervye-shagi?amp=true Wed, 03 Dec 2025 00:26:00 +0300 Учимся писать автотесты на Selenium + Python. Установка, настройка, первый тест за 30 минут. Примеры кода и объяснения для новичков.

Selenium Python: первый автотест за 30 минут для QA

Работаешь Manual QA? Хочешь в автоматизацию? Не знаешь с чего начать?
Selenium + Python — популярный стек для автоматизации UI. Я покажу как написать первый автотест за 30 минут. С установкой. С объяснениями. С рабочим кодом.
После статьи запустишь свой первый автотест. И поймёшь как работает автоматизация.

Краткий ответ

Чтобы написать первый автотест на Selenium + Python:
  1. Установи Python 3.8+
  2. Выполни: pip install selenium
  3. Скачай ChromeDriver
  4. Напиши тест: открыть сайт → найти элемент → кликнуть
  5. Запусти: python test.py
Займёт 20-30 минут.

Зачем нужен Selenium

Selenium — инструмент для автоматизации браузера. Пишешь код — он кликает кнопки, заполняет формы, проверяет результаты.
Для чего используют:
✅ Регрессионное тестирование (проверять одно и то же быстро)
✅ Smoke-тесты (критичные сценарии перед релизом)
✅ Кросс-браузерное тестирование (Chrome, Firefox, Safari)
Плюсы:
  • Бесплатный, open source
  • Поддерживает все браузеры
  • Большое комьюнити
  • Интеграция с Pytest, CI/CD
Минусы:
  • Медленнее API-тестов
  • Нестабильные тесты (flaky tests)
  • Требует обслуживания
Selenium — стандарт для UI автотестов. Знать его обязательно для AQA.

Что нужно знать перед стартом

Python базовый:
✓ Переменные, циклы, условия
✓ Функции
✓ Импорты модулей
✓ ООП минимум (классы, методы)
HTML/CSS структура:
✓ Что такое тег, атрибут, класс
✓ Как устроена страница (DOM)
✓ Как найти элемент в DevTools
Не обязательно:
❌ Продвинутый Python
❌ JavaScript
❌ Backend
💡 Не уверен готов ли к автоматизации? Читай план перехода из Manual в Automation

Системные требования

ОС: Windows 10/11, macOS 11+, Linux (Ubuntu 20+)
Python: версия 3.8 или новее
RAM: минимум 4GB (рекомендую 8GB)
Браузер: Chrome 100+ или Firefox 100+
Интернет: для установки пакетов

Установка и настройка окружения

Установка Python

Windows:
  1. Скачай с python.org
  2. При установке поставь галочку "Add Python to PATH"
  3. Проверь: открой cmd, введи python --version
macOS:
brew install python3
python3 --version
Linux:
sudo apt update
sudo apt install python3 python3-pip
python3 --version

Установка Selenium

Открой терминал (cmd на Windows):
pip install selenium
Проверь установку:
pip show selenium
Должна показаться версия 4.х.х

Установка WebDriver (ChromeDriver)

Способ 1: Автоматически (рекомендую)
Selenium 4 скачивает драйвер сам. Просто используй webdriver.Chrome().
Способ 2: Вручную
  1. Узнай версию Chrome: chrome://version
  2. Скачай ChromeDriver с chromedriver.chromium.org
  3. Положи в папку проекта или добавь в PATH
Для Firefox:
pip install webdriver-manager

Проверка установки

Создай файл test_check.py:
from selenium import webdriver

# Открываем браузер
driver = webdriver.Chrome()

# Открываем сайт
driver.get("https://google.com")

# Ждём 3 секунды
import time
time.sleep(3)

# Закрываем браузер
driver.quit()

print("Всё работает!")
Запусти:
python test_check.py
Если открылся Chrome и зашёл на Google — всё ок.

Базовые концепции Selenium

WebDriver — что это

WebDriver — программа которая управляет браузером.
Твой код → WebDriver → Браузер
Для каждого браузера свой WebDriver:
  • Chrome → ChromeDriver
  • Firefox → GeckoDriver
  • Safari → SafariDriver

Локаторы: как найти элемент

Локатор — способ найти элемент на странице.
8 типов локаторов:
Приоритет использования:
  1. ID (если есть и уникальный)
  2. CSS Selector
  3. XPath (если другие не подходят)

Основные методы

# Найти элемент
element = driver.find_element(By.ID, "email")

# Кликнуть
element.click()

# Ввести текст
element.send_keys("test@mail.ru")

# Очистить поле
element.clear()

# Получить текст
text = element.text

# Получить атрибут
value = element.get_attribute("value")

Первый автотест: пошагово

Задача: авторизация на сайте

Напишем тест:
  1. Открыть сайт
  2. Найти поле Email
  3. Ввести email
  4. Найти поле Пароль
  5. Ввести пароль
  6. Нажать кнопку "Войти"
  7. Проверить что вошли

Код теста с комментариями

Создай файл test_login.py:
from selenium import webdriver
from selenium.webdriver.common.by import By
import time

# 1. Создаём объект драйвера (открываем браузер)
driver = webdriver.Chrome()

try:
# 2. Открываем сайт
driver.get("https://example.com/login")

# Ждём загрузки страницы (плохая практика, потом заменим)
time.sleep(2)

# 3. Находим поле Email по ID
email_field = driver.find_element(By.ID, "email")

# 4. Вводим email
email_field.send_keys("test@mail.ru")

# 5. Находим поле пароля
password_field = driver.find_element(By.ID, "password")

# 6. Вводим пароль
password_field.send_keys("qwerty123")

# 7. Находим кнопку "Войти" по CSS селектору
login_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")

# 8. Кликаем
login_button.click()

# Ждём перехода
time.sleep(3)

# 9. Проверяем что вошли (ищем элемент личного кабинета)
user_menu = driver.find_element(By.CLASS_NAME, "user-menu")

if user_menu:
print("✅ Тест прошёл! Авторизация успешна.")
else:
print("❌ Тест упал! Не нашли user-menu.")

except Exception as e:
print(f"❌ Ошибка: {e}")

finally:
# 10. Всегда закрываем браузер
driver.quit()

Запуск и результат

python test_login.py
Если всё ок:
  • Откроется Chrome
  • Заполнятся поля
  • Кликнется кнопка
  • В консоли: "✅ Тест прошёл!"

Локаторы подробнее

By ID


element = driver.find_element(By.ID, "email")
Когда использовать:
Когда у элемента есть уникальный ID.
HTML:
<input id="email" type="text">

By Class Name

element = driver.find_element(By.CLASS_NAME, "btn-primary")
Внимание: если классов несколько, найдёт первый.

By XPath

# Абсолютный XPath (плохо, ломается при изменениях)
element = driver.find_element(By.XPATH, "/html/body/div/form/input")[1]

# Относительный XPath (лучше)
element = driver.find_element(By.XPATH, "//input[@id='email']")

# По тексту
button = driver.find_element(By.XPATH, "//button[text()='Войти']")

# По части текста
link = driver.find_element(By.XPATH, "//a[contains(text(), 'Регистр')]")
Как получить XPath:
  1. Открой DevTools (F12)
  2. Найди элемент
  3. ПКМ → Copy → Copy XPath

By CSS Selector

# По ID
element = driver.find_element(By.CSS_SELECTOR, "#email")

# По классу
element = driver.find_element(By.CSS_SELECTOR, ".btn-primary")

# По атрибуту
element = driver.find_element(By.CSS_SELECTOR, "input[type='email']")

# Комбинация
element = driver.find_element(By.CSS_SELECTOR, "form.login-form input#email")
CSS обычно быстрее и читабельнее XPath.

Ожидания: implicit и explicit wait

Проблема

driver.get("https://example.com")
element = driver.find_element(By.ID, "slow-element") # ❌ Ошибка! Элемент ещё не загрузился

Implicit Wait (неявное ожидание)

Selenium ждёт до X секунд перед ошибкой.
driver.implicitly_wait(10) # Ждать до 10 секунд

driver.get("https://example.com")
element = driver.find_element(By.ID, "slow-element") # ✅ Подождёт загрузки
Плюсы: настроил один раз, работает везде.
Минусы: ждёт каждый элемент, замедляет тесты.

Explicit Wait (явное ожидание)

Ждём конкретное условие для конкретного элемента.
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# Ждём до 10 секунд пока элемент станет кликабельным
wait = WebDriverWait(driver, 10)
element = wait.until(EC.element_to_be_clickable((By.ID, "button")))
element.click()
Популярные условия:
  • presence_of_element_located — элемент есть в DOM
  • visibility_of_element_located — элемент видим
  • element_to_be_clickable — элемент кликабельный
  • text_to_be_present_in_element — текст в элементе
Рекомендация: используй explicit wait для важных действий.

Pytest vs unittest для Selenium

unittest (встроенный в Python)

import unittest
from selenium import webdriver

class TestLogin(unittest.TestCase):

def setUp(self):
self.driver = webdriver.Chrome()

def test_successful_login(self):
driver = self.driver
driver.get("https://example.com/login")
# ... тест
self.assertTrue(condition)

def tearDown(self):
self.driver.quit()

if __name__ == "__main__":
unittest.main()

pytest (рекомендую)

import pytest
from selenium import webdriver

@pytest.fixture
def driver():
driver = webdriver.Chrome()
yield driver
driver.quit()

def test_successful_login(driver):
driver.get("https://example.com/login")
# ... тест
assert condition
Почему pytest лучше:
✅ Проще синтаксис (обычные функции, assert)
✅ Мощные фикстуры
✅ Параметризация тестов
✅ Лучшие отчёты
✅ Больше плагинов
Установка pytest:
pip install pytest
Запуск:
pytest test_login.py

Частые ошибки новичков

1. NoSuchElementException
selenium.common.exceptions.NoSuchElementException: Unable to locate element
Причины:
  • Элемент не загрузился (добавь ожидание)
  • Неправильный локатор (проверь в DevTools)
  • Элемент в iframe (переключись: driver.switch_to.frame())
Решение:
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)
element = wait.until(EC.presence_of_element_located((By.ID, "email")))
2. ElementNotInteractableException
Element is not clickable at point (x, y)
Причины:
  • Элемент перекрыт другим (попап, баннер)
  • Элемент вне видимой области (проскролль)
Решение:
# Скролл к элементу
driver.execute_script("arguments.scrollIntoView();", element)
element.click()
3. StaleElementReferenceException
Stale element reference: element is not attached to the page document
Причина: элемент удалён из DOM (страница обновилась).
Решение: найди элемент заново.
4. time.sleep() везде
❌ Плохо:
time.sleep(5) # Ждём всегда 5 секунд
✅ Хорошо:
WebDriverWait(driver, 10).until(...) # Ждём до 10, но продолжим как только элемент появится
5. Абсолютные XPath
❌ Плохо:
driver.find_element(By.XPATH, "/html/body/div/div/form/input")[2][1]
✅ Хорошо:
driver.find_element(By.XPATH, "//input[@id='email']")

Best practices для начинающих

1. Используй explicit waits
wait = WebDriverWait(driver, 10)
element = wait.until(EC.element_to_be_clickable((By.ID, "button")))
2. Закрывай браузер в finally
try:
driver.get("...")
finally:
driver.quit()
3. Предпочитай ID и CSS локаторам
XPath — последний вариант.
4. Делай скриншоты при ошибке
except Exception as e:
driver.save_screenshot("error.png")
raise e
5. Не храни данные в коде
# ❌ Плохо
password = "qwerty123"

# ✅ Хорошо
import os
password = os.getenv("TEST_PASSWORD")
6. Один тест — одна проверка
Не делай мега-тест на 50 шагов.
7. Используй headless для CI/CD
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument("--headless")
driver = webdriver.Chrome(options=options)

Troubleshooting: решение частых проблем

Проблема: ChromeDriver not found
Решение:
# Используй webdriver-manager
from selenium import webdriver
from webdriver_manager.chrome import ChromeDriverManager
from selenium.webdriver.chrome.service import Service

service = Service(ChromeDriverManager().install())
driver = webdriver.Chrome(service=service)
Проблема: Элемент не найден, хотя вижу его на странице
Решение:
  1. Проверь что элемент не в iframe
  2. Добавь ожидание
  3. Проверь локатор в DevTools (Ctrl+F в Elements)
Проблема: Тест работает локально, падает на CI/CD
Решение:
Используй headless режим:
options = Options()
options.add_argument("--headless")
options.add_argument("--no-sandbox")
options.add_argument("--disable-dev-shm-usage")
driver = webdriver.Chrome(options=options)

Что изучать дальше

Освоил базу? Двигайся дальше:
1. Page Object Model (POM)
Паттерн для организации кода. Вместо кучи локаторов в тесте — отдельные классы для страниц.
2. Pytest фикстуры
@pytest.fixture для setup/teardown, передачи данных.
3. Параметризация тестов
@pytest.mark.parametrize("username,password", [
("user1", "pass1"),
("user2", "pass2")
])
def test_login(username, password):
...
4. Allure отчёты
Красивые отчёты о прогоне тестов.
5. CI/CD интеграция
Запуск тестов в Jenkins, GitLab CI, GitHub Actions.
6. Selenium Grid
Параллельный запуск тестов на разных машинах.
💡 Хочешь глубже освоить автоматизацию? На курсе Automation Python пройдём всё это с ментором.

Вопросы и ответы

Сколько нужно знать Python для Selenium?
Базовый уровень: переменные, циклы, функции, импорты. ООП на минимуме.
Что лучше: XPath или CSS Selector?
CSS быстрее и читабельнее. XPath используй когда CSS не подходит (поиск по тексту, навигация вверх по DOM).
Нужен ли Selenium Grid новичку?
Нет. Сначала научись писать стабильные тесты. Grid для масштабирования.
Как найти локатор элемента?
Открой DevTools (F12) → Elements → найди элемент → ПКМ → Copy → Copy selector/XPath.
Почему тесты нестабильные (flaky)?
Нет ожиданий, динамическая подгрузка, плохие локаторы. Используй explicit waits.
Pytest или unittest?
Pytest. Проще, мощнее, популярнее.
Можно ли автоматизировать всё?
Нет. Исследовательское тестирование, UX, некоторые mobile-сценарии — руками эффективнее.

Следующие шаги

Теперь знаешь базу Selenium + Python. Написал первый автотест.
Что делать:
  1. Попрактикуйся: автоматизируй 3-5 сценариев
  2. Изучи pytest
  3. Попробуй Page Object Model
  4. Добавь тесты в портфолио

Как я могу помочь

Kонсультация

Не уверен с чего начать автоматизацию?
Запишись на созвон:
✓ Оценю твой уровень Python
✓ Скажу готов ли к Selenium
✓ Дам план обучения
✓ Отвечу на вопросы
Записаться →

Курс автоматизации Python

Хочешь глубже освоить автоматизацию?
На курсе Automation Python:
✓ Selenium + Pytest от А до Я
✓ Page Object Model
✓ CI/CD интеграция (Jenkins, GitLab)
✓ Портфолио автотестов для резюме
✓ Подготовка к собесам на AQA
Формат: 1:1 с ментором
Срок: 2-3 месяца
Узнать условия →
Еще больше полезных материалов в моем телеграм-канале https://t.me/yanaoqa
]]> Postman для API тестирования: гайд для начинающих QA https://yakorqa.ru/tpost/postman-api-testirovanie-osnovy https://yakorqa.ru/tpost/postman-api-testirovanie-osnovy?amp=true Fri, 12 Dec 2025 20:01:00 +0300 Учимся тестировать API в Postman: GET/POST запросы, коллекции, автотесты, переменные. Примеры с реальными API. Гайд для начинающих QA.

Postman для API тестирования: гайд для начинающих QA

Postman для API тестирования: первый тест за 5 минут

Сложность: 4,5/5
Работаешь Manual QA? Видел в вакансиях требование "API тестирование"? Не знаешь что это и с чего начать?
Postman — самый популярный инструмент для тестирования API. Я покажу как сделать первый запрос за 5 минут. С установкой. С примерами. Без сложной теории.
После статьи запустишь свой первый API тест. И поймёшь что это не страшно.

Быстрый старт (5 минут)

  1. Скачай Postman с postman.com (бесплатно)
  2. Установи и открой
  3. Создай новый запрос: кнопка "New" → "HTTP Request"
  4. Вставь URL: https://jsonplaceholder.typicode.com/users/1
  5. Метод: GET (уже выбран по умолчанию)
  6. Нажми Send
  7. Увидел JSON ответ внизу? Поздравляю — первый API запрос готов!
Работает? Читай дальше — разберём что произошло.

Что такое API и зачем его тестировать

API (Application Programming Interface) — способ как программы общаются между собой.
Пример:
Открываешь приложение погоды. Оно отправляет запрос на сервер: "дай погоду для Москвы". Сервер отвечает JSON с данными. Приложение показывает тебе погоду.
Запрос к серверу — это API запрос.
Зачем тестировать API:
✅ Быстрее чем UI (не надо кликать кнопки)
✅ Стабильнее (нет проблем с вёрсткой, анимациями)
✅ Находишь баги на backend до UI
✅ Можешь автоматизировать легко
✅ Проверяешь данные напрямую
Что тестируем:
  • Правильность данных (корректный JSON)
  • Статус коды (200, 400, 500)
  • Время ответа (performance)
  • Авторизацию (токены, права доступа)
  • Валидацию (что будет если ввести неверные данные)

API vs UI тестирование: в чём разница

Правило: сначала проверь API. Потом UI. Найдёшь баги раньше.
Подробнее про типы тестирования: Виды тестирования

Почему именно Postman

Плюсы:
✅ Бесплатный
✅ Удобный интерфейс (не нужен код)
✅ Коллекции (группировка запросов)
✅ Переменные окружения (dev/prod)
✅ Автотесты (встроенные assertions)
✅ Newman CLI (запуск через терминал)
✅ Документация API
✅ Mock servers
Альтернативы:
  • Insomnia (проще, но меньше функций)
  • Thunder Client (плагин для VS Code)
  • cURL (командная строка, для продвинутых)
Для Junior QA Postman — лучший выбор. Его требуют 90% работодателей.

Установка и первое знакомство

Установка Postman

Для всех ОС:
  1. Иди на postman.com/downloads
  2. Скачай версию для своей ОС
  3. Установи (стандартная установка)
  4. Запусти
  5. Создай бесплатный аккаунт (нужен для синхронизации)
Системные требования:
  • Windows 10+, macOS 10.13+, Linux
  • 4GB RAM минимум
  • 500MB свободного места

Интерфейс: что где находится

Основные элементы:
1. Workspace (рабочая область)
Твои проекты. Можно создавать личные или командные.
2. Collections (коллекции)
Папки с запросами. Группируешь по проектам: "API магазина", "API банка".
3. Requests (запросы)
Отдельные API запросы: GET /users, POST /login.
4. Environments (окружения)
Переменные для разных серверов: dev, test, prod.
5. Tests (тесты)
Автоматические проверки ответов.
Интерфейс запроса:
  • URL строка — адрес API
  • Метод — GET, POST, PUT, DELETE...
  • Params — параметры запроса
  • Headers — заголовки (авторизация, тип данных)
  • Body — тело запроса (для POST/PUT)
  • Response — ответ сервера

Основы HTTP для тестирования

HTTP методы

Статус коды

Запомни:
  • 2xx — успех
  • 4xx — ошибка клиента (твоя ошибка)
  • 5xx — ошибка сервера (их ошибка)

Headers и Body

Headers — метаданные запроса:

Content-Type: application/json
Authorization: Bearer token123
Accept: application/json
Body — данные которые отправляешь (POST/PUT):

{
"name": "John",
"email": "john@mail.com"
}

Первый запрос: пошагово

Будем использовать JSONPlaceholder — бесплатное API для тренировки.

GET запрос к публичному API

Задача: получить данные пользователя с ID=1
Шаги:
  1. Открой Postman
  2. Нажми New → HTTP Request
  3. В поле URL вставь: https://jsonplaceholder.typicode.com/users/1
  4. Убедись что метод GET (слева от URL)
  5. Нажми Send

Анализ ответа

Внизу появился ответ:
Status: 200 OK (успешно)
Time: ~300ms (скорость ответа)
Size: ~500B (размер данных)
Body (JSON):

{
"id": 1,
"name": "Leanne Graham",
"username": "Bret",
"email": "Sincere@april.biz",
"address": {
"street": "Kulas Light",
"city": "Gwenborough"
}
}

Проверка статус кода и данных

Вручную проверяем:
✓ Статус код 200
✓ ID равен 1
✓ Есть поля name, email
✓ Email содержит @
Поздравляю — протестировал API вручную!

POST запрос: создание данных

Задача: создать нового пользователя
Шаги:
  1. Создай новый запрос
  2. Метод: POST
  3. URL: https://jsonplaceholder.typicode.com/users
  4. Вкладка Body → raw → выбери JSON
  5. Вставь данные:

{
"name": "Test User",
"email": "test@example.com",
"username": "testuser"
}
  1. Нажми Send
Ответ:

{
"id": 11,
"name": "Test User",
"email": "test@example.com",
"username": "testuser"
}
Проверка:
✓ Статус 201 Created
✓ Вернулся ID нового пользователя
✓ Данные совпадают с отправленными

Коллекции: организация тестов

Коллекция — папка с запросами.
Создание коллекции:
  1. Слева нажми Collections
  2. Кнопка + (Create Collection)
  3. Назови: "JSONPlaceholder API"
  4. Перетащи запросы в коллекцию
Структура коллекции:
📁 JSONPlaceholder API
📁 Users
GET /users
GET /users/:id
POST /users
PUT /users/:id
DELETE /users/:id
📁 Posts
GET /posts
POST /posts
Плюсы:
✅ Организованность
✅ Можно запустить все тесты разом (Runner)
✅ Можно экспортировать/импортировать

Переменные окружения

Что это и зачем

Проблема: у тебя 3 сервера — dev, test, prod. URL разные. Менять в каждом запросе долго.
Решение: переменные окружения.

Создание переменных

  1. Справа вверху Environments
  2. Кнопка + (Create Environment)
  3. Назови: "Development"
  4. Добавь переменную:
  • Variable: base_url
  • Initial Value: https://jsonplaceholder.typicode.com
  • Current Value: то же самое
Сохрани
Создай ещё окружение "Production" с другим URL.

Использование {{variable}}

В запросах вместо полного URL пиши:
{{base_url}}/users/1
Postman подставит значение из активного окружения.
Переключение:
Справа вверху выбирай "Development" или "Production" из списка.
Другие переменные:
  • {{api_key}} — ключ API
  • {{auth_token}} — токен авторизации
  • {{user_id}} — ID пользователя

Автоматизация: тесты в Postman

Вкладка Tests

Тут пишешь код проверок. Выполняется после каждого запроса.
Язык: JavaScript (но простой, на уровне примеров).

Базовые assertions

Открой запрос → вкладка Tests → вставь:

javascript
// Проверка статус кода
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

// Проверка времени ответа
pm.test("Response time is less than 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});

// Проверка заголовка
pm.test("Content-Type is JSON", function () {
pm.response.to.have.header("Content-Type", "application/json; charset=utf-8");
});
Нажми Send. Внизу вкладка Test Results — видишь результаты проверок.

Проверка JSON ответа

// Парсим JSON
pm.test("Response has correct structure", function () {
var jsonData = pm.response.json();

// Проверяем поля
pm.expect(jsonData).to.have.property("id");
pm.expect(jsonData).to.have.property("name");
pm.expect(jsonData).to.have.property("email");
});

// Проверяем конкретное значение
pm.test("ID is 1", function () {
var jsonData = pm.response.json();
pm.expect(jsonData.id).to.eql(1);
});

// Проверяем тип данных
pm.test("Email is a string", function () {
var jsonData = pm.response.json();
pm.expect(jsonData.email).to.be.a("string");
});

// Проверяем что email содержит @
pm.test("Email contains @", function () {
var jsonData = pm.response.json();
pm.expect(jsonData.email).to.include("@");
});
Snippets (готовые шаблоны):
Справа во вкладке Tests есть кнопки с готовыми проверками. Кликай — код вставляется автоматически.

Запуск коллекции через Runner

Collection Runner — запускает все тесты коллекции разом.
Шаги:
  1. Открой коллекцию
  2. Кнопка Run (справа вверху)
  3. Выбери запросы которые запустить
  4. Выбери окружение
  5. Кнопка Run [Collection Name]
Результат:
Видишь какие тесты прошли (зелёные), какие упали (красные).
Плюсы:
✅ Регрессионное тестирование за 1 клик
✅ Видишь все баги разом
✅ Можно сохранить результаты

Newman: запуск через командную строку

Newman — CLI для Postman. Запускаешь коллекции без GUI.
Зачем:
✅ Интеграция в CI/CD (Jenkins, GitLab)
✅ Запуск на сервере без интерфейса
✅ Автоматизация в расписании
Установка:
bash
npm install -g newman
Экспорт коллекции:
  1. Коллекция → три точки → Export
  2. Сохрани как collection.json
Запуск:
bash
newman run collection.json
С окружением:
bash
newman run collection.json -e environment.json
Отчёт HTML:
bash
npm install -g newman-reporter-htmlextra
newman run collection.json -r htmlextra
💡 Хочешь интегрировать API тесты в CI/CD? На курсе автоматизации разберём Newman + Jenkins подробно.

Частые ошибки новичков

1. Не проверяют статус коды
Запрос прошёл, данные есть — думают всё ок. А статус 500 (ошибка сервера).
Решение: всегда проверяй статус.
2. Забывают Headers
Отправляют JSON без Content-Type: application/json. Сервер не понимает формат.
Решение: проверяй Headers, особенно при POST/PUT.
3. Хардкодят данные
Пишут URL прямо в запросах. Потом меняется сервер — надо менять везде.
Решение: используй переменные окружения.
4. Не организуют коллекции
Все запросы в куче. Невозможно найти нужный.
Решение: структурируй по папкам.
5. Не используют Pre-request Scripts
Нужен токен для каждого запроса. Копируют вручную каждый раз.
Решение:
// Pre-request Script на уровне коллекции
pm.sendRequest({
url: "{{base_url}}/auth/login",
method: "POST",
body: {
mode: "raw",
raw: JSON.stringify({
username: "admin",
password: "admin123"
})
}
}, function (err, res) {
pm.environment.set("auth_token", res.json().token);
});
6. Игнорируют валидацию схемы JSON
Решение:
var schema = {
"type": "object",
"properties": {
"id": {"type": "number"},
"name": {"type": "string"}
},
"required": ["id", "name"]
};

pm.test("Schema is valid", function() {
pm.response.to.have.jsonSchema(schema);
});

Best practices

1. Используй переменные окружения
Для URL, токенов, ID.
2. Организуй коллекции по модулям
Users, Products, Orders — отдельные папки.
3. Пиши тесты для каждого запроса
Минимум: статус код, структура JSON.
4. Используй Pre-request Scripts
Для авторизации, генерации данных.
5. Называй запросы понятно
❌ "Request 1"
✅ "GET /users - Get all users"
6. Документируй API
Postman может генерировать документацию из коллекций.
7. Версионируй коллекции
Экспортируй в Git. Отслеживай изменения.
8. Запускай тесты в CI/CD
Newman + Jenkins/GitLab = автоматизация.
9. Проверяй время ответа
Performance важен:
pm.test("Response time < 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});
10. Используй Mock Servers
Нет backend? Создай mock в Postman.

Что изучать дальше

Освоил базу Postman? Двигайся дальше:
1. Авторизация
  • Bearer Token
  • API Key
  • OAuth 2.0
  • Basic Auth
2. Pre-request Scripts
Динамическая генерация данных, цепочки запросов.
3. JSON Schema Validation
Проверка структуры ответа.
4. Data-driven testing
CSV/JSON файлы с данными для массовых тестов.
5. Mock Servers
Эмуляция API когда backend не готов.
6. Newman в CI/CD
Автоматический запуск тестов при каждом коммите.
7. Postman Monitors
Запуск коллекций по расписанию (каждый час).
8. API документация
Генерация документации из коллекций.
9. GraphQL
Postman поддерживает GraphQL запросы.
10. REST Assured (для автоматизации)
Переход на код (Java/Python) для более сложных сценариев.
На курсе ручного тестирования мы проходим Postman от базы до продвинутых техник.

Вопросы и ответы

Нужно ли знать программирование для Postman?
Нет. Базовые функции работают без кода. Для тестов нужен простой JavaScript — научишься по примерам.
Чем Postman лучше Insomnia?
Postman функциональнее: коллекции, окружения, Newman CLI, документация. Insomnia проще, но меньше возможностей.
Можно ли тестировать SOAP в Postman?
Да. Postman поддерживает SOAP запросы через XML Body.
Как авторизоваться с токеном?
Вкладка Authorization → Type: Bearer Token → вставь токен. Или в Headers: Authorization: Bearer your_token_here.
Что такое Pre-request Script?
Код который выполняется ДО отправки запроса. Нужен для получения токена, генерации данных.
Можно ли параллельно запускать тесты?
Через Newman нет (sequential). Используй Postman CLI или сторонние инструменты.
Бесплатен ли Postman?
Да. Есть платные фичи (командная работа, больше запросов к API), но для обучения хватит бесплатного.
Как сохранить коллекцию?
Экспорт: коллекция → три точки → Export → сохрани JSON. Импорт: Import → выбери файл.

Следующие шаги

Теперь знаешь основы Postman. Можешь тестировать API.
Что делать:
  1. Протестируй 3-5 публичных API (JSONPlaceholder, ReqRes, OpenWeatherMap)
  2. Создай коллекцию с тестами
  3. Запусти через Runner
  4. Попробуй Newman
  5. Добавь в портфолио

Как я могу помочь

Бесплатная консультация

Не уверен как развиваться в API тестировании?
Запишись на созвон:
✓ Оценю твой уровень
✓ Скажу что учить дальше
✓ Дам план обучения
✓ Отвечу на вопросы
Записаться →

Курс ручного тестирования

Хочешь освоить API тестирование с ментором?
На курсе ручного тестирования:
✓ Postman от А до Я
✓ REST API, JSON, авторизация
✓ Автотесты для портфолио
✓ Подготовка к вопросам про API на собесах
✓ Практика на реальных проектах
Формат: 1:1 индивидуально
Срок: 2 месяца
Оплата: постоплата после оффера
Узнать условия →

Курс автоматизации Python

Хочешь интегрировать API тесты в CI/CD?
На курсе автоматизации:
✓ Newman + Jenkins/GitLab
✓ REST Assured (Python)
✓ Data-driven testing
✓ API автотесты в портфолио
Подробнее →

Boosty подписки

3 уровня:
Уровень 1: Закрытый чат (обучение, ответы на вопросы)
Уровень 2: Помощь с трудоустройством (все что в обучении+резюме, собесы, разбор тестов)
Уровень 3: Максимум ( + консультации 1:1)
Читай также:
Еще больше полезных материалов в моем телеграм-канале https://t.me/yanaoqa
]]> Сколько зарабатывают тестировщики в 2025: реальные цифры https://yakorqa.ru/tpost/zarplata-testirovschika-2025-2026 https://yakorqa.ru/tpost/zarplata-testirovschika-2025-2026?amp=true Sat, 13 Dec 2025 20:39:00 +0300 Реальные зарплаты тестировщиков в 2025: Junior 80-150К, Middle 150-300К, Senior 300-500К. Москва, регионы, удалёнка. Что влияет на доход.

Сколько зарабатывают тестировщики в 2025: реальные цифры

Сколько зарабатывают тестировщики в 2025: реальные цифры

Думаешь стать тестировщиком? Хочешь знать сколько реально платят?
Данные собрала из 500+ вакансий hh.ru, зарплат моих учеников и опросов в QA сообществах. Актуально на декабрь 2025.

Краткий ответ: сколько платят QA

Минимум: 40-60К (стажёр в регионах)
Максимум: 500-700К (Lead QA)

Зарплаты по уровням

Junior QA (0-1 год)

Что умеет:
  • Ручное тестирование
  • Баг-репорты, тест-кейсы
  • SQL базовый, Postman, Jira
Зарплаты:
  • Москва: 80-150К (средняя 120К)
  • Регионы: 50-100К (средняя 75К)
  • Удалёнка: 70-130К (средняя 100К)

Middle QA (1-3 года)

Дополнительно умеет:
  • API тестирование
  • Базовая автоматизация
  • SQL продвинутый
Зарплаты:
  • Москва: 150-250К
  • Регионы: 100-180К

Senior QA (3-5 лет)

Зарплаты:
  • Москва: 250-400К
  • Удалёнка: 200-350К

Manual vs Automation

Вывод: Automation платят на 20-50% больше на каждом уровне.
💡 План перехода из Manual в Automation →

Зарплаты по городам

Москва (самые высокие):
  • Junior: 80-150К
  • Middle: 150-250К
Санкт-Петербург (-10-20% от Москвы):
  • Junior: 70-130К
  • Middle: 130-220К
Регионы (-20-40% от Москвы):
  • Junior: 50-100К
  • Middle: 100-180К
Удалёнка (как Москва, но выше конкуренция):
  • Junior: 70-130К
  • Middle: 120-220К

Зарплаты в топовых компаниях

Яндекс

Зарплаты:
  • Junior: 100-150К
  • Middle: 170-250К
  • Senior: 280-400К
Важно: на 10-20% ниже рынка, но большой соцпакет (ДМС, питание, спорт, обучение) + бренд в резюме. Многие идут за опытом на 1-2 года, потом переходят в стартапы за большей зарплатой.

Другие компании

  • Сбер: 90-240К (аналогично Яндексу)
  • Тинькофф: 100-280К (выше рынка, но жёсткие требования)
  • VK: 90-250К (средний рынок)

Что влияет на зарплату

1. Технологии:
  • Базовый набор (SQL, Postman): 80-120К
  • +Python/автотесты: +20-40К
  • +CI/CD, нагрузка: +30-50К
2. Английский:
3. Портфолио:
С портфолио: +20-30К к зарплате
4. Переговоры:
Умение торговаться: +20-30% на оффере

Рост зарплаты: таймлайн

Месяц 0-2: Обучение (0₽, вложения 0-150К)
Месяц 3-6: Junior 80-120К
Год 2: Middle 140-250К
Год 3-5: Senior 220-300К
Итого за 5 лет: заработал 10-12 млн₽, вложил 50-150К
ROI: 80-200x

Окупаемость обучения

Вариант 1: Самообучение
  • Вложения: 0-5К
  • Срок: 6-12-18 месяцев
  • Зарплата: 80-100К
Вариант 2: Курсы
  • Вложения: 50-100К
  • Срок: 3-6-12 месяцев
  • Зарплата: 100-130К
  • Окупаемость: 1-2 месяца
Вариант 3: Менторство
  • Вложения: 30К предоплата + постоплата
  • Срок: 2-3 месяца
  • Зарплата: 180-250К
  • Окупаемость: 2-3 месяца

Динамика: 2023-2025

Прогноз на 2026: рост 10-15%, Junior будут получать 90-160К.

Как увеличить зарплату

  1. Освой автоматизацию: +50-80К (3-4 месяца)
  2. Английский до B2: +20-30%
  3. Меняй работу каждые 1.5-2 года: +20-40% при смене
  4. Нишевые навыки (performance, security): +15-30%
  5. Учись переговорам: +20-30% на оффере
💡 Курс с менторством → — учу не только тестированию, но и переговорам о зарплате.

Вопросы и ответы

Сколько получают тестировщики без опыта?
80-120К Москва, 60-100К регионы, 70-110К удалёнка.
Правда ли Junior получают 150К?
Да, но не все. Средняя 100-120К. 150К — если хорошо подготовился и умеешь торговаться.
Automation зарабатывает больше Manual?
Да, на 20-50% в зависимости от уровня.
За сколько окупится обучение?
Вложил 50-100К → получил оффер 120К → окупил за 1-2 месяца.
Какая минимальная зарплата?
40-50К стажёры в регионах. Норма для новичка: 70-100К.
Сколько зарабатывает в Яндексе?
Junior 100-150К, Middle 170-250К. На 10-20% ниже рынка, но большой соцпакет + бренд.
Стоит ли идти ради зарплаты?
Если сейчас получаешь меньше 130К — да. Окупаешь обучение за 1-2 месяца.

Хочешь зарплату 150-220К через 2 месяца?

Бесплатная консультация:
✓ Оценю твои шансы
✓ Посчитаю реальную вилку для тебя
✓ Научу договариваться о большей зарплате
✓ Дам план достижения нужного дохода
Записаться на консультацию →
P.S. Мои ученики получают офферы на 180-250К за 2-3 месяца обучения. Оплата: есть вариант, оплаты до 9тыс в месяц, а также, когда основная часть оплаты - после оффера.
Узнать условия →
Читай также:
Еще больше полезных материалов в моем телеграм-канале https://t.me/yanaoqa
]]> Manual vs Automation: когда автоматизировать тесты https://yakorqa.ru/tpost/manual-vs-automation-testing https://yakorqa.ru/tpost/manual-vs-automation-testing?amp=true Sun, 15 Feb 2026 10:32:00 +0300 Разбираем разницу между ручным и автоматизированным тестированием. Когда автоматизировать, а когда руками. Критерии, чек-лист решения.

Manual vs Automation: когда автоматизировать тесты

Manual vs Automation: когда автоматизировать тесты

Вопрос "учить ручное или сразу автоматизацию?" задаёт каждый второй новичок в QA. И почти каждый получает размытый ответ: "зависит от ситуации". Давайте разберёмся конкретно - от чего именно зависит и как принять решение.
Короткий ответ: автоматизация нужна там, где один и тот же тест прогоняется больше 5-7 раз. Всё остальное - ручное тестирование. Но дьявол, как обычно, в деталях.
На российском рынке сейчас около 4 000 вакансий для Manual QA и примерно 2 500 для AQA. Зарплаты у автоматизаторов в среднем на 40-60% выше. Но это не значит, что ручное тестирование умирает. Скорее наоборот - спрос на грамотных мануальщиков растёт вместе с рынком.

Что такое ручное тестирование и где оно незаменимо

Ручное тестирование - это когда QA инженер сам открывает приложение, проходит сценарии, нажимает кнопки и фиксирует результат. Никакого кода. Браузер, глаза, голова.
Звучит примитивно? На деле это сложная аналитическая работа. Manual QA находит баги, которые автотест никогда не поймает. Автотест проверяет то, что в него заложили. А человек замечает странности: "кнопка работает, но выглядит криво", "текст обрезается на мобильном", "после оплаты нет подтверждения - пользователь растеряется".
Ручное тестирование незаменимо в нескольких случаях:
Исследовательское тестирование.
Новая фича, документации мало, нужно "пощупать" продукт. Автотест тут бесполезен - вы ещё не знаете, что именно проверять.
UX и юзабилити.
Удобно ли расположены элементы? Понятен ли текст ошибки? Это оценивает человек, не скрипт.
Одноразовые проверки.
Заказчик попросил проверить конкретный сценарий. Писать автотест ради одного прогона - трата времени.
Тестирование на ранних стадиях.
Когда интерфейс меняется каждый день, автотесты ломаются быстрее, чем вы их пишете.

Что такое автоматизация и когда она окупается

Автоматизация - это код, который тестирует приложение вместо вас. Написали скрипт один раз, запускаете хоть 50 раз в день. Selenium открывает браузер, заполняет формы, кликает кнопки и сверяет результат с ожидаемым.
Главная метрика здесь - ROI (возврат инвестиций). Написать автотест дороже, чем прогнать тест руками один раз. Но если этот тест нужно прогонять каждый день - автоматизация окупается за 2-3 недели.
Конкретный пример. Регрессионный набор из 200 тест-кейсов. Вручную один QA проходит его за 3 рабочих дня. Автотесты проходят тот же набор за 40 минут. При еженедельных релизах экономия - 2.5 рабочих дня в неделю. За месяц это 10 рабочих дней одного инженера.
Автоматизация окупается, когда:
- Тест запускается регулярно (регрессия, smoke-тесты)
- Интерфейс стабилен и не меняется каждую неделю
- Есть чёткие входные и выходные данные
- Тест включает много однотипных операций
Автоматизация не окупается, когда:
- Фича ещё в разработке и UI нестабилен
- Тест запускается 1-2 раза за жизнь проекта
- Проверка субъективная (визуал, удобство)
- Стоимость поддержки автотеста выше стоимости ручного прогона

Пирамида тестирования: как распределить усилия

Пирамида тестирования - это модель, которая показывает, сколько тестов какого типа нужно писать. Снизу вверх:
Unit-тесты (70%).
Проверяют отдельные функции в коде. Пишут разработчики. Один unit-тест выполняется за миллисекунды. Самые быстрые и дешёвые.
Интеграционные тесты (20%).
Проверяют взаимодействие компонентов: API-запросы, связки сервисов, работу с базой данных. Пишут разработчики или AQA. Выполняются за секунды.
E2E тесты (10%).
Проверяют сценарий целиком: пользователь открыл сайт, зарегистрировался, оплатил заказ. Пишут AQA на Selenium или Playwright. Выполняются за минуты.
Ошибка, которую допускают многие команды: перевернутая пирамида. 200 E2E тестов, 30 интеграционных, 0 юнитов. Результат - тесты идут часами, постоянно падают из-за нестабильных локаторов, команда тратит больше времени на поддержку тестов, чем на тестирование.

Чек-лист: автоматизировать или нет

Конкретный чек-лист. Если на 4+ вопроса ответ "да" - автоматизируйте:
1. Тест запускается чаще одного раза в неделю?
2. Сценарий стабилен и не менялся последний месяц?
3. Есть чёткие ожидаемые результаты (число, текст, статус)?
4. Тест включает больше 10 шагов?
5. Тестовые данные можно генерировать программно?
6. Релизы выходят чаще раза в месяц?
7. В команде есть человек, который умеет писать автотесты?
Последний пункт - критичный. Автоматизация без компетенции в команде превращается в мёртвый код. Тесты написали, через месяц они сломались, никто не чинит, все вернулись к ручному тестированию.

Инструменты: что учить в каждом направлении

Стек Manual QA:
- Jira / YouTrack - трекеры задач и багов
- TestRail / Qase - управление тест-кейсами
- Postman - тестирование API
- DevTools - инспектирование элементов, сетевые запросы
- Charles / Fiddler - перехват трафика
- SQL - проверка данных в базе
Стек AQA (Python):
- Python 3 - язык автотестов
- Selenium / Playwright - управление браузером
- pytest - фреймворк для запуска тестов
- Allure - отчёты
- Git - версионирование кода
- Docker - изоляция тестового окружения
- Jenkins / GitLab CI - запуск тестов в пайплайне
Почему Python? Низкий порог входа, огромное комьюнити, большинство вакансий AQA в России - на Python. Java тоже востребована, но учить её дольше. Средний срок перехода из Manual в AQA: 3-6 месяцев при ежедневных занятиях по 1.5-2 часа.

Зарплаты: Manual QA vs AQA в цифрах

Разница в зарплатах ощутимая. Данные по России на начало 2026 года:
Junior Manual QA: 50 000 - 90 000 руб.
Junior AQA: 80 000 - 130 000 руб.
Middle Manual QA: 100 000 - 170 000 руб.
Middle AQA: 160 000 - 270 000 руб.
Senior Manual QA: 180 000 - 280 000 руб.
Senior AQA: 270 000 - 420 000 руб.
Разница между мидл-мануальщиком и мидл-автоматизатором - 60 000-100 000 рублей в месяц. За год это 720 000 - 1 200 000 рублей. Ради такой суммы 4-6 месяцев обучения - разумная инвестиция.
Но есть нюанс. Senior Manual QA с глубоким знанием предметной области (финтех, медтех, e-commerce) зарабатывает на уровне мидл-автоматизатора. Экспертиза в домене ценится высоко.

Частые ошибки при переходе в автоматизацию

"Автоматизирую всё подряд."
Нет. Начните с smoke-тестов - 10-15 критичных сценариев. Потом добавляйте регресс. Покрывать 100% - утопия.
"Не разобрался в ручном, иду сразу в AQA."
Автотест проверяет бизнес-логику. Если вы не понимаете, как тестировать руками - вы напишете автотест, который проверяет не то. Минимум 3 месяца ручного тестирования - это фундамент.
"Скопировал код из туториала и работает."
Работает сейчас. Через неделю сломается, и вы не поймёте почему. Изучайте язык программирования как следует, а не надёрганные куски.

Вопросы и ответы

Можно ли работать ручным тестировщиком и зарабатывать хорошо?
Да. Senior Manual QA в финтехе или крупном e-commerce получает 200 000-280 000 рублей. Но таких позиций меньше, конкуренция за них выше. Знание автоматизации расширяет выбор вакансий.
Через сколько месяцев ручного тестирования переходить в автоматизацию?
Оптимально - через 3-6 месяцев. К этому моменту вы понимаете процесс тестирования, умеете писать тест-кейсы и знаете, какие сценарии повторяются. Это и будут кандидаты на автоматизацию.
Какой язык учить для автоматизации: Python или Java?
Python - быстрее старт, больше вакансий для джуниоров. Java - шире стек, чаще встречается в энтерпрайзе. Для первого языка берите Python.

Как выбрать своё направление

Решение зависит от трёх факторов: что вам интереснее, где вы сейчас и куда хотите прийти через год.
Если вы только входите в QA - начинайте с ручного тестирования. Это база. Без неё автоматизация превращается в бессмысленное написание кода.
Если вы мануальщик с опытом от полугода и чувствуете потолок - самое время двигаться в автоматизацию. Python + Selenium + pytest - стандартный стек, который покрывает 80% вакансий.
У меня есть программы для обоих направлений: курс Fullstack тестирования для старта и менторство по автоматизации на Python для перехода. На бесплатной консультации разберём ваш уровень и составим индивидуальный план. Без обязательств, без продаж в лоб.
Записаться на консультацию https://t.me/yakorqa
]]> SQL для QA инженера: JOIN, SELECT и проверка данных https://yakorqa.ru/tpost/sql-dlya-qa-join-zapros https://yakorqa.ru/tpost/sql-dlya-qa-join-zapros?amp=true Fri, 27 Feb 2026 14:50:00 +0300 Учим SQL для тестировщика: SELECT, WHERE, JOIN, GROUP BY. Практические запросы для проверки данных в базе. Примеры из реальной работы QA.

SQL для QA инженера: JOIN, SELECT и проверка данных

SQL для QA: JOIN запросы и проверка данных

Тестировщик открыл баг: "При оформлении заказа отображается неправильная цена". Разработчик спрашивает: "А в базе какая цена?" И тут два варианта. Первый - QA идёт к разработчику и просит посмотреть. Второй - открывает терминал, пишет SELECT и за 10 секунд получает ответ.
SQL - это язык для работы с базами данных. Для QA инженера это инструмент проверки данных: правильно ли записался заказ, совпадает ли цена на фронте с ценой в базе, не потерялись ли данные при импорте. Без SQL тестировщик видит только интерфейс. С SQL - видит всю картину.
В этой статье разберём именно то, что нужно QA: SELECT, WHERE, JOIN и конкретные приёмы проверки данных. Без теории ради теории - только практика.

Базовые запросы: SELECT и WHERE

Всё начинается с SELECT. Это команда для получения данных из таблицы.
SELECT * FROM users;
Этот запрос вернёт все строки и все столбцы из таблицы users. Звёздочка (*) означает "все столбцы".
На практике все столбцы нужны редко. Выбирайте конкретные:
SELECT id, name, email FROM users;
WHERE добавляет фильтрацию:
SELECT id, name, email FROM users WHERE status = 'active';
Этот запрос вернёт только активных пользователей.
Операторы фильтрации, которые нужны каждый день:
= равно
!= или <> не равно
> < >= <= сравнение
BETWEEN x AND y диапазон
IN (a, b, c) одно из значений
LIKE '%текст%' поиск по части строки
IS NULL / IS NOT NULL проверка на пустое значение
Пример из реальной работы QA. Вам нужно проверить, что все заказы за последнюю неделю имеют статус:
SELECT id, status, created_at FROM orders
WHERE created_at >= '2026-02-21'
AND status NOT IN ('completed', 'cancelled');
Если запрос вернул строки - значит есть заказы в непонятном статусе. Это потенциальный баг.

ORDER BY и LIMIT: сортировка и ограничение

ORDER BY сортирует результат:
SELECT * FROM orders ORDER BY created_at DESC;
DESC - от новых к старым. ASC (по умолчанию) - от старых к новым.
LIMIT ограничивает количество строк:
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;
Последние 10 заказов. Полезно, когда в таблице миллионы строк и SELECT * повесит базу.
Комбинация ORDER BY + LIMIT - ваш основной инструмент для быстрых проверок: "Покажи последние 5 регистраций", "Покажи самый дорогой заказ".

GROUP BY и агрегатные функции

GROUP BY группирует строки для подсчёта статистики. Агрегатные функции работают с группами:
COUNT(*) - количество строк
SUM(column) - сумма
AVG(column) - среднее
MIN(column) - минимум
MAX(column) - максимум
Пример: сколько заказов в каждом статусе?
SELECT status, COUNT(*) as cnt
FROM orders
GROUP BY status;
Результат:
completed 1250
pending 43
cancelled 87
processing 12
Если вы видите 500 заказов в статусе "processing" при норме 10-15 - что-то сломалось.
HAVING фильтрует результаты после группировки:
SELECT user_id, COUNT(*) as order_count
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 100;
Пользователи с более чем 100 заказами. Может быть тестовый аккаунт, а может - баг с дублированием.

JOIN: объединение таблиц

JOIN - самая важная тема для QA после SELECT. Данные в базе разложены по таблицам: пользователи отдельно, заказы отдельно, товары отдельно. Чтобы собрать полную картину, таблицы нужно объединить.
INNER JOIN - пересечение
Возвращает строки, которые есть в обеих таблицах:
SELECT u.name, o.id as order_id, o.total
FROM users u
INNER JOIN orders o ON u.id = o.user_id;
Покажет пользователей, у которых есть заказы. Пользователи без заказов и заказы без пользователей - не попадут.
LEFT JOIN - все из левой таблицы
Возвращает все строки из левой таблицы, даже если в правой нет совпадений:
SELECT u.name, o.id as order_id
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;
Покажет всех пользователей. У тех, кто не делал заказов, в столбце order_id будет NULL.
Это мощный приём для QA. Хотите найти пользователей без заказов?
SELECT u.name, u.email
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.id IS NULL;
Если среди них есть пользователи, зарегистрированные месяц назад и с подтверждённой оплатой - это баг: деньги списали, заказ не создался.
RIGHT JOIN и FULL JOIN
RIGHT JOIN - зеркало LEFT JOIN, все строки из правой таблицы. На практике используется редко: проще поменять таблицы местами и написать LEFT JOIN.
FULL JOIN - все строки из обеих таблиц. Полезен для поиска рассинхронизации: записи есть в одной системе, но нет в другой.

Практические запросы для QA

Вот конкретные запросы, которые QA используют каждый день:
Проверка дублей:
SELECT email, COUNT(*) as cnt
FROM users
GROUP BY email
HAVING COUNT(*) > 1;
Если email уникален - запрос ничего не вернёт. Если вернул строки - баг в валидации регистрации.
Проверка целостности данных:
SELECT o.id
FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE u.id IS NULL;
Заказы без пользователя. Если такие есть - нарушена целостность данных.
Сравнение сумм:
SELECT o.id, o.total,
SUM(oi.price * oi.quantity) as calculated_total
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
GROUP BY o.id, o.total
HAVING o.total != SUM(oi.price * oi.quantity);
Находит заказы, где сумма в заголовке не совпадает с суммой позиций. Классический баг в интернет-магазинах.
Поиск аномалий по времени:
SELECT DATE(created_at) as day, COUNT(*) as registrations
FROM users
GROUP BY DATE(created_at)
ORDER BY registrations DESC
LIMIT 10;
Дни с аномально высокой регистрацией. Может быть маркетинговая акция, а может - бот-атака.
Проверка статусных переходов:
SELECT * FROM orders
WHERE status = 'delivered'
AND paid_at IS NULL;
Доставленные, но не оплаченные заказы. Если бизнес-логика требует оплату до доставки - это баг.

Частые ошибки новичков в SQL

SELECT * в продакшн-базе
Таблица с миллионом строк. SELECT * без WHERE и LIMIT - и база зависла на 5 минут. Всегда добавляйте LIMIT при первом запросе к незнакомой таблице.
Путаница WHERE и HAVING
WHERE фильтрует строки до группировки. HAVING - после. WHERE status = 'active' GROUP BY city - сначала отфильтрует активных, потом сгруппирует по городам. HAVING COUNT(*) > 10 - сначала сгруппирует, потом отфильтрует группы.
Забыли про NULL
WHERE status != 'cancelled' НЕ вернёт строки, где status = NULL. NULL - это не значение, а отсутствие значения. Правильно: WHERE status != 'cancelled' OR status IS NULL.
JOIN без понимания связей
Прежде чем писать JOIN, поймите связи между таблицами. Один пользователь - много заказов (один-ко-многим). Один заказ - много товаров (один-ко-многим через order_items). Неправильный JOIN даст дублирование строк или потерю данных.

Где практиковать SQL

Теория без практики в SQL бесполезна. Вот конкретные ресурсы:
- sql-ex.ru - задачи от простых к сложным, классика для подготовки к собеседованиям
- leetcode.com/problemset/database - SQL-задачи с проверкой
- pgexercises.com - интерактивные упражнения на PostgreSQL
- mode.com/sql-tutorial - туториал с реальными данными
Минимальная программа для QA: решите 30-40 задач на sql-ex.ru (разделы SELECT, JOIN, GROUP BY). Этого хватит для 90% рабочих ситуаций и собеседований.

Вопросы и ответы по SQL для QA

Какой SQL нужен тестировщику: MySQL, PostgreSQL или другой?
Синтаксис базовых запросов одинаков везде. SELECT, JOIN, WHERE, GROUP BY работают и в MySQL, и в PostgreSQL, и в MS SQL. Различия начинаются в продвинутых функциях: оконные функции, CTE, специфичные типы данных. Для старта язык значения не имеет.
Обязательно ли учить SQL для первой работы в QA?
Для Junior Manual QA - желательно, но не блокирует. Для Middle и выше - обязательно. На собеседованиях SQL спрашивают в 7 из 10 компаний. Базовый уровень осваивается за 2-3 недели ежедневных занятий по часу.
Можно ли случайно удалить данные в рабочей базе?
Да, если есть права на запись. Поэтому на проде QA обычно получает read-only доступ. На тестовых стендах - полный доступ. Золотое правило: перед DELETE или UPDATE всегда сначала запустите SELECT с тем же WHERE и убедитесь, что выбраны правильные строки.

SQL как ступень роста в QA

SQL отделяет начинающего тестировщика от уверенного. С SQL вы не зависите от разработчика при проверке данных, быстрее локализуете баги и можете аргументировать свои баг-репорты конкретными данными из базы.
Освоить базовый SQL для QA можно за 2-3 недели. Это одна из самых быстро окупаемых инвестиций в карьере тестировщика - и на собеседованиях, и в ежедневной работе.
Если хотите изучать SQL и другие инструменты QA с ментором, который объяснит на реальных примерах - у меня есть индивидуальное менторство. Разберём ваш уровень, составим план обучения и будем двигаться в вашем темпе.
Записаться на бесплатную консультацию:
https://t.me/yakorqa
]]>