Ответ
SDLC (Software Development Life Cycle) — это структурированный процесс создания ПО, где тестирование не изолированный этап, а непрерывная активность. Основные фазы и роль тестирования в них:
-
Сбор и анализ требований: Тестировщик участвует в уточнении требований, задавая вопросы на предмет двусмысленностей, проверяемости и полноты. На выходе — начало формирования тест-аналитики и чек-листов.
-
Проектирование (Design): Проектируется архитектура. Тестировщик оценивает тестируемость архитектуры, планирует необходимые тестовые среды и инструменты. Создаются первые высокоуровневые тест-планы.
-
Разработка (Implementation): Пока разработчики пишут код, тестировщик:
- Пишет и автоматизирует тест-кейсы на основе спецификаций.
- Выполняет статическое тестирование (ревью кода, требований).
- Запускает ранние smoke-тесты на сборках.
-
Фаза активного тестирования (Testing): Выполняется основной объем динамического тестирования:
- Функциональное тестирование (по чек-листам и тест-кейсам).
- Нефункциональное тестирование (нагрузка, безопасность, UX).
- Регрессионное тестирование после исправления багов.
- Автоматизированный прогон регрессионных сьютов.
-
Внедрение (Deployment): Тестировщик проводит санитарное (smoke) и приемочное (UAT) тестирование на production-подобной среде, чтобы убедиться в готовности к выпуску.
-
Сопровождение (Maintenance): После релиза тестируются исправления багов и минорные обновления. Актуализируется набор автоматизированных тестов.
Ключевой современный тренд — смещение тестирования влево (Shift-Left): вовлечение QA на самых ранних этапах для профилактики дефектов, а не их поиска в конце. В Agile/DevOps тестирование интегрировано в каждый спринт, а автоматизация является неотъемлемой частью CI/CD-пайплайна.
Ответ 18+ 🔞
Да ты послушай, что за модная хуйня сейчас пошла — SDLC! А расшифровывается-то просто: жизнь какого-нибудь куска софта от рождения до гроба. И главная фишка в том, что тестирование — это не какая-то отдельная забегаловка в конце, куда приносят готовый продукт и говорят «ну-ка, поищи тут говна». Нет, блядь! Это непрерывный процесс, как зубная боль, только полезный. Сейчас разжую, как есть.
Ну, поехали по этапам, ёпта.
1. Сбор и анализ требований. Вот тут все начинается. Сидят менеджеры, продакты, рисуют красивые картинки. А наш брат-тестировщик должен вломиться в эту идиллию и начать доёбываться. «А что вот это значит? А что будет, если пользователь нажмет сюда левой пяткой? А где, блядь, описание этого краевого случая?». Задача — вытащить все неоднозначности, пока они не превратились в баги. И уже тут начинается тест-аналитика, рождаются первые чек-листы в голове. Подозрение ебать чувствую, что тут нас ждет.
2. Проектирование. Архитекторы начертили какие-то квадратики-стрелочки, все красиво. А тестировщик смотрит на эту схему и думает: «Ну и манда с ушами. Как я к этому модулю тесты-то прикручу? Где мне столько тестовых серверов взять?». Планируется, чем и как будем проверять. Пишутся первые тест-планы, высокоуровневые, но уже.
3. Разработка. Программисты кодируют, а мы не спим. Пока они компилят, мы:
- Пишем и даже автоматизируем тест-кейсы по готовым спецификациям.
- Делаем статическое тестирование — то есть просто читаем их код и требования, ищем косяки в логике, не запуская ничего. Иногда охуеваем от увиденного.
- Как только появилась первая сборка — врубаем на ней smoke-тесты, чтобы понять, вообще она жива или уже накрылась медным тазом.
4. Фаза активного тестирования. А вот тут уже начинается ад и Израиль. Основной объём работы:
- Функциональное тестирование — тупо проверяем, работает ли так, как хотели.
- Нефункциональное — а теперь давайте нагрузим эту штуку, проверим безопасность, посмотрим, не разъёбывается ли интерфейс.
- Регрессионное тестирование — пофиксили один баг, а мы проверяем, не сломали ли они всё остальное. Вечная история.
- Автоматизированные прогоны — если, конечно, автоматизацию не просрали на предыдущих этапах.
5. Внедрение. Всё, релиз на носу. Паника. Мы в последний момент делаем санитарное тестирование (smoke) на среде, похожей на боевую, и помогаем с приемочным (UAT), чтобы заказчик не охуел от результата.
6. Сопровождение. Выпустили и забыли? Хуй там! Жизнь продолжается. Ловим баги от пользователей, тестируем исправления и мелкие обновления. Поддерживаем в актуальном состоянии всю эту овердохуищу автотестов.
А теперь, самое важное — тренд «Shift-Left». Это когда тестировщика впихивают в процесс как можно раньше, чуть ли не в момент зарождения идеи. Чтобы дефекты не искать потом, а не давать им родиться вообще. В Agile и DevOps мы вообще становимся частью каждой итерации, а автотесты — это кровь CI/CD пайплайна. Не написал тест — твой код не полетит в продакшн. Вот так-то, чувак.
