Тестовое задание для QA — это проверка умения мыслить как тестировщик, а не только нажимать кнопки. Разбираем, что дают, как подходить и на что обращают внимание.
Типичные форматы тестовых заданий QA
Написать тест-кейсы для функциональности. «Напишите тест-кейсы для формы регистрации», «для поиска на сайте».
Найти баги на тестовом стенде. Дают ссылку на приложение: «протестируйте и задокументируйте найденные дефекты».
Тестирование API. Дают спецификацию API или коллекцию Postman: «найдите баги».
SQL-задачи. «Напишите запрос для получения...» — проверяют базовый SQL.
Задачи на тест-дизайн. «Используя технику классов эквивалентности, покройте поле "возраст"».
Разбор кейса 1: тест-кейсы для формы регистрации
Условие: «Напишите тест-кейсы для формы регистрации с полями: имя, email, пароль, кнопка "Зарегистрироваться"».
Типичная ошибка: написать 3–4 позитивных теста и забыть про негативные.
Правильный подход — покрыть все классы эквивалентности:
Поле email:
- валидный email (позитивный)
- без символа `@` → ошибка
- без домена (`user@`) → ошибка
- пустое поле → ошибка
- пробел в начале/конце
- уже зарегистрированный email → ошибка «уже существует»
Поле пароль:
- минимальная длина (граничное значение: N-1 символов → ошибка, N → успех)
- максимальная длина
- без спецсимволов, если требуются
- пробел как единственный символ
Кнопка / поведение формы:
- отправка при незаполненных обязательных полях
- двойное нажатие кнопки (защита от дублирования)
- состояние кнопки во время загрузки
- сообщение об успехе
Формат тест-кейса:
| # | Название | Предусловие | Шаги | Ожидаемый результат |
|---|---|---|---|---|
| TC-01 | Успешная регистрация | Пользователь не зарегистрирован | 1. Открыть форму 2. Ввести валидные данные 3. Нажать "Зарегистрироваться" | Пользователь создан, редирект на главную |
Разбор кейса 2: баг-репорты по итогам тестирования
Что проверяют: умеете ли вы описывать баги так, чтобы разработчик мог воспроизвести и исправить без лишних вопросов.
Структура хорошего баг-репорта:
- Заголовок: `[Регистрация] Email с пробелом принимается как валидный`
- Среда: Chrome 120, Windows 11, staging.example.com
- Шаги воспроизведения:
1. Открыть форму регистрации
2. Ввести `user @example.com` (с пробелом) в поле Email
3. Нажать «Зарегистрироваться»
- Ожидаемый результат: Ошибка «Некорректный email»
- Фактический результат: Регистрация прошла успешно
- Severity: Major
- Приоритет: High
- Скриншот: [приложен]
Типичные ошибки в баг-репортах:
- расплывчатое название: «форма не работает»
- шаги воспроизведения с позиции разработчика вместо пользователя
- нет ожидаемого результата
- нет скриншота/лога
Разбор кейса 3: тестирование API
Что дают: Swagger/OpenAPI спецификацию или коллекцию Postman.
Что проверять для каждого эндпоинта:
1. Позитивный сценарий: корректные данные → ожидаемый ответ, правильный статус-код
2. Обязательные поля: убрать поле → 400 с понятным сообщением
3. Граничные значения: строка максимальной длины, минимальная и нулевая
4. Неверные типы: число вместо строки, строка вместо числа
5. Авторизация: запрос без токена → 401, с чужим токеном → 403
6. Несуществующий ресурс: GET /users/99999 → 404
Что часто ломается: сервер возвращает 200 на невалидные данные, или 500 вместо 400, или пустой ответ без сообщения об ошибке.
Что проверяют в тестовом задании QA
- Полнота покрытия: не забыты ли граничные значения, негативные сценарии
- Качество описания: понятно ли воспроизвести тест/баг без уточнений
- Приоритизация: умеете ли отделять критические баги от косметических
- SQL (если требуется): базовый SELECT
FAQ
Нужен ли автоматизированный код в тестовом задании QA?
Для ручного QA — нет. Если вакансия подразумевает автоматизацию — да.
Сколько тест-кейсов достаточно?
Столько, сколько нужно для разумного покрытия, без дублирования. 10–30 для одной функции — норма.
Что делать, если нашёл слишком мало багов?
Проверьте: граничные значения, безопасность (XSS, SQL-инъекции), поведение при потере сети, работу с разными браузерами.
---