1. Введение в профессию тестировщика и жизненный цикл разработки ПО (SDLC)
Введение в профессию тестировщика и жизненный цикл разработки ПО (SDLC)
В 1996 году программная ошибка в системе управления ракеты-носителя Ariane 5 привела к самоликвидации аппарата через 37 секунд после старта. Ущерб составил около 370 млн USD. Причиной стала попытка запихнуть 64-битное число с плавающей запятой в 16-битное целое число — классическое переполнение, которое не было выявлено на этапе проверки. Этот случай вошел в историю как один из самых дорогих уроков того, почему тестирование — это не просто «поиск багов», а критический процесс управления рисками.
Профессия QA-инженера (Quality Assurance) часто воспринимается новичками как «человек, который нажимает на кнопки, чтобы всё сломать». На деле же современное тестирование — это интеллектуальная дисциплина, стоящая на стыке аналитики, психологии и инженерии. Прежде чем мы перейдем к техническим деталям, необходимо разобраться, в какой экосистеме живет тестировщик и по каким правилам строится современное программное обеспечение.
Кто такой тестировщик: QA vs QC vs Testing
В индустрии часто путают три понятия: Quality Assurance (QA), Quality Control (QC) и Testing. Для Junior-специалиста критически важно понимать разницу, так как это определяет зону ответственности и мировоззрение профессионала.
Тестирование (Testing) — это самый узкий уровень. Это непосредственное выполнение проверок: запуск программы, ввод данных, сравнение того, что получилось, с тем, что ожидалось. Если вы открыли мобильное приложение и проверили, нажимается ли кнопка «Войти», — вы занимаетесь тестированием.
Контроль качества (Quality Control) — это более широкий процесс. Он включает в себя не только выполнение тестов, но и анализ их результатов, классификацию найденных дефектов и оценку того, готово ли приложение к выпуску. QC сфокусирован на продукте: «Соответствует ли этот конкретный билд требованиям?».
Обеспечение качества (Quality Assurance) — это стратегический уровень. QA-инженер занимается не только поиском ошибок в коде, но и предотвращением их появления в будущем. Это работа с процессами: как мы пишем требования? Как разработчики передают код на проверку? Достаточно ли у нас времени на тесты? QA сфокусирован на процессе: «Что нам нужно изменить в работе команды, чтобы продукт изначально получался качественным?».
> Качество — это степень соответствия совокупности присущих характеристик объекта требованиям. > > ISO 9000:2015
Представьте строительство дома. Тестировщик проверяет, открывается ли дверь. QC-специалист проверяет, соответствует ли весь дом чертежам и нормам безопасности перед сдачей жильцам. QA-инженер следит за тем, чтобы бетон был правильной марки, рабочие не прогуливали, а чертежи были понятны строителям еще до того, как заложен фундамент.
Психология тестирования: почему разработчики не видят свои ошибки
Один из главных барьеров в работе QA — это разница в ментальных моделях. Разработчик по своей природе — созидатель. Его задача — заставить систему работать, построить логические связи. Когда программист тестирует свой код, он подсознательно идет по «счастливому пути» (Happy Path), вводя корректные данные и совершая логичные действия.
Тестировщик же должен обладать деструктивным и критическим мышлением. Его задача — проверить, что произойдет, если система столкнется с хаосом.
Профессиональный парадокс заключается в том, что тестировщик помогает разработчику, находя его ошибки, но психологически это может восприниматься как критика. Поэтому Soft Skills (мягкие навыки) — умение вежливо и аргументированно доносить информацию о дефектах — являются базовым требованием для Junior QA.
Жизненный цикл разработки ПО (SDLC)
Программное обеспечение не появляется из ниоткуда. Оно проходит через четко определенные этапы, которые называются Software Development Life Cycle (SDLC). Понимание SDLC позволяет тестировщику понять, где именно он должен включиться в работу.
1. Сбор и анализ требований (Requirement Analysis)
На этом этапе бизнес-аналитики и заказчики решают, что именно нужно создать. Результатом становится документ — спецификация (SRS — Software Requirements Specification). Роль QA: Тестирование требований. Это самый дешевый этап для исправления ошибок. Если в требованиях написано «система должна работать быстро», QA должен указать на неопределенность и попросить конкретики: «быстро — это сколько в миллисекундах?». Исправить строчку в документе стоит 1 руб., исправить ту же ошибку в готовом коде — 100 руб., а после релиза — 1000 руб.2. Проектирование (Design)
Архитекторы решают, как система будет устроена внутри: какие базы данных использовать, как сервисы будут общаться между собой. Роль QA: Анализ архитектуры на предмет «тестируемости». Например, закладывается ли возможность выгрузки логов или создания тестовых учетных записей.3. Разработка (Implementation / Coding)
Программисты пишут код. Роль QA: На этом этапе может выполняться Unit-тестирование (модульное тестирование), которое чаще делают сами разработчики, но QA может помогать в написании автотестов или подготовке тестовых данных.4. Тестирование (Testing)
Когда код написан и собран в работающее приложение, наступает звездный час QA. Здесь проводятся все основные виды проверок: функциональные, нагрузочные, проверки безопасности и удобства использования. Результат: Список багов и отчет о качестве.5. Развертывание и внедрение (Deployment)
Продукт выпускается на рынок (релиз) или устанавливается на серверы заказчика. Роль QA: Дымовое тестирование (Smoke Test) на реальном окружении, чтобы убедиться, что при переносе ничего не «отвалилось».6. Поддержка и сопровождение (Maintenance)
Пользователи начинают работать с программой, находят редкие ошибки, запрашивают новые функции. Роль QA: Регрессионное тестирование — проверка того, что новые исправления не сломали старый, работающий функционал.Модели SDLC: от водопада до гибкости
То, как именно эти этапы сменяют друг друга, зависит от выбранной модели разработки.
Каскадная модель (Waterfall)
Это классический линейный подход. Каждый этап строго следует за предыдущим. Вы не можете начать кодить, пока не утверждены все требования, и не можете начать тестировать, пока не написан весь код.V-модель (V-Model)
Улучшенная версия Waterfall, которая делает акцент на тестировании. Она визуализируется как буква V, где левая сторона — это этапы проектирования, а правая — уровни тестирования. Ключевая идея: для каждого этапа разработки сразу готовится план тестирования.Итерационная и инкрементальная модели
Продукт создается частями. Сначала делается минимально рабочая версия (MVP), затем она обрастает новыми функциями. Каждая итерация — это маленький SDLC.Agile (Гибкая разработка)
Сегодня это стандарт индустрии. Agile — это не конкретная инструкция, а философия, описанная в Agile-манифесте. Самые популярные реализации — Scrum и Kanban. В Agile тестирование вплетено в процесс постоянно. Нет «фазы тестирования» в конце месяца — проверки идут параллельно с разработкой. Это требует от QA высокой адаптивности и умения работать в условиях неполных требований.С чего начинается качество: тестирование требований
Многие начинающие тестировщики думают, что их работа начинается с открытия приложения. Это опасное заблуждение. Работа начинается с чтения документации.
Существует понятие статического тестирования — это проверка кода или документации без запуска программы. Тестируя требования, мы ищем логические дыры. Хорошее требование должно обладать набором характеристик:
Жизненный цикл тестирования (STLC)
Внутри общего жизненного цикла разработки (SDLC) существует свой внутренний цикл — Software Testing Life Cycle (STLC). Он структурирует работу QA-отдела.
Этап 1: Анализ требований
Тестировщики изучают спецификацию и задают вопросы аналитикам. Выясняются технические ограничения.Этап 2: Планирование тестирования (Test Planning)
Создается Тест-план (Test Plan). Это стратегический документ, отвечающий на вопросы:Этап 3: Проектирование тестов (Test Design)
На этом этапе создаются Тест-кейсы (Test Cases) — пошаговые инструкции для проверки. Здесь применяются техники тест-дизайна (эквивалентное разделение, граничные значения), чтобы не проверять всё подряд, а выбрать самые эффективные сценарии.Этап 4: Настройка тестовой среды (Test Environment Setup)
Тестировщику нужно окружение — специальный сервер (Staging или Test), где развернута база данных и само приложение. Важно, чтобы это окружение было максимально похоже на «боевое» (Production), где будут работать реальные пользователи.Этап 5: Выполнение тестов (Test Execution)
Прохождение тест-кейсов. Если фактический результат совпал с ожидаемым — тест пройден (Passed). Если нет — найден баг (Failed), и тестировщик заводит баг-репорт.Этап 6: Завершение цикла (Test Closure)
Подготовка отчета (Test Summary Report). Команда анализирует: сколько багов нашли, какие из них исправили, а какие решили оставить «на потом».Почему 100% тестирование невозможно
Один из фундаментальных принципов тестирования гласит: исчерпывающее тестирование недостижимо.
Рассмотрим простой пример: поле ввода имени пользователя, которое принимает от 1 до 20 символов латиницы. Количество комбинаций букв, их регистров и последовательностей исчисляется триллионами. Если мы будем проверять каждую комбинацию по одной секунде, жизнь Вселенной закончится раньше, чем мы проверим одно это поле.
Поэтому задача QA — не проверить всё, а обеспечить достаточный уровень уверенности в продукте при ограниченных ресурсах (времени и деньгах). Для этого используются приоритеты: сначала проверяем то, что ломается чаще всего, и то, что принесет наибольший ущерб бизнесу в случае поломки.
Цена ошибки и принцип «Shift Left»
Существует прямая зависимость между временем обнаружения дефекта и стоимостью его исправления.
Современная концепция Shift Left (сдвиг влево) призывает начинать тестирование как можно раньше — буквально с первого дня обсуждения идеи. Чем левее по временной шкале SDLC мы находим проблему, тем дешевле она обходится компании.
Роль Junior QA в команде
Начинающий тестировщик чаще всего подключается на этапах выполнения тестов и частично на этапе проектирования. Основные задачи Junior-специалиста:
Однако, чтобы вырасти до уровня Middle и выше, нужно учиться смотреть на продукт шире — понимать бизнес-цели заказчика и архитектурные сложности, с которыми сталкиваются разработчики.
Взаимосвязь SDLC и STLC на практике
Представим разработку новой функции: «Вход в личный кабинет по номеру телефона».
Этот круговорот продолжается на протяжении всей жизни продукта. Тестирование — это не финальный аккорд, а непрерывный процесс сопровождения разработки.