Всё, что спрашивают у начинающего тестировщика: виды и уровни тестирования, техники тест-дизайна, баг-репорты, клиент-серверная архитектура, HTTP, DevTools, тестирование API и SQL.
API тестируют без интерфейса: отправляем запросы (Postman, curl) и проверяем статус, тело ответа, схему данных, побочные эффекты и обработку ошибок.
Идентификация — кто вы (логин), аутентификация — докажите это (пароль, код), авторизация — что вам разрешено делать.
Методы по доступу к коду: чёрный ящик — без знания внутреннего устройства, белый — с доступом к коду, серый — частичное знание (база, логи, API).
Ошибки чаще всего на границах классов, поэтому проверяем саму границу и значения рядом с ней.
Типичный путь: Новый → Открыт → В работе → Исправлен → Проверка (ретест) → Закрыт; при неудачном ретесте — Переоткрыт.
Баг-репорт — описание дефекта, по которому разработчик воспроизведёт его без вопросов: заголовок, шаги, фактический и ожидаемый результат, окружение, вложения.
Браузер находит IP через DNS, устанавливает соединение (TCP, TLS для HTTPS), отправляет HTTP-запрос, сервер возвращает ответ, браузер отрисовывает страницу и догружает ресурсы.
Cookies — небольшие данные, которые браузер отправляет на сервер с каждым запросом (сессия, настройки); localStorage и sessionStorage — хранилища, доступные только скриптам…
Таблица решений описывает все комбинации условий и результат для каждой — так не теряются сочетания в сложной бизнес-логике.
DevTools помогают локализовать баг: Network — запросы и ответы, Console — ошибки JavaScript, Application — cookies и хранилища, Elements — вёрстка.
Делим входные данные на группы, которые система обрабатывает одинаково, и берём по одному значению из каждой.
Исследовательское тестирование — одновременное изучение продукта, придумывание и выполнение проверок, без заранее написанных тест-кейсов.
Функциональное — что система делает (функции по требованиям), нефункциональное — как она это делает (скорость, удобство, надёжность, безопасность).
GET — получить данные, POST — создать или отправить, PUT — заменить целиком, PATCH — изменить частично, DELETE — удалить.
Пять групп: 1xx информационные, 2xx успех, 3xx перенаправление, 4xx ошибка клиента, 5xx ошибка сервера.
Pairwise — подбор набора тестов, в котором каждая пара значений любых двух параметров встречается хотя бы один раз.
Позитивное — проверка с корректными данными и ожидаемыми действиями; негативное — с некорректными, чтобы убедиться, что система правильно обрабатывает ошибку.
Это вложенные уровни: QA — обеспечение качества процессов, QC — контроль качества продукта, тестирование — конкретные проверки.
Требования проверяют до разработки: полнота, однозначность, непротиворечивость, проверяемость, выполнимость — каждая найденная дыра дешевле бага в коде.
Тестирование идёт на всех этапах разработки, а не только в конце: от проверки требований до приёмки и мониторинга после релиза.
Серьёзность (severity) — насколько дефект влияет на систему; приоритет (priority) — насколько срочно его исправлять для бизнеса.
Smoke — быстрая проверка, что сборка вообще работает; sanity — узкая проверка конкретного исправления или функции; регресс — что изменения не сломали старое.
SQL нужен, чтобы проверять данные в базе после действий, готовить тестовые данные и искать причину бага.
Если у объекта есть статусы (заказ, заявка, аккаунт), рисуем состояния и переходы между ними и проверяем каждый переход — и недопустимые тоже.
Тест-кейс — подробная проверка: предусловия, шаги, тестовые данные, ожидаемый результат; чек-лист — список того, что проверить, без детальных шагов.
Четыре уровня: модульное (функция, класс) → интеграционное (взаимодействие частей) → системное (продукт целиком) → приёмочное (готов ли для пользователя).
Начните с вопросов о требованиях: для кого предмет и как его используют — затем структурируйте проверки по видам.
Тест-план отвечает на вопросы что, как, кем, когда и до каких пор тестируем на проекте или релизе.
Семь классических принципов: тестирование показывает наличие дефектов, исчерпывающее невозможно, раннее — дешевле, дефекты скапливаются, парадокс пестицида, тестирование зависит…
Тестирование — проверка, что продукт работает как ожидается и решает задачу пользователя; цель — дать информацию о качестве и снизить риски.
Автоматизируют повторяющиеся, стабильные и критичные проверки — регресс, smoke, API; вручную — новое, меняющееся и то, где важен человеческий взгляд.
sotto слышит вопрос и сразу показывает короткий ответ. Оставьте контакт — пришлём доступ и промокод.
sotto