База для QA
К списку уроков
Блок 3 · Теория тестирования

Урок 8. Принципы тестирования и STLC

7 принципов ISTQB и жизненный цикл тестирования

Темы урока

7 принципов ISTQB, STLC, отличие SDLC и STLC, Shift Left / Shift Right, когда начинается/заканчивается тестирование

Видео урока

Пройти тест по уроку

Конспект урока

Главное за урок

QA не доказывает, что багов нет — он снижает риск. Тестирование показывает наличие дефектов, а не их отсутствие. Если мы нашли баг, мы доказали проблему. Если не нашли — это не гарантия идеальной работы.

STLC — это карта работы QA, а не бюрократия. Без него тестирование превращается в хаотичное «покликал и вроде норм». STLC помогает структурировать: что понять, спланировать, подготовить, проверить и закрыть.

Качество начинается раньше кода и продолжается после релиза. Shift Left подключает QA к требованиям и дизайну. Shift Right смотрит на метрики и жалобы пользователей уже после выхода.

7 принципов тестирования ISTQB

1. Тестирование показывает наличие дефектов

Нашли баг — доказали, что проблема есть. Не нашли — не доказали, что продукт идеально работает. QA выдаёт снижение риска, а не «сертификат ошибок нет».

2. Исчерпывающее тестирование невозможно

Даже в небольшом магазине есть товары, категории, промокоды, количества, доставка, checkout и popup. Все комбинации действий пользователя — огромное дерево. QA выбирает проверки по риску, частоте и цене ошибки.

3. Раннее тестирование экономит деньги

Ошибка в требовании стоит дешевле, чем ошибка после релиза. Вопрос «можно ли применять промокод дважды?» лучше задать до разработки, чем фиксить после. Это принцип Shift Left.

4. Дефекты собираются в кластеры

Если в корзине уже нашли несколько багов — там может быть ещё больше. Сложные зоны ломаются чаще: расчёты, состояния, интеграции, граничные условия. QA усиливает проверку там, где уже видно напряжение.

5. Парадокс пестицида

Один и тот же набор тестов со временем перестаёт находить новые баги. Если проверять только «добавить товар и оформить заказ», можно пропустить новые риски. Тесты нужно пересматривать после изменений продукта, багов и требований.

6. Тестирование зависит от контекста

Банковский перевод, игра и учебный магазин тестируются с разной глубиной. Хороший QA не копирует чужой чек-лист вслепую, а адаптирует подход к продукту.

7. Отсутствие найденных багов ≠ полезный продукт

Можно сделать форму без технических ошибок, но неудобную и непонятную пользователю. Если требования неверные — идеально реализованная фича всё равно не решает задачу бизнеса.

SDLC vs STLC: в чём разница

SDLC STLC
Что описывает Жизненный цикл продукта от идеи до поддержки Жизненный цикл тестирования конкретной фичи
Кто ведёт Вся команда QA
Начало Идея / требования Анализ требований параллельно с разработкой
Конец Вывод из эксплуатации Закрытие цикла тестирования (exit criteria)

Они идут рядом: QA встроен в разработку, а не появляется только в конце.

Этапы STLC

1. Анализ требований

QA читает требования и ищет не только «что проверить», но и неясности. Хороший вопрос на этапе требований экономит часы тестирования и переделок.

Пример: сразу спрашиваем — как работает промокод, что делать с пустой корзиной, когда показывать popup?

2. Планирование тестирования

QA решает, какие зоны входят в проверку, какие риски самые важные и сколько времени есть. План нужен не для бюрократии, а чтобы команда понимала объём и ожидания.

3. Дизайн тестов

Из требования «промокод даёт скидку 10%» получаются позитивные, негативные и граничные сценарии. Проверяем: валидный код, неверный код, пустое поле, повторное применение, заказ после скидки.

4. Подготовка окружения

Нужны стабильная версия продукта, тестовые данные, доступы и способ сбросить состояние. Если окружение нестабильно — QA тратит время на борьбу с шумом, а не на проверку продукта.

5. Выполнение тестов

QA сравнивает фактический результат с ожидаемым и фиксирует отклонения. Даже ручная проверка должна оставлять след: что проверено, что найдено, что осталось рискованным.

6. Закрытие тестирования

В конце QA сообщает: что проверено, какие баги открыты, что заблокировано и какие риски остались. Команда принимает решение о релизе не по ощущению «вроде норм», а по понятной картине качества.

Exit criteria — критерии, по которым можно сказать «тестирование завершено»: X% тест-кейсов выполнены, критичных багов нет, все P1 баги закрыты.

Shift Left и Shift Right

[Идея] → [Требования] → [Дизайн] → [Разработка] → [Тестирование] → [Релиз] → [Продакшн]
   ←←←←←←←←← Shift Left ←←←←←←              Shift Right →→→→→→→→→→→→→
  • Shift Left — подключить QA раньше: к требованиям, дизайну, API-контрактам, критериям приёмки. Дефекты дешевле исправлять ближе к источнику.
  • Shift Right — смотреть на продукт после релиза: метрики, логи, жалобы пользователей, реальные сценарии. Качество не заканчивается с выходом фичи.

STLC на примере промокода в «Пиццаеде»

Этап STLC Что делаем
Анализ Читаем требования: QA60, скидка 10%, можно ли применить дважды, что с пустой корзиной
Планирование Определяем зоны: промокод, сумма, checkout, popup, регресс корзины
Дизайн Позитив: QA60 → скидка. Негатив: TEST → ошибка. Граница: пустое поле
Окружение /base/shop, данные о товарах, возможность сброса корзины
Выполнение Проходим проверки, фиксируем фактические результаты и баги
Закрытие Отчёт: что работает, что сломано, что требует уточнения у аналитика

Ключевые тезисы для теста

  • Тестирование снижает риск, но не доказывает отсутствие багов.
  • 7 принципов ISTQB: дефекты есть, исчерпание невозможно, раннее дешевле, кластеры, пестицид, контекст, польза ≠ отсутствие багов.
  • SDLC — цикл продукта, STLC — цикл тестирования; они идут параллельно.
  • STLC = анализ → планирование → дизайн → окружение → выполнение → закрытие.
  • Exit criteria — формальные условия, при которых тестирование можно завершить.
  • Shift Left — QA участвует с требований, Shift Right — QA наблюдает за продакшном.
  • Парадокс пестицида: один и тот же набор тестов перестаёт находить новые баги — тесты нужно обновлять.

Полезные ссылки