Что такое STLC?
Software Testing Life Cycle (STLC) — это систематический подход к тестированию, определяющий шаги и активности на каждой фазе. Как разработка следует SDLC, тестирование следует STLC.
STLC гарантирует, что тестирование организовано, тщательно и прослеживаемо. Он превращает тестирование из хаотичной активности в структурированный процесс с чёткими входами, выходами и критериями качества.
Шесть Фаз STLC
Требований] --> TP[2. Планирование
Тестирования] TP --> TCD[3. Проектирование
Тест-кейсов] TCD --> ES[4. Настройка
Окружения] ES --> TE[5. Выполнение
Тестов] TE --> TC[6. Закрытие
Тестирования] style RA fill:#4CAF50,color:#fff style TP fill:#2196F3,color:#fff style TCD fill:#FF9800,color:#fff style ES fill:#9C27B0,color:#fff style TE fill:#F44336,color:#fff style TC fill:#795548,color:#fff
Фаза 1: Анализ Требований
Цель: Понять, что нужно тестировать, и определить тестируемость.
Критерии входа: Документ требований доступен, стейкхолдеры доступны для уточнений.
Активности:
- Проверка требований на полноту, ясность и тестируемость
- Определение типов тестирования (функциональное, производительности, безопасности)
- Определение scope тестирования
- Оценка возможности автоматизации
- Проведение Three Amigos (Бизнес + Dev + QA) для сложных требований
- Выявление пробелов и противоречий в требованиях
Артефакты:
- Матрица прослеживаемости требований (RTM)
- Список тестируемых требований
- Отчёт о возможности автоматизации
- Список вопросов стейкхолдерам
Фаза 2: Планирование Тестирования
Цель: Определить стратегию, scope, трудозатраты и расписание.
Активности:
- Определение стратегии (ручное vs. автоматизированное, типы тестирования)
- Оценка трудозатрат (время, люди, инструменты)
- Планирование требований к окружению
- Определение необходимых инструментов
- Определение ролей и обязанностей
- Анализ рисков и план снижения
- Определение критериев входа и выхода
Артефакты: Документ Тест-плана, документ оценки трудозатрат, план ресурсов.
Фаза 3: Проектирование Тест-кейсов
Цель: Создать детальные тест-кейсы и тестовые данные.
Активности:
- Написание тест-кейсов на основе требований
- Проектирование наборов тестовых данных (позитивные, негативные, граничные значения)
- Создание скриптов автоматизированных тестов
- Ревью и приоритизация тест-кейсов
- Маппинг тест-кейсов к требованиям в RTM
Артефакты: Тест-кейсы, наборы тестовых данных, скрипты автотестов, обновлённая RTM.
Фаза 4: Настройка Окружения
Цель: Подготовить тестовое окружение и убедиться в его готовности.
Активности:
- Настройка окружения (оборудование, ПО, сеть)
- Установка и конфигурация тестируемого приложения
- Подготовка тестовых данных в окружении
- Конфигурация инструментов тестирования
- Smoke-тестирование для проверки готовности
- Документирование конфигурации
Примечание: Настройка окружения часто идёт параллельно с Проектированием тест-кейсов.
Фаза 5: Выполнение Тестов
Цель: Выполнить тест-кейсы, зафиксировать результаты и сообщить о дефектах.
Активности:
- Выполнение тест-кейсов (ручных и автоматизированных)
- Сравнение фактических результатов с ожидаемыми
- Заведение дефектов по упавшим тест-кейсам
- Перепроверка исправленных дефектов
- Регрессионное тестирование
- Отслеживание прогресса выполнения
- Обновление статусов в системе управления тестами
Артефакты: Результаты выполнения, отчёты о дефектах, отчёты о статусе, обновлённая RTM.
Фаза 6: Закрытие Тестирования
Цель: Оценить полноту тестирования и зафиксировать уроки.
Активности:
- Оценка критериев завершённости vs. фактические результаты
- Анализ метрик (процент прохождения, плотность дефектов, покрытие)
- Документирование извлечённых уроков
- Создание итогового отчёта о тестировании
- Архивация артефактов тестирования
Артефакты: Итоговый отчёт, документ уроков, отчёт метрик, архив артефактов.
STLC vs SDLC
| Фаза SDLC | Фаза STLC | Активность QA |
|---|---|---|
| Требования | Анализ Требований | Ревью требований, создание RTM |
| Дизайн | Планирование Тестирования | Создание стратегии и плана |
| Реализация | Проектирование тест-кейсов + Настройка окружения | Написание тестов, подготовка окружения |
| Тестирование | Выполнение Тестов | Выполнение тестов, отчёты о дефектах |
| Развёртывание | Закрытие Тестирования | Итоги, уроки |
| Поддержка | Текущее тестирование | Регрессия для патчей |
Матрица Прослеживаемости Требований (RTM)
RTM — один из важнейших артефактов QA. Она связывает каждое требование с тест-кейсами:
| ID Треб | Требование | ID Тест-кейсов | Статус |
|---|---|---|---|
| REQ-001 | Пользователь может зарегистрироваться через email | TC-001, TC-002, TC-003 | Пройден |
| REQ-002 | Пользователь может войти | TC-004, TC-005 | Пройден |
| REQ-003 | Пользователь может сбросить пароль | TC-006, TC-007, TC-008 | 1 Упал |
| REQ-004 | Админ может экспортировать отчёты | TC-009 | Не выполнен |
Зачем RTM:
- Гарантирует, что ни одно требование не осталось без тестов
- Показывает покрытие тестами одним взглядом
- Отслеживает статус требований через тестирование
- Выявляет пробелы в покрытии
- Требуется многими стандартами качества (ISO, CMMI)
Упражнение: Создать Артефакты STLC для Проекта
Вы — QA-лид нового функционала онлайн-банкинга: Оплата Счетов. Функционал позволяет:
- Добавлять поставщиков услуг (электричество, вода, интернет)
- Планировать разовые или регулярные платежи
- Просматривать историю платежей
- Получать уведомления о предстоящих и завершённых платежах
Ваша задача:
- Анализ требований: Создать RTM с минимум 6 требованиями и определить 2 проблемы тестируемости
- Планирование: Написать краткий план тестирования
- Проектирование: Написать 3 детальных тест-кейса (позитивный, негативный, граничный)
- Выполнение: По данным результатам определить, выполнены ли критерии выхода
Подсказка
Для RTM подумайте о функциональных и нефункциональных требованиях. Оплата счетов — финансовые транзакции, безопасность и точность критичны.
Пример решения
1. RTM
| ID Треб | Требование | Тест-кейсы | Приоритет |
|---|---|---|---|
| BP-001 | Пользователь может добавить поставщика по имени или номеру счёта | TC-001, TC-002, TC-003 | Высокий |
| BP-002 | Пользователь может запланировать разовый платёж | TC-004, TC-005, TC-006 | Высокий |
| BP-003 | Пользователь может запланировать регулярный платёж | TC-007, TC-008, TC-009, TC-010 | Высокий |
| BP-004 | Пользователь может просматривать историю (последние 12 месяцев) | TC-011, TC-012 | Средний |
| BP-005 | Уведомление за 2 дня до запланированного платежа | TC-013, TC-014 | Средний |
| BP-006 | Сумма платежа не должна превышать баланс счёта | TC-015, TC-016, TC-017 | Критический |
Проблемы тестируемости:
- Регулярные платежи требуют триггеров на основе времени — нужна возможность симуляции смены дат
- Обработка платежей включает сторонние API — нужны mock-сервисы или sandbox
2. План тестирования
Scope: Функциональное тестирование оплаты счетов. Типы: Функциональное, безопасности, производительности, юзабилити, регрессионное. Риски: Mock-шлюз может не отражать реальное поведение; регулярные платежи зависят от времени.
3. Тест-кейсы
TC-004: Планирование разового платежа (Позитивный)
- Предусловие: Пользователь авторизован, поставщик «ГорЭлектро» добавлен, баланс 50 000 руб.
- Шаги: 1) Выбрать «ГорЭлектро» 2) Ввести сумму 5 000 3) Выбрать дату: завтра 4) Нажать «Запланировать платёж»
- Ожидаемый результат: Платёж запланирован, подтверждение показано
TC-016: Платёж превышает баланс (Негативный)
- Предусловие: Пользователь авторизован, баланс 3 000 руб.
- Шаги: 1) Выбрать поставщика 2) Ввести сумму 5 000 3) Нажать «Запланировать платёж»
- Ожидаемый результат: Ошибка «Недостаточно средств. Ваш баланс: 3 000 руб.»
TC-017: Платёж равен балансу (Граничный)
- Предусловие: Пользователь авторизован, баланс 5 000.00 руб.
- Шаги: 1) Выбрать поставщика 2) Ввести сумму 5 000.00 3) Нажать «Запланировать платёж»
- Ожидаемый результат: Платёж успешно запланирован
4. Оценка критериев выхода
Результаты: 45/50 выполнено, 1 критический баг отложен, 2 средних открыты, 89% прошли.
Рекомендация: НЕ одобрять релиз. 1 отложенный критический баг — блокер для финансового функционала.
Типичные Ошибки STLC
- Пропуск анализа требований — приводит к тестам, не покрывающим критические сценарии
- Неполное планирование — вызывает расползание scope и срыв сроков
- Отсутствие критериев входа/выхода — фазы начинаются по датам, а не по готовности
- Плохое закрытие тестирования — уроки не извлекаются, ошибки повторяются
Профессиональные Советы
Автоматизируйте обновления RTM. Используйте инструменты (TestRail, Zephyr, Xray), автоматически связывающие тест-кейсы с требованиями.
Начинайте настройку окружения рано. Проблемы с окружением — причина №1 задержек тестирования.
Делайте критерии выхода измеримыми. «Тестирование завершено» — не критерий. «95% выполнено, ноль открытых критических дефектов» — критерий.
Проводите закрытие даже в agile. Мини-закрытие в конце каждого спринта, полное — в конце релиза.
Используйте RTM на встречах. Когда спрашивают «мы готовы к релизу?», RTM даёт объективный ответ на основе данных.