Основы тестирования
Тестирование начинается не с инструмента, а с понятий. Прежде чем открыть Selenium или Postman, тестировщик должен твёрдо различать процесс и продукт, верификацию и валидацию, severity и priority — иначе он будет чинить не то и останавливаться не там. Этот раздел собирает базовый словарь, на котором держится всё остальное — от отбора тест-кейсов до формулировки баг-репорта.
Здесь же спрятаны главные ловушки новичка. Тестирование не доказывает отсутствие багов — оно снижает риск. Цепочка error → defect → failure имеет одно направление и не переворачивается. Smoke — это широкая и мелкая проверка, а не глубокий прогон. Каждую такую ловушку мы называем прямо в соответствующем слое. Полная карта — ниже.
Карта темы
- Что такое тестирование — зачем оно нужно и почему цель в том, чтобы снизить риск, а не доказать отсутствие багов.
- QA, QC и тестирование — процесс против продукта против техники и почему это не синонимы.
- Верификация и валидация — «правильно ли строим продукт» против «тот ли продукт строим».
- Error, defect, failure — причинно-следственная цепочка от ошибки человека до сбоя в рантайме.
- Причины багов — почему корень большинства дефектов в требованиях и коммуникации, а не в опечатках.
- Семь принципов ISTQB — фундаментальные истины отрасли: скопление дефектов, парадокс пестицида, зависимость от контекста.
- Этапы жизненного цикла ПО — где в SDLC живёт тестирование и почему оно охватывает весь цикл.
- SDLC и STLC — вложенный цикл тестирования и его параллельность разработке.
- Качество требований — что делает требование тестируемым и почему непроверяемое требование дефектно.
- Уровни тестирования — unit, integration, system, acceptance и их охват.
- Виды тестирования — функциональное против нефункционального, а также smoke, sanity и regression.
- Black-, white- и grey-box — объём знания о внутренностях как ось классификации.
- Позитивное и негативное тестирование — счастливый путь против устойчивости к невалидному вводу.
- Отбор smoke и regression — критичность против анализа влияния при выборе кейсов.
- Баг-репорт — обязательные поля и почему пара ожидаемое-против-фактического — его сердце.
- Severity и priority — технический ущерб против бизнес-срочности и их независимость.
- Жизненный цикл дефекта — состояния от New до Closed и петля Reopened.
- Критерии приостановки и выхода — временная пауза против финального завершения цикла.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Считать, что тестирование доказывает отсутствие багов | Ложная уверенность в релизе — тестирование лишь показывает наличие дефектов и снижает риск |
| Называть тестирование надмножеством QA | Перевёрнутая иерархия: тестирование — техника внутри QC, а QC — часть QA |
| Переворачивать цепочку error → defect → failure | Неверный поиск причины: причина всегда человек, следствие — сбой в рантайме |
| Приравнивать severity к priority | Неверная приоритизация правок; опечатка в логотипе бывает low severity, но high priority |
| Путать smoke (широкий, мелкий) с regression (глубокий) | Либо пропущенная поломка, либо трата времени на полный прогон ради хотфикса |
| Считать тестирование поздней фазой после разработки | Дорогие дефекты, найденные в проде вместо ревью требований |
| Писать требование, которое нельзя проверить | Нет теста, подтверждающего выполнение — требование дефектно по сути |
Значение для собеседований
Основы спрашивают на любом junior-собеседовании, потому что они мгновенно отделяют человека, читавшего теорию, от того, кто путает термины. Интервьюер проверяет не зубрёжку, а понимание отношений: что во что вложено, что чему причина, что от чего независимо.
Что обычно проверяют:
- Цель тестирования — снижение риска и информирование, а не доказательство отсутствия багов.
- Различение пар: QA/QC, верификация/валидация, severity/priority, smoke/regression.
- Направление цепочки error → defect → failure и место тестирования в SDLC.
- Состав баг-репорта и жизненный цикл дефекта от New до Closed.
Типичный неверный ответ: «тестирование — это когда прокликиваешь приложение в конце, чтобы убедиться, что багов нет». Здесь сразу три ошибки — тестирование не только динамическое и не только в конце, оно не доказывает отсутствие багов, и клики — лишь малая его часть.