Ответ
Жизненный цикл тестирования программного обеспечения (Software Testing Life Cycle, STLC) — это структурированная последовательность действий, выполняемых командой QA для обеспечения качества. STLC интегрирован в общий жизненный цикл разработки (SDLC).
Основные фазы STLC:
- Анализ требований — изучение документации (PRD, user stories, спецификации) для понимания, что тестировать. Выявление тестируемых аспектов и потенциальных рисков.
- Планирование тестирования — определение как, когда и кем будет проводиться тестирование. Создание плана тестирования (Test Plan), который включает стратегию, ресурсы, расписание, критерии входа/выхода, метрики.
- Проектирование тестов — создание детальных артефактов: тест-кейсы, чек-листы, тестовые сценарии. Подготовка тестовых данных и проектирование тестового окружения.
- Настройка тестового окружения — развёртывание и конфигурация стенда (серверы, БД, мобильные устройства), на котором будут выполняться тесты. Проверка готовности среды.
- Выполнение тестов — прогон подготовленных тестов (ручных и автоматизированных). Логирование результатов, составление баг-репортов для найденных дефектов.
- Завершение тестирования — анализ результатов, оценка выполнения критериев выхода. Подготовка отчёта о тестировании, проведение ретроспективы, архивация тестовых артефактов.
Важно: STLC — итеративный процесс. В Agile фазы повторяются в каждом спринте, но с разным фокусом (например, в одном спринте упор на новом функционале, в другом — на регрессии).
Пример цикла для задачи "Добавить кнопку 'Поделиться'":
flowchart TD
A[Анализ: Требования к кнопке] --> B[Планирование: Включить в спринт #5]
B --> C[Проектирование: Тест-кейсы на кликабельность, доступность, корректность ссылки]
C --> D[Настройка: Сборка с фичей на QA-стенде]
D --> E[Выполнение: Прогон тест-кейсов, баг если ссылка битая]
E --> F[Завершение: Отчёт по спринту #5, критерии выполнены]Цель STLC — не просто найти баги, а своевременно предоставить объективную информацию о качестве продукта для принятия решений о релизе.
Ответ 18+ 🔞
Давайте разложим по полочкам эту всю канитель под названием STLC, чтобы не казалось, будто это какая-то космическая наука. По сути, это просто наш, тестерский, распорядок дня, когда мы пытаемся не дать разработчикам выпустить в мир какую-нибудь дичь.
Итак, этапы нашего славного пути:
-
Анализ требований. Сидишь, читаешь эти документы, а там написано: «Должна быть кнопка». И всё. И думаешь: «Ну, блядь, а какая кнопка-то? Квадратная? Круглая? При нажатии на неё должен выезжать пони или просто отправляться запрос в никуда?». Суть в том, чтобы понять, что вообще мы будем ломать. И уже на этом этапе чувствуешь подвох, потому что «требования» иногда пишутся на салфетке после третьего кофе.
-
Планирование тестирования. Тут мы решаем, как и когда будем это всё гробить. Составляем план: «Вася будет бить фронт, Петя — апишку, а я, красавчик, буду всё это координировать и орать, что ничего не успеваем». Определяем, когда начинаем и когда уже пора сдаваться и писать отчёт.
-
Проектирование тестов. Самый творческий этап, ёпта! Берём ту самую «кнопку» и начинаем придумывать, как её уронить. «А что если нажать её 1000 раз подряд? А что если перед этим ввести в поле символы с Марса? А что если сделать это с выключенным интернетом?». Рождаются тест-кейсы, чек-листы и злобный смех в предвкушении багов. Готовим тестовые данные: логины, пароли, названия вроде «Тест Тестович» — классика жанра.
-
Настройка тестового окружения. А вот тут начинается магия. Нужно поднять стенд, где это всё будет работать. «Сервер упал», «база не коннектится», «на этом устройстве кнопка не помещается, потому что у него экран, как почтовая марка». Половина времени уходит на то, чтобы среда просто жила. Иногда кажется, что само окружение — главный враг тестировщика.
-
Выполнение тестов. НАКОНЕЦ-ТО! Берём наши придуманные сценарии и начинаем впендюривать их в приложение. Кликаем, тыкаем, вводим ерунду. Находим баг — ура! Пишем баг-репорт. Искусство в том, чтобы описать проблему так, чтобы разработчик не просто понял, а охуел от того, как он это пропустил. «При нажатии на кнопку «Сохранить» данные не сохраняются, а на сервер улетает запрос с текстом «Йоу, чё как?». Воспроизводится стабильно, хуле».
-
Завершение тестирования. Всё, силы на исходе. Смотрим, сколько багов нашли, сколько пофиксили, можно ли выпускать эту версию в свет или она сломает пользователям жизнь. Пишем итоговый отчёт, где прямым текстом говорим: «Ребята, вы можете выкатывать это, но одна фича работает так, будто её писали в состоянии, близком к летальному». Делаем выводы на следующий раз.
Важный момент, на котором все спотыкаются: STLC — это не линейный маршрут «раз и навсегда». В Agile это весёлая карусель, которая крутится каждый спринт. Только успел отдышаться — опять новые требования, опять кнопки, опять «ой, мы тут немного поменяли архитектуру».
Вот, смотри, как это выглядит в жизни для той самой кнопки «Поделиться»:
flowchart TD
A[Анализ: Чего хотят от кнопки?] --> B[Планирование: Забиваем на всё, тестим её в спринте #5]
B --> C[Проектирование: Придумываем, как сломать<br>Кликабельность, ссылка, доступность]
C --> D[Настройка: Ставим сборку на стенд<br>и молимся, чтобы она встала]
D --> E[Выполнение: Жмём кнопку.<br>Ссылка битая? Пишем баг!]
E --> F[Завершение: Критерии вроде выполнены.<br>Отчёт готов. Можно выпить.]А главная цель всего этого цирка — не просто найти косяки, а вовремя донести до начальства и команды, что творится с продуктом. Чтобы решение о выпуске принималось не на основе криков «У меня всё работает!», а на основе нормальных, объективных данных. Или, как говорят у нас, чтобы было не «ой, всё», а «всё, я проверил».