Тестирование программного обеспечения — итоги
Проверка в БД — SQL для тестировщика, Основы БД, транзакции, PostgreSQL. Карта — о разделе.
Зачем эта страница. Вы прошли (или пролистали) раздел — здесь сжатая карта — что запомнить, какие статьи связаны, что проверить перед собесом. Для глубокой самопроверки откройте чек-лист из 50 вопросов.
FAQ — Часто задаваемые вопросы
Типичные сбои и путаницы у начинающих QA и разработчиков, которые впервые отвечают за качество. Здесь — практика и куда копать в разделе; формулировки для зачёта — в чек-листе.
Вопрос. Вакансия "QA" — ждут только ручные проверки или обязательно писать код?
Ответ. Зависит от команды: уточните ожидания по автоматизации, стек (Python/Java/JS) и долю регресса в CI. Ручной QA без кода возможен; SDET — наоборот. Подробнее здесь — основы тестирования, автоматизация.
Вопрос. Баг закрыли как "исправлен", на проде снова воспроизводится.
Ответ. Нужны retest на той же сборке/ветке и регресс по связанной области; проверьте, что фикс попал в релизную ветку и конфиг среды совпадает. Подробнее здесь — классификация видов, документация тестировщика.
Вопрос. Автотест то зелёный, то красный без изменений кода — с чего начать?
Ответ. Это флейк: уберите sleep, добавьте явные ожидания, стабилизируйте тестовые данные и среду. Не "перезапускайте пока не пройдёт" в CI. Подробнее здесь — E2E и UI, практикум 1013.
Вопрос. Разработчик говорит "у меня работает" — баг не принимают.
Ответ. Соберите воспроизводимый пакет: шаги, скрин/видео, версия сборки, браузер, учётка, время, логи Network/консоль. Сверьте среду (dev/stage). Подробнее здесь — документация, ручное веб-тестирование.
Вопрос. Тестового стенда нет — проверяем на проде "осторожно".
Ответ. Это высокий риск: договоритесь о минимальном stage, маскированных данных и окне проверок. На проде — только smoke по согласованию, без разрушительных сценариев. Подробнее здесь — жизненный цикл QA, DevOps и CI.
Вопрос. Stage "зелёный", прод падает после выкладки.
Ответ. Сравните конфиг, секреты, объём данных, интеграции и фичефлаги. Добавьте smoke после деплоя и мониторинг ошибок. Подробнее здесь — классификация, порядок этапов.
Вопрос. Баг-репорт вернули с формулировкой "не воспроизводится".
Ответ. Уточните окружение, предусловия (кэш, роль, данные), приложите HAR или curl. Один шаг — одно действие; ожидаемый результат — конкретный. Подробнее здесь — документация тестировщика.
Вопрос. В трекере путают приоритет и серьёзность — что ставить новичку?
Ответ. Серьёзность — ущерб (деньги, данные, блокировка); приоритет — когда чинить с учётом релиза. Критичный по бизнесу баг может иметь разный приоритет на hotfix и на бэклоге. Подробнее здесь — основы, классификация.
Вопрос. Требований нет — "просто потыкайте".
Ответ. Составьте риск-ориентированный чек-лист по ролям, платежам, авторизации, границам ввода; зафиксируйте найденные пробелы как вопросы к аналитику. Подробнее здесь — тест-дизайн, аналитика.
Вопрос. API отвечает 200 OK, но сумма заказа в базе неверная.
Ответ. HTTP-статус не равен корректности бизнес-логики: проверяйте тело ответа и данные в БД. Подробнее здесь — тестирование API, SQL для тестировщика.
Вопрос. Нашёл расхождение в БД — кто должен править, QA или разработчик?
Ответ. QA фиксирует дефект с доказательством (запрос, скрин, id записи); правка данных на проде — по процессу с DBA/разработкой, не "вручную в pgAdmin" без согласования. Подробнее здесь — SQL для тестировщика.
Вопрос. E2E в CI идут час — релиз ждут.
Ответ. Сократите E2E до критичного smoke, ускорьте API и unit в пайплайне, параллелизуйте стабильные сьюты. Пирамида — не лозунг, а экономика времени. Подробнее здесь — автоматизация, карта уровней.
Вопрос. Всё замокали — в проде интеграция всё равно падает.
Ответ. Моки нужны на нижних уровнях; для релиза оставьте интеграционные проверки на реальных контрактах (хотя бы stage). Подробнее здесь — тестовые дублёры, интеграционное.
Вопрос. Заказчик хочет UAT до внутреннего регресса.
Ответ. Риск — показать сырой продукт и потерять доверие. Минимум: smoke + критичные сценарии внутри команды, затем UAT по согласованным сценариям. Подробнее здесь — классификация, жизненный цикл.
Вопрос. После каждого деплоя что гонять в первую очередь?
Ответ. Короткий smoke: вход, главный сценарий, оплата/отчёт — что критично для бизнеса; затем таргетный регресс по области изменения. Подробнее здесь — классификация, порядок этапов.
Вопрос. Безопасность проверяют за день до релиза сканером "для галочки".
Ответ. Базовые проверки (инъекции, XSS, права) закладывайте в ранние итерации; сканер — дополнение, не замена сценариям. Подробнее здесь — тестирование безопасности, основы ИБ.
Вопрос. Нагрузочный тест запустили с ноутбука на прод — сайт лёг.
Ответ. Нагрузка только на выделенном стенде с лимитами и согласованием; с продом так делать нельзя. Подробнее здесь — нагрузочное, практикум 1014.
Вопрос. Мобильное приложение и веб — разные команды, баги "перекидывают".
Ответ. Зафиксируйте единый контракт API и матрицу совместимости версий; баг привязывайте к слою (клиент/бэкенд) с логами. Подробнее здесь — мобильное тестирование, API.
Вопрос. ChatGPT выдал тест-кейсы — можно сразу в TestRail?
Ответ. Только после review человеком: границы, отрицательные сценарии, актуальность требований. Иначе получите красивый, но пустой регресс. Подробнее здесь — нейрослоп и QA, тест-дизайн, промпты с критериями готовности.
Вопрос. Коллекция Postman у коллеги работает, у меня 401.
Ответ. Сверьте токен, окружение, base URL и заголовки; часто забывают переменные или истёкший refresh. Подробнее здесь — тестирование API, curl в терминале, curl / fetch — примеры.
Вопрос. С чего начать автоматизацию — Selenium или Playwright?
Ответ. Для нового веб-проекта чаще смотрят на Playwright (стабильность, трассировки); Selenium — если так уже принято в компании. Сначала API и unit, UI — тонкий слой. Подробнее здесь — Playwright, Selenium, каталог инструментов.
Вопрос. Проверяю только "счастливый путь" — заказчик находит краевые случаи.
Ответ. Добавьте границы, пустые поля, отмену, повтор, гонки по техникам эквивалентных классов и таблиц решений. Подробнее здесь — тест-дизайн.
Вопрос. Доступность (a11y) вспомнили после релиза по жалобе пользователя.
Ответ. Базовые проверки (контраст, фокус, клавиатура, alt) включайте в чек-лист UI раньше. Подробнее здесь — ручное веб, маршрут веб-QA.
Вопрос. В тестовой базе лежат реальные паспорта и телефоны клиентов.
Ответ. Это нарушение закона о ПДн: нужны синтетические или обезличенные данные. Эскалируйте безопасности, не копируйте прод "как есть". Подробнее здесь — основы ИБ.
Вопрос. Триаж дефектов превращается в спор "чей баг" два часа.
Ответ. Заранее: владелец компонента, критерии Blocker/Critical, лимит времени на обсуждение, эскалация к тимлиду. Без воспроизведения — в статус "нужна информация". Подробнее здесь — основы, документация.
Вопрос. Руководство требует "100 % покрытия кода" к дате.
Ответ. Покрытие — индикатор, не гарантия: можно набрать процент бессмысленными тестами. Лучше риск-ориентированный набор и мутационная выборка на критичном модуле. Подробнее здесь — покрытие кода, мутационное.
Вопрос. Хочу из ручного QA в автоматизацию — с чего учиться в этом разделе?
Ответ. Маршрут: основы → API → Подготовка среды и создание первого теста (pytest) → пирамида. Параллельно Git и HTTP из Дополнительные модули для тестировщика.
Вопрос. На собеседовании спрашивают "верификацию бага" — что имеют в виду?
Ответ. Часто имеют в виду подтверждение исправления (retest), а не термин verification из ISTQB. Уточните контекст; путаница с "верификацией продукта" — частая ловушка. Подробнее здесь — основы, классификация.
Вопрос. Регресс на 500 кейсов не успеваем — что резать?
Ответ. Режьте по риску изменения: затронутые модули, история дефектов, критичность для денег и данных; автоматизируйте стабильное ядро. Подробнее здесь — классификация, автоматизация.
Вопрос. Unit-тесты пишет только QA — разработчики отказываются.
Ответ. Unit — зона разработчика; QA дополняет интеграцией, E2E и приёмкой. Договоритесь о Definition of Done с unit на новый код. Подробнее здесь — юнит-тестирование, карта уровней.
Вопрос. Как стать тестировщиком ПО с нуля без опыта в IT?
Ответ. Старт: основы QA, ручное веб, баг-репорты, HTTP/API, затем SQL и автоматизация (pytest). Маршрут в разделе — о разделе, шаги 1–9. Карьера — IT-профессии.
Вопрос. Чем QA инженер отличается от тестировщика?
Ответ. QA — процессы качества на всём цикле; тестировщик — исполнение проверок. На вакансиях названия смешивают — смотрите обязанности в тексте. Подробнее здесь — основы тестирования.
Вопрос. Что такое регрессионное тестирование?
Ответ. Проверка, что после изменений старое не сломалось; делают выборочно по риску или полным набором перед релизом. Подробнее здесь — классификация видов, автоматизация.
Вопрос. Smoke test (дымовое тестирование) — что проверяют?
Ответ. Короткий прогон критичных сценариев после сборки или деплоя: "система вообще жива". Не заменяет полный регресс. Подробнее здесь — классификация.
Вопрос. Ручное и автоматизированное тестирование — что выбрать?
Ответ. Ручное — исследование, UX, новые фичи; автоматизация — стабильный повторяемый регресс (API, unit, часть UI). Обычно нужны оба. Подробнее здесь — автоматизация, ручное веб.
Вопрос. Как написать баг-репорт — какие поля обязательны?
Ответ. Заголовок, шаги, фактический и ожидаемый результат, среда (ОС, браузер, сборка), вложения, серьёзность. Без воспроизведения баг не примут. Подробнее здесь — документация тестировщика.
Вопрос. Как тестировать REST API через Postman?
Ответ. Соберите коллекцию запросов, окружения (URL, токен), проверки статуса и JSON в Tests; для CI — экспорт в Newman. Подробнее здесь — тестирование API.
Вопрос. pytest для автотестов — с чего начать новичку?
Ответ. Установите Python, venv, pytest, напишите первый тест на функцию, затем API. Пошагово — практикум 1011, юнит-тестирование.
Вопрос. Selenium или Playwright — что лучше в 2025–2026?
Ответ. Для новых проектов часто берут Playwright (скорость, автоожидания, trace); Selenium — если уже есть большая база. Подробнее здесь — Playwright, Selenium.
Вопрос. E2E тестирование — что это простыми словами?
Ответ. Сквозной сценарий как у пользователя через UI и реальные интеграции (логин → заказ → оплата). Дорого в поддержке — держите мало кейсов. Подробнее здесь — E2E и системное, практикум 1013.
Вопрос. Интеграционное тестирование — чем отличается от unit?
Ответ. Unit изолирует модуль (моки); integration проверяет стык модулей, БД, API, очередей. Подробнее здесь — юнит, интеграционное, карта уровней.
Вопрос. Тест-кейс и чек-лист — в чём разница?
Ответ. Тест-кейс — детальные шаги и ожидания; чек-лист — список пунктов без глубины, быстрее для обзора. Подробнее здесь — документация.
Вопрос. Пирамида тестирования (test pyramid) — как понять?
Ответ. Много быстрых unit внизу, меньше integration/API, мало E2E сверху — баланс скорости и уверенности. Подробнее здесь — автоматизация.
Вопрос. Нагрузочное тестирование — JMeter или k6?
Ответ. Оба подходят; важнее метрики (RPS, latency, ошибки) и стенд, не имя инструмента. В разделе — обзор и практика. Подробнее здесь — нагрузочное, Проверка надежности под нагрузкой.
Вопрос. Зачем тестировщику SQL и запросы к базе?
Ответ. Проверить факт данных после API/UI, подготовить фикстуры, найти расхождения. Подробнее здесь — SQL для тестировщика.
Вопрос. ISTQB сертификат — нужен ли для работы?
Ответ. Не обязателен: даёт общий словарь, но практика и портфолио важнее. Термины раздела согласованы с основами ISTQB без привязки к экзамену. Подробнее здесь — основы, классификация.
Вопрос. Как начать тестировать веб-приложение в браузере?
Ответ. DevTools (Network, Console), чек-лист UI, сессии, формы, адаптив. Маршрут — основы веб для QA → ручное веб.
Вопрос. Верификация и валидация в тестировании — в чём разница?
Ответ. Верификация — "сделали по спецификации" (review, unit); валидация — "то ли для пользователя" (UAT, прод-сценарии). Подробнее здесь — основы.
Вопрос. UAT (приёмочное тестирование) — кто проводит?
Ответ. Заказчик или бизнес по согласованным сценариям; QA готовит среду, данные и фиксирует дефекты. Подробнее здесь — классификация, жизненный цикл.
Вопрос. Code coverage (покрытие кода) — сколько процентов нормально?
Ответ. Универсального % нет: смотрите критичные модули и качество тестов, не гонитесь за 100 % ради отчёта. Подробнее здесь — покрытие кода.
Вопрос. TDD (разработка через тесты) — это про QA?
Ответ. TDD — практика разработчика (Red-Green-Refactor); QA использует результат в регрессе. Подробнее здесь — карта уровней и TDD, лабораторный кейс TDD.
Вопрос. Метод граничных значений в тест-дизайне — пример?
Ответ. Для поля "возраст 18–65" проверяют 17, 18, 65, 66 — ошибки часто на границах диапазона. Подробнее здесь — тест-дизайн.
Вопрос. Mock, stub и fake — как не перепутать?
Ответ. Все — замены зависимостей; stub отдаёт заготовленный ответ, mock проверяет вызовы, fake — упрощённая рабочая реализация. Подробнее здесь — тестовые дублёры.
Вопрос. Тестирование безопасности — SQL injection и XSS с чего начать?
Ответ. Базовые payloads в формах и API, проверка экранирования, права доступа; для глубины — OWASP Top 10. Подробнее здесь — тестирование безопасности.
Вопрос. SDET — кто это и чем отличается от manual QA?
Ответ. SDET (Software Development Engineer in Test) пишет автотесты и инфраструктуру тестов, ближе к разработке. Manual QA — ручные сценарии и документы. Подробнее здесь — автоматизация, каталог инструментов.
Вопрос. Тестирование в Agile / Scrum — когда QA входит в спринт?
Ответ. С этапа уточнения требований, тест-дизайн параллельно разработке, регресс каждый спринт, не "только в последний день". Подробнее здесь — жизненный цикл QA, порядок этапов.
Главная мысль раздела
Качество — это система: требования → тест-дизайн → проверки на разных уровнях → артефакты → обратная связь. Тестирование даёт информацию о рисках; решение "выпускать или нет" принимает команда на основе этой информации и бизнес-контекста.
Термины, которые должны не путаться
| Термин | Смысл в одной фразе | Где подробнее |
|---|---|---|
| Ошибка (mistake) | Человек ошибся при проектировании или коде | Основы, Классификация |
| Дефект (defect) | Несоответствие в артефакте (код, ТЗ) | там же |
| Сбой (failure) | Пользователь увидел поломку в рантайме | там же |
| Верификация | "Собрали ли правильно по ТЗ?" (в т.ч. review) | Основы |
| Валидация | "То ли сделали для пользователя?" (запуск, UAT) | Основы |
| Retest / confirmation | Перепроверили конкретный исправленный баг | Классификация |
| Регрессия | Старое не сломали после изменений | Классификация, Автоматизация |
| Smoke / sanity | Короткий прогон после сборки / точечного фикса | Классификация |
| Стаб / мок / фейк | Способы подменить зависимости в тестах | Объекты |
Уровни проверок
Снизу вверх — больше скорости и изоляции, сверху — ближе к пользователю и дороже в поддержке:
- Unit — функция/класс, моки и стабы, миллисекунды. Юнит-тестирование, практика Подготовка среды и создание первого теста.
- Integration — стык модулей, API, БД, очереди. Интеграционное.
- UI — проверка интерфейса и его поведения (не всегда сквозной бизнес-путь). E2E и системное, Ручное веб-тестирование.
- System — продукт целиком по спецификации (не обязательно через UI). E2E и системное.
- E2E — сквозной сценарий "как в жизни". E2E, практика Проверка пользовательского сценария.
- UAT / приёмка — заказчик и бизнес. Классификация.
Пирамида — много unit, меньше integration/API, мало E2E — см. Автоматизация.
Процесс и документы
| Тема | Статья |
|---|---|
| Фазы QA в релизе (план → отчёт) | Жизненный цикл |
| В каком порядке гонять уровни тестов | Последовательность этапов |
| План, кейс, чек-лист, баг-репорт | Документация |
| Эквивалентные классы, границы, таблицы | Тест-дизайн |
| Ручная проверка веба | Ручное тестирование веб-приложений |
| API без браузера | Тестирование API |
| Данные в БД | SQL для тестировщика |
Автоматизация и инструменты
- Когда автоматизировать — повторяемость, стабильность, критичность; не UX "на глаз". Автоматизация.
- Как не путать уровни и практики — отдельная карта — Unit, Integration, UI, E2E, TDD и BDD.
- Справочник инструментов — по задаче, не подряд: каталог.
- Selenium / Playwright — отдельные глубокие статьи: Selenium, Playwright.
- Нагрузка — Нагрузочное и стресс-тестирование производительности, практика Проверка надежности под нагрузкой.
- Безопасность — Тестирование информационной безопасности.
Настройка пайплайнов и запуск тестов в CI — в DevOps, не дублируем здесь.
Типичные ошибки новичка
- Путают QA (процессы) и автотесты (один из инструментов).
- Называют перепроверку бага "верификацией" — правильнее retest (Классификация видов тестирования vs Основы тестирования программного обеспечения).
- Пишут UI-автотесты до API и unit — долгий и хрупкий регресс.
- Используют
sleep()вместо явных ожиданий — флейки (End-to-End и системное тестирование, Проверка пользовательского сценария). - Считают 100 % покрытия кода гарантией качества (Покрытие кода и метрики полноты тестирования).
Рекомендуемая литература
- Г. Майерс — Искусство тестирования программ — классика про мышление тестировщика (сложнее для старта, полезно после основ).
- В. Хориков — Принципы юнит-тестирования — когда перейдёте к юнит-тестам и практикуму 1011.
Сводный список книг по IT — в каталоге документации.
Куда идти дальше
| Цель | Действие |
|---|---|
| Закрепить теорию | Чек-лист самопроверки — 50 вопросов |
| Практика кода | Python Подготовка среды и создание первого теста–Проверка надежности под нагрузкой · Java Практикум Java — JUnit и REST Assured · JS Практикум JavaScript — Playwright и Jest |
| Бонус-модули | Git, HTTP, алгоритмы, soft skills, английский |
| Карьера и роли | Карьера в IT |
| HTTP и интеграции глубже | Основы интеграции |
Полный маршрут по разделу — на странице о разделе.
Навигация по разделу "Тестирование"
- Маршрут: О разделе · Резюме раздела · Карта уровней и практик (Unit / Integration / UI / E2E, TDD, BDD)
- Теория и процесс: Основы · Классификация · Жизненный цикл · Порядок этапов · Артефакты качества
- Уровни проверок: Unit · Integration · E2E, системное и UI · API · Тестовые дублёры · Покрытие кода · White-box · Мутационное тестирование
- Практика QA: Документация · Тест-дизайн · Ручное веб · SQL
- Автоматизация: Стратегия и пирамида · Каталог инструментов · Selenium · Playwright
- Практикум и углубление: Подготовка среды и создание первого теста · Проверка взаимодействия компонентов · Проверка пользовательского сценария · Проверка надежности под нагрузкой · Мобильное · Нагрузка · Безопасность · Самопроверка · Доп. материалы курса · Инструменты с низким кодом для тестирования · Тестирование нейроморфных систем