Практическая подготовка Junior QA: Инструментарий Postman и SQL для технического интервью

Жизненный цикл тестирования и стратегия подготовки к техническому интервью

Представьте, что вы приходите на собеседование в крупный финтех-проект. Рекрутер задает невинный вопрос: «С чего вы начнете тестирование новой фичи?». Если ваш ответ начинается с фразы «Я открою приложение и нажму кнопку», интервьюер мысленно ставит пометку «недостаточно системности». В мире коммерческой разработки тестирование — это не хаотичный поиск багов, а строго регламентированный процесс, вписанный в жизненный цикл разработки ПО (SDLC).

Место тестирования в современном SDLC

Современные IT-компании давно отошли от линейной модели Waterfall в пользу гибких методологий вроде Scrum. В Agile-среде тестирование перестало быть финальным этапом перед релизом. Оно интегрировано в каждый «спринт». Это означает, что Junior QA должен понимать не только как завести баг-репорт, но и как анализировать требования еще до того, как написана первая строчка кода.

Жизненный цикл тестирования (STLC) состоит из нескольких фаз: анализ требований, планирование, проектирование тестов, настройка окружения, выполнение и завершение. На техническом интервью часто проверяют понимание фазы анализа. Если вы обнаружите логическую дыру в документации (например, в ТЗ не указано, что делать, если пользователь ввел отрицательную сумму перевода), вы сэкономите компании тысячи долларов. Исправление ошибки на этапе дизайна в десятки раз дешевле, чем на этапе эксплуатации.

> «Чем раньше обнаружена ошибка, тем меньше стоимость её исправления. Ошибка, найденная в продакшене, может стоить в 100 раз дороже, чем та, что была выявлена на этапе анализа требований». > > Software Testing Life Cycle — Wikipedia

Стратегия подготовки к техническому интервью

Техническое интервью для Junior QA — это проверка трех составляющих: теоретической базы, владения инструментами (Postman, SQL) и «тестировочного мышления». Ваша задача — показать, что вы умеете декомпозировать сложную задачу на простые проверки.

Подготовка должна быть сфокусирована на практических сценариях. На интервью вас не попросят процитировать определение «регрессионного тестирования» по учебнику. Скорее, вас спросят: «У нас обновился модуль авторизации. Какие тесты вы прогоните в первую очередь и почему?». Здесь важно продемонстрировать понимание приоритетов. Сначала — Smoke-тестирование (проверка основной функции), затем — Critical Path (основные сценарии использования), и только потом — негативные тесты и проверка граничных значений.

Разбор сценария: Тестирование формы регистрации

Рассмотрим пошаговый процесс подготовки к тестированию стандартной формы регистрации пользователя (Email, Пароль, Подтверждение пароля).

Шаг 1: Анализ требований. Прежде чем писать тесты, уточните детали. Какой длины может быть пароль? Какие символы разрешены? Должен ли Email быть уникальным? На интервью этот шаг показывает вашу дотошность.

Шаг 2: Применение техник тест-дизайна. Не нужно проверять пароли длиной 8, 9, 10, 11 символов. Используйте эквивалентное разделение и анализ граничных значений. Если лимит 8–16 символов, проверьте 7 (негатив), 8 (граница), 12 (позитив), 16 (граница) и 17 (негатив).

Шаг 3: Проверка логики и безопасности. Попробуйте зарегистрировать уже существующий Email. Проверьте, маскируется ли пароль при вводе (звездочки вместо символов). Посмотрите, как форма реагирует на SQL-инъекции в поле ввода (это мостик к вашим знаниям SQL).

Шаг 4: Кроссбраузерность и адаптивность. Как форма ведет себя на iPhone Safari и на десктопном Chrome? Не «едет» ли верстка при разрешении ?

Шаг 5: Ожидаемый результат. Для каждого теста четко сформулируйте, что должно произойти. Например: «Система выдает ошибку "Пароль слишком короткий", кнопка "Зарегистрироваться" заблокирована».

Ловушки и типичные ошибки новичков

Частая ошибка на интервью — зацикливание на UI-тестировании. Кандидат долго рассказывает, как он будет проверять цвет кнопки или шрифт. В реальности современный QA тратит 70% времени на проверку того, что «под капотом»: API и базы данных. Если кнопка красивая, но после нажатия данные не улетают на сервер или сохраняются в базе с ошибкой — тест провален.

Еще одно заблуждение — стремление найти «все баги». Важно понимать концепцию исчерпывающего тестирования: оно невозможно. Ваша цель — обеспечить достаточное качество продукта в рамках имеющегося времени и ресурсов. На вопрос «Когда вы остановите тестирование?» правильный ответ базируется на критериях выхода (Exit Criteria), прописанных в тест-плане, а не на ощущении, что «багов больше нет».

Если вы претендуете на позицию Junior, будьте готовы к «задачкам на карандаш». Вам дадут физический объект (лифт, банкомат, зажигалку) и попросят протестировать его. Не теряйтесь. Сразу делите проверки на функциональные, нефункциональные (нагрузка, удобство, безопасность) и локализацию. Это покажет вашу структурность.

Тестирование API: Основы протокола HTTP и работа с методами в Postman

Когда вы нажимаете кнопку «Заказать» в приложении по доставке еды, магия происходит не на экране смартфона. Ваше приложение отправляет сообщение серверу, используя протокол HTTP. Для Junior QA понимание того, как устроено это сообщение, — критически важный навык. На интервью вас обязательно спросят: «В чем разница между GET и POST?» или «Что означает статус-код 403?». Если вы ответите уверенно, это подтвердит, что вы понимаете архитектуру клиент-серверного взаимодействия.

Анатомия HTTP-запроса и ответа

Любое взаимодействие в вебе строится по принципу «Запрос — Ответ». Клиент (Postman или браузер) формирует запрос, сервер его обрабатывает и возвращает ответ.

Запрос состоит из трех частей:

Ответ сервера имеет похожую структуру, но вместо метода содержит Status Code. Эти коды — язык, на котором сервер сообщает о результате.

Основные методы API: CRUD в действии

В тестировании API мы чаще всего работаем с концепцией CRUD (Create, Read, Update, Delete). Каждому действию соответствует свой HTTP-метод.

| Действие | HTTP Метод | Описание | | :--- | :--- | :--- | | Create | POST | Создание нового ресурса. Всегда имеет тело запроса. | | Read | GET | Получение данных. Данные передаются в URL (query-параметры). | | Update | PUT / PATCH | Обновление. PUT заменяет ресурс целиком, PATCH — частично. | | Delete | DELETE | Удаление ресурса. |

Важный нюанс для интервью: метод GET считается идемпотентным. Это значит, что сколько бы раз вы ни вызывали GET /user/1, состояние системы не изменится (вы просто читаете данные). А вот POST не идемпотентен: каждый новый запрос может создавать нового пользователя в базе данных.

Практическая работа в Postman: создание первого запроса

Postman — это «швейцарский нож» для тестировщика. Он позволяет имитировать работу фронтенда и проверять бэкенд напрямую.

Шаг 1: Установка URL и метода. Допустим, у нас есть эндпоинт https://api.example.com/v1/users. Выбираем метод GET, чтобы посмотреть список пользователей. Нажимаем Send и анализируем JSON-ответ в нижней панели.

Шаг 2: Работа с Query-параметрами. Если нам нужно найти пользователя по имени, мы используем вкладку Params. Добавляем ключ name и значение Ivan. URL превратится в .../users?name=Ivan. Это стандартный способ фильтрации данных в GET-запросах.

Шаг 3: Отправка данных через POST. Чтобы создать пользователя, переключаем метод на POST. Переходим во вкладку Body, выбираем тип raw и формат JSON. Пишем структуру:

После отправки мы ожидаем статус 201 Created и объект с созданным ID в ответе.

Шаг 4: Проверка статус-кодов. Тестировщик всегда ищет негативные сценарии. Что будет, если отправить POST с пустым телом? Сервер должен вернуть 400 Bad Request. Если он вернет 500 — это баг, сервер не справился с обработкой некорректных данных.

Почему тестирование API важнее UI-тестов?

На интервью вас могут спросить про «Пирамиду тестирования». Тесты API находятся посередине: они быстрее и стабильнее, чем UI-тесты (которые часто ломаются при изменении дизайна), но покрывают бизнес-логику лучше, чем Unit-тесты.

Если вы нашли баг на уровне API (например, сервер позволяет перевести отрицательную сумму денег, хотя фронтенд рисует ошибку), вы предотвратили критическую уязвимость. Фронтенд можно обойти, отправив запрос напрямую через Postman, поэтому валидация на бэкенде — это «последняя линия обороны».

> «API-тестирование позволяет проверять логику приложения без привязки к интерфейсу, что делает тесты более надежными и легкими в поддержке». > > API Testing — Wikipedia

Продвинутый Postman: Организация коллекций, работа с переменными и скриптами

На реальных проектах количество запросов в API измеряется сотнями. Если вы будете каждый раз вручную менять ID пользователя в URL или копировать токен авторизации из одного запроса в другой, вы быстро утонете в рутине. На техническом интервью опытный QA отличается от новичка именно умением автоматизировать эти процессы внутри Postman.

Коллекции и переменные: избавляемся от хардкода

Коллекция в Postman — это не просто папка для запросов. Это контейнер, который может иметь свои скрипты и переменные. Представьте, что у вас есть три окружения: dev, staging и production. У каждого свой базовый URL. Вместо того чтобы создавать три копии запросов, мы используем переменные окружения (Environments).

Мы пишем в строке адреса: {{baseUrl}}/users. Теперь, переключая окружение в верхнем правом углу Postman, значение {{baseUrl}} будет подставляться автоматически. Это избавляет от «хардкода» (жестко прописанных значений) и делает ваши тесты переносимыми.

Существует иерархия переменных:

Скрипты Pre-request и Tests: магия автоматизации

Postman позволяет писать код на JavaScript. Это открывает две мощные возможности:

Пример простейшего теста во вкладке Tests:

Если сервер вернет 404, этот тест подсветится красным. На интервью важно упомянуть, что вы не просто «смотрите глазами» на ответ, а используете автоматические проверки.

Пошаговый разбор: цепочка запросов (Chaining)

Один из самых частых сценариев на собеседовании: «Как протестировать создание и последующее удаление сущности, если ID генерируется сервером?». Это называется Request Chaining.

Шаг 1: Создание (POST). Отправляем запрос на создание пользователя. Во вкладке Tests пишем скрипт, который вытягивает ID из ответа и сохраняет его в переменную окружения:

Шаг 2: Использование переменной. Создаем следующий запрос GET /users/{{current_user_id}}. Postman сам подставит ID, который мы получили на предыдущем шаге.

Шаг 3: Удаление (DELETE). Используем тот же {{current_user_id}} в методе DELETE.

Шаг 4: Проверка очистки. Снова вызываем GET. Если сервер вернул 404 Not Found, значит, цепочка тестов прошла успешно: сущность создана, проверена и корректно удалена.

Работа с динамическими данными и Runner

Чтобы тесты были разнообразными, используйте встроенные динамические переменные Postman. Например, {{randomFullName}}. Это позволяет создавать уникальных пользователей при каждом запуске, избегая ошибок дублирования в базе данных.

Когда запросов становится много, на помощь приходит Collection Runner. Он позволяет запустить всю коллекцию (или папку) целиком одной кнопкой. Вы можете задать количество итераций и даже подгрузить файл данных (CSV или JSON), чтобы прогнать один и тот же запрос с разными наборами параметров. Это зачатки полноценного автотестирования.

> «Использование переменных и скриптов в Postman превращает инструмент из простого HTTP-клиента в мощную платформу для автоматизированного тестирования API». > > Postman Documentation — Variables

Если на интервью вас спросят, как вы проверяете структуру JSON-ответа, обязательно упомяните JSON Schema Validation. Это продвинутый способ проверки, который гарантирует, что сервер прислал не просто «какие-то данные», а данные строго определенного типа (например, что age — это число, а не строка).

Основы SQL: Выборка данных, фильтрация и сортировка в реляционных базах

Для тестировщика база данных — это «источник истины». Если в приложении написано, что у вас на счету 1000 рублей, QA должен уметь заглянуть в БД и проверить, действительно ли там лежит число 1000, а не 1000.000001 или строка "1000". На интервью знание SQL часто становится решающим фактором: разработчики ценят тестировщиков, которые могут сами локализовать проблему, не отвлекая их вопросами «а что там в базе?».

Реляционная модель и структура таблиц

Большинство современных систем используют реляционные базы данных (PostgreSQL, MySQL, MS SQL). Данные в них хранятся в таблицах, которые связаны между собой. Каждая таблица состоит из строк (записей) и столбцов (атрибутов).

Ключевые понятия, которые нужно знать для старта:

Самый важный запрос в жизни любого QA — это SELECT. Он позволяет «выбрать» данные из таблицы.

Если нужно вытащить всё, используется звездочка: SELECT * FROM users;. Однако на реальных проектах с миллионами записей так делать не стоит — это нагружает базу.

Фильтрация данных: оператор WHERE

Обычно нам не нужны все пользователи, а только те, у кого есть проблемы. Для этого используется оператор WHERE.

Основные операторы сравнения:

Знак % в операторе LIKE — это джокер. %@gmail.com найдет все почты, заканчивающиеся на gmail. Ivan% найдет Ивана, Иванова и Иванченко.

Сортировка и ограничение выборки

Чтобы данные было удобно читать, мы используем ORDER BY. По умолчанию сортировка идет по возрастанию (ASC), но можно задать и по убыванию (DESC).

Этот запрос покажет самых богатых пользователей в начале списка.

Если записей слишком много, используйте LIMIT. Например, LIMIT 10 вернет только первые 10 строк. Это полезно при тестировании пагинации (постраничного вывода) в приложении.

Пример: Тестирование интернет-магазина через БД

Представьте задачу: вам нужно проверить, что в админке сайта правильно отображаются «Заказы за последнюю неделю на сумму более 5000 рублей, отсортированные от новых к старым».

Шаг 1: Формируем базовый запрос. Выбираем нужные поля из таблицы заказов: SELECT id, user_id, amount, created_at FROM orders

Шаг 2: Добавляем фильтр по сумме. WHERE amount > 5000

Шаг 3: Добавляем фильтр по дате. Используем логический оператор AND: AND created_at >= '2023-10-01'

Шаг 4: Сортируем. ORDER BY created_at DESC

Итоговый запрос:

Выполнив этот запрос, вы сравниваете результат из консоли БД с тем, что выдает UI сайта. Если данные не совпадают — вы нашли баг.

Опасности и нюансы: NULL и регистр

В SQL есть особое значение — NULL. Это не ноль и не пустая строка, это «отсутствие значения». Обычные операторы вроде = с ним не работают. Чтобы найти записи с пустым полем, нужно писать WHERE phone IS NULL.

Также помните про регистр. В некоторых базах данных (как PostgreSQL) поиск по строкам чувствителен к регистру: 'ivan' и 'Ivan' — это разные значения. Для QA это отличное поле для тестов: как система поведет себя, если пользователь введет логин капсом?

> «SQL является декларативным языком программирования: вы описываете, какой результат хотите получить, а не как его должна извлечь база данных». > > SQL — Wikipedia

Сложные SQL-запросы: Объединение таблиц через JOIN и агрегация данных

На техническом интервью Junior QA часто слышит задачу: «Есть таблица пользователей и таблица их заказов. Напишите запрос, который выведет имена пользователей и общую сумму их покупок». Эта задача проверяет два ключевых навыка: умение объединять таблицы (JOIN) и работать с агрегатными функциями. В реальных системах данные нормализованы (разнесены по разным таблицам), чтобы избежать дублирования, поэтому без JOIN вы не сможете собрать полную картину для теста.

Как работают объединения (JOIN)

Представьте две таблицы: Users (id, name) и Orders (id, user_id, amount). В таблице заказов нет имен, только user_id. Чтобы увидеть имя рядом с заказом, нам нужно «склеить» таблицы по этому общему полю.

Существует несколько типов JOIN, но для QA критически важно понимать три:

Синтаксис выглядит так:

Здесь u и o — это алиасы (псевдонимы), которые мы даем таблицам, чтобы запрос был короче и понятнее.

Агрегатные функции и группировка

Иногда нам не нужны детали каждой транзакции, нам нужна статистика. Для этого в SQL есть функции:

Но агрегаты редко используются сами по себе. Обычно мы хотим увидеть сумму в разрезе чего-либо (например, по каждому пользователю). Для этого используется GROUP BY.

Важное правило: если вы используете агрегатную функцию (например, SUM) вместе с обычным полем (например, name), это поле обязательно должно быть указано в GROUP BY.

Пошаговый разбор: Анализ активности пользователей

Допустим, нам нужно найти «VIP-клиентов», которые совершили более 5 заказов.

Шаг 1: Объединяем таблицы. Нам нужны имена из Users и количество записей из Orders. FROM Users u LEFT JOIN Orders o ON u.id = o.user_id

Шаг 2: Группируем по имени. Чтобы посчитать заказы для каждого человека отдельно: GROUP BY u.name

Шаг 3: Считаем количество. Добавляем COUNT(o.id) в блок SELECT.

Шаг 4: Фильтруем результат агрегации. Внимание! Оператор WHERE нельзя использовать для фильтрации результатов COUNT или SUM. Для этого существует оператор HAVING.

Итоговый запрос:

Разница между WHERE и HAVING

Это один из самых «заковыристых» вопросов на интервью.

Если вы перепутаете их местами, запрос выдаст ошибку. Запомните: WHERE работает с исходными данными, HAVING — с агрегатами.

Практические советы для тестировщика

При тестировании отчетов или аналитических панелей в приложении всегда проверяйте граничные случаи через SQL:

Владение JOIN и агрегацией переводит вас из категории «человек, который нажимает кнопки» в категорию «технический специалист», способный проверить целостность данных на глубоком уровне.