1. Жизненный цикл разработки ПО (SDLC) и место тестировщика
Добро пожаловать в мир обеспечения качества! Если вы решили освоить профессию QA-инженера (Quality Assurance), первое, с чем вам предстоит столкнуться — это понимание того, как вообще создаются программы. Невозможно эффективно проверять качество продукта, если вы не понимаете, на каком этапе конвейера находитесь и кто стоит рядом с вами.
Многие начинающие специалисты ошибочно полагают, что тестировщик вступает в игру только тогда, когда программист закончил писать код. Это один из самых вредных мифов в IT. Чтобы стать востребованным специалистом, необходимо мыслить шире и понимать Жизненный цикл разработки ПО (Software Development Life Cycle, или SDLC).
Что такое SDLC и зачем это тестировщику
SDLC — это структурированный процесс, который проходит любой программный продукт от момента зарождения идеи до вывода из эксплуатации. Это своеобразный конвейер, где каждый участник команды знает свою роль.
Представьте строительство многоквартирного дома. Вы не можете начать клеить обои (тестировать интерфейс), пока не возведены стены (не написан код). Но и ждать окончания стройки, чтобы проверить качество фундамента, тоже нельзя — если фундамент залит криво, дом рухнет, и переделывать придется всё. Инспектор по качеству (QA) должен изучить чертежи еще до начала земляных работ.
Понимание SDLC дает тестировщику ответы на три главных вопроса:
6 основных этапов SDLC и место QA на каждом из них
В разных компаниях названия этапов могут немного отличаться, но фундаментальная суть остается неизменной. Рассмотрим классический цикл и конкретные практические задачи тестировщика на каждом шаге.
1. Сбор и анализ требований (Planning & Requirements)
На этом этапе заказчик, бизнес-аналитики и менеджеры проектов решают, что именно нужно создать. Формируется документация, описывающая, как должна работать система.
Роль тестировщика: Здесь начинается статическое тестирование — проверка без запуска самого кода. Вы читаете требования и ищете в них логические дыры, противоречия и неточности.
Практический пример: Аналитик написал требование: «Пароль пользователя должен состоять ровно из 8 символов». В другом абзаце того же документа указано: «Пароль должен содержать от 10 до 15 символов». Если программист начнет писать код по этим требованиям, он создаст баг. Вы, как QA, находите это противоречие на этапе текста, задаете вопрос аналитику, и ошибка исправляется за 2 минуты.
2. Проектирование (Design)
Системные архитекторы и дизайнеры решают, как технически реализовать требования. Выбираются базы данных, языки программирования, рисуются макеты интерфейсов.
Роль тестировщика: QA-инженер начинает планировать свою будущую работу. Создается Тест-план (Test Plan) — стратегический документ, описывающий, что мы будем тестировать, какие виды тестирования применим и какие ресурсы для этого понадобятся.
3. Разработка или Кодирование (Development)
Программисты пишут код. Это самый длительный технический этап.
Роль тестировщика: Пока разработчики пишут код, тестировщик не пьет кофе в ожидании. Это время для создания тестовой документации. Вы пишете тест-кейсы (test cases) и чек-листы (checklists). Вы переносите эти сценарии в специализированные системы управления тестированием, такие как TestRail или Zephyr.
Практический пример: Разработчик создает форму оплаты картой. Вы в это время пишете пошаговые инструкции для будущей проверки:
4. Тестирование (Testing)
Код написан и передан в тестовую среду. Наступает звездный час мануального тестировщика.
Роль тестировщика: Вы берете написанные ранее тест-кейсы и начинаете их выполнять. Вы сравниваете Ожидаемый результат (как должно быть по требованиям) с Фактическим результатом (как программа работает на самом деле). Если они не совпадают — вы нашли баг (дефект).
Далее вы оформляете баг-репорт (отчет об ошибке) в баг-трекинговой системе, например, в Jira. После того как программист исправит ошибку, вы проводите повторное тестирование, чтобы убедиться, что проблема действительно ушла.
5. Развертывание и Релиз (Deployment)
Продукт, прошедший проверку, переносится на «боевые» серверы (production) и становится доступен реальным пользователям.
Роль тестировщика: Проведение дымового тестирования (Smoke testing) на рабочей среде. Это быстрая проверка самого критичного функционала.
Практический пример: После релиза обновления интернет-магазина вы заходите на реальный сайт как обычный покупатель и пробуете положить товар в корзину. Если кнопка «Купить» не нажимается — релиз срочно откатывают назад.
6. Поддержка (Maintenance)
Программа живет своей жизнью. Пользователи находят неочевидные ошибки, а бизнес придумывает новые функции.
Роль тестировщика: Воспроизведение багов, о которых сообщили пользователи в службу поддержки. Также при добавлении новых функций QA проводит регрессионное тестирование (Regression testing) — проверку того, что новый код не сломал старый, ранее работавший функционал.
!Схема жизненного цикла разработки ПО (SDLC) с указанием задач тестировщика на каждом этапе.
Цена ошибки: почему QA вступает в игру так рано
Главное правило обеспечения качества гласит: чем позже найдена ошибка, тем дороже стоит ее исправление. В IT существует математическая закономерность стоимости дефекта, которую можно выразить простым неравенством:
Где — стоимость исправления на этапе требований, — на этапе разработки, а — после релиза продукта.
Давайте рассмотрим это на конкретных числах:
| Этап обнаружения бага | Действия для исправления | Примерная стоимость для бизнеса | | :--- | :--- | :--- | | Требования | Аналитик стирает одно предложение в документе и пишет новое. | 1 000 руб. (1 час работы аналитика) | | Разработка | Программист переписывает кусок кода, тестировщик проверяет его заново. | 15 000 руб. (день работы команды) | | После релиза | Пользователи не могут оплатить товар. Служба поддержки перегружена жалобами. Программисты бросают текущие задачи и делают срочный патч (hotfix). Компания теряет прибыль и репутацию. | 500 000 руб. + отток клиентов |
Именно поэтому современный QA-инженер начинает работу с первого дня проекта. Найти ошибку в тексте требований в сотни раз дешевле, чем исправлять готовый код на серверах.
SDLC против STLC: цикл внутри цикла
Изучая SDLC, вы обязательно столкнетесь с аббревиатурой STLC — Software Testing Life Cycle (Жизненный цикл тестирования ПО).
Если SDLC описывает работу всей команды (от аналитика до девопс-инженера), то STLC — это ваш личный процесс внутри большого конвейера.
> Основное различие между этими двумя жизненными циклами заключается в том, что SDLC ориентирован на создание ПО и работу со связанными с ним требованиями и обязанностями. В то время как STLC сосредоточен на тестировании ПО с целью выявления и исправления возможных дефектов. > > QaRocks
Этапы STLC идут параллельно этапам SDLC. Например, когда весь проект находится на стадии «Проектирование» (SDLC), отдел тестирования находится на стадии «Планирование тестов» (STLC). Когда программисты переходят к «Разработке», тестировщики переходят к «Проектированию тестов» (написанию тест-кейсов).
Понимание своего места в жизненном цикле разработки — это фундамент. Вы не просто «искатель багов в готовой программе». Вы — специалист, который предотвращает появление этих багов на самых ранних этапах, экономит деньги бизнеса и гарантирует, что финальный продукт решит проблему пользователя.