1. Основы, принципы и цели тестирования согласно стандартам ISTQB
Основы, принципы и цели тестирования согласно стандартам ISTQB
В 1994 году запуск спутника связи Ariane 5 закончился катастрофой через 40 секунд после старта. Причиной стал программный сбой: попытка упаковать 64-битное число с плавающей запятой в 16-битное целое число привела к переполнению. Убытки составили 370 миллионов USD. Этот случай вошел в учебники как классический пример того, что тестирование — это не просто «поиск багов», а критический процесс управления рисками. Когда мы говорим о профессиональном тестировании, мы опираемся на стандарты ISTQB (International Software Testing Qualifications Board), которые превращают интуитивную проверку кнопок в строгую инженерную дисциплину.
Что такое тестирование на самом деле: цели и задачи
Многие начинающие специалисты совершают ошибку, полагая, что цель тестирования — доказать, что программа работает. На самом деле, профессиональный подход прямо противоположен. Тестирование — это процесс, направленный на оценку качества программного обеспечения и снижение риска его отказа в процессе эксплуатации.
Согласно ISTQB, цели тестирования трансформируются в зависимости от этапа жизненного цикла ПО:
Важно различать понятия «ошибка», «дефект» и «отказ». В терминологии ISTQB это строгая иерархия: * Ошибка (Error/Mistake): Действие человека (программиста, аналитика), которое привело к неверному результату. Например, разработчик не выспался и перепутал оператор с . * Дефект (Defect/Bug/Fault): Изъян в компоненте или системе, порожденный ошибкой. Это «спящая» проблема в коде или документации. * Отказ (Failure): Событие, при котором система не выполняет требуемую функцию в рамках заданных требований. Отказ происходит, когда выполняется код, содержащий дефект.
> Не каждый дефект приводит к отказу. Если дефект находится в «мертвом коде», который никогда не вызывается пользователем, система будет работать стабильно, несмотря на наличие ошибки в исходниках.
Семь принципов тестирования: философия качества
Эти принципы — фундамент мышления QA-инженера. Они помогают аргументированно отвечать на вопросы менеджеров вроде «Почему вы не нашли все баги?» или «Когда мы уже закончим тестировать?».
1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
Тестирование может показать, что дефекты есть, но оно никогда не докажет, что их нет совсем. Даже после самого тщательного прогона тысячи тестов мы можем лишь утверждать, что в данных сценариях при данных условиях дефекты не обнаружены. Это снижает вероятность наличия скрытых проблем, но не сводит её к нулю.2. Исчерпывающее тестирование недостижимо
Попытка протестировать все комбинации входных данных и предусловий невозможна для любой мало-мальски сложной системы. Рассмотрим пример: поле ввода пароля длиной от 1 до 8 символов, принимающее цифры и латинские буквы. Количество комбинаций составит:Это триллионы вариантов. Вместо попыток проверить всё, тестирование использует анализ рисков и техники тест-дизайна (эквивалентное разделение, анализ граничных значений), чтобы выбрать наиболее репрезентативные проверки.
3. Раннее тестирование экономит время и деньги
Дефекты, найденные на этапе формирования требований, исправляются простым редактированием текста. Дефекты, найденные в готовом коде, требуют переписывания логики, повторного тестирования и сборки проекта. График стоимости исправления ошибки растет экспоненциально по мере продвижения по жизненному циклу разработки.4. Кластеризация дефектов
Принцип Парето в тестировании: около 80% отказов системы обычно сосредоточены в 20% её модулей. Если вы нашли много багов в модуле «Оплата», велика вероятность, что там скрывается еще больше проблем. Это сигнал для QA-команды: нужно сосредоточить усилия именно в этой «хрупкой» зоне.5. Парадокс пестицида
Если вы будете повторять одни и те же тесты снова и снова, со временем они перестанут находить новые дефекты. Система «привыкает» к ним, как насекомые к пестицидам. Чтобы поддерживать эффективность, тестовые наборы нужно регулярно пересматривать, обновлять и дополнять новыми сценариями.6. Тестирование зависит от контекста
Методы тестирования интернет-магазина и системы управления ядерным реактором будут кардинально различаться. В первом случае важнее юзабилити и скорость загрузки, во втором — надежность, отказоустойчивость и безопасность. Не существует универсального чек-листа «для всего».7. Заблуждение об отсутствии ошибок
Нахождение и исправление большого количества дефектов не гарантирует успех продукта. Если система работает без сбоев, но не удовлетворяет потребности пользователей или неудобна в использовании, она бесполезна. Качество — это не только отсутствие багов, но и соответствие ожиданиям рынка.Психология тестирования: конфликт или сотрудничество?
Тестирование часто воспринимается как деструктивная деятельность — «ломание» того, что другие создавали с трудом. Это порождает психологическое напряжение. Согласно ISTQB, важно понимать разницу в майндсете (складе ума) разработчика и тестировщика.
Разработчик ориентирован на созидание и решение проблем. Его мозг настроен на вопрос: «Как мне заставить это работать?». Тестировщик же должен обладать критическим мышлением, любопытством и вниманием к деталям. Его вопрос: «А что, если я сделаю вот так? Сломается ли система?».
Чтобы избежать конфликтов, QA-специалист должен: * Сообщать о дефектах нейтрально и профессионально. Вместо «Ты здесь накосячил» — «При вводе спецсимволов система выдает ошибку 500». * Помнить, что общая цель — качественный продукт, а не поиск виноватых. * Подтверждать дефекты фактами (логами, скриншотами, шагами воспроизведения).
Процесс тестирования: не только выполнение тестов
Многие новички думают, что работа тестировщика начинается с нажатия кнопок в готовом приложении. ISTQB выделяет формализованный процесс, состоящий из нескольких логических этапов.
Планирование тестирования
Здесь определяются цели, стратегия и охват. Мы отвечаем на вопросы: что мы тестируем? Каковы критерии завершения (когда мы поймем, что пора остановиться)? Какие ресурсы нам нужны (люди, девайсы, тестовые стенды)?Мониторинг и контроль
На протяжении всего проекта мы сравниваем реальный прогресс с планом. Если мы планировали проверить 100 функций за неделю, а проверили только 20, нужно корректировать сроки или ресурсы.Анализ тестирования
На этом этапе мы изучаем базис тестирования (требования, документацию, архитектуру). Мы решаем, что именно нужно протестировать. Например, если в ТЗ написано «Система должна выдерживать 1000 пользователей», аналитической задачей будет выделить сценарии нагрузки.Проектирование (Дизайн)
Здесь мы создаем конкретные тест-кейсы (тестовые сценарии). Мы определяем входные данные, шаги и ожидаемый результат. > Пример тест-кейса: > * Шаг: Ввести в поле «Возраст» значение . > * Ожидаемый результат: Система выводит сообщение «Некорректный возраст».Реализация
Подготовка тестовой среды и инструментов. Если для теста нужны специальные данные в базе (например, пользователь с отрицательным балансом), они создаются на этом этапе.Выполнение
Самый заметный этап: запуск тестов (ручной или автоматизированный), сравнение фактического результата с ожидаемым и регистрация дефектов в баг-трекинговых системах (например, Jira).Завершение
Сбор данных по итогам цикла. Мы анализируем: сколько багов осталось открытыми? Какие риски не закрыты? Создается отчет о результатах тестирования (Test Summary Report), на основе которого принимается решение о релизе.Тестирование и обеспечение качества: в чем разница?
В индустрии часто путают термины QA (Quality Assurance), QC (Quality Control) и Testing. ISTQB вносит ясность в эту иерархию.
Если тестирование находит баг, то QA анализирует, почему этот баг стал возможен и как изменить процесс, чтобы такие ошибки не повторялись в будущем.
Этика и стандарты поведения
Профессиональный тестировщик согласно кодексу этики ISTQB/IEEE должен: * Действовать в интересах общества (не выпускать опасное ПО). * Быть независимым. Лучшее тестирование — то, которое проводится человеком, не писавшим этот код. Независимость может быть разной: от тестирования коллегой-разработчиком до внешнего аудита сторонней компанией. * Постоянно обучаться. Технологии меняются быстрее, чем пишутся стандарты.
Контекст и жизненный цикл: краткий взгляд вперед
Тестирование не существует в вакууме. Оно тесно связано с тем, как пишется код. В классической «Водопадной» (Waterfall) модели тестирование происходит в самом конце. В гибких методологиях (Agile) тестирование идет параллельно с разработкой короткими итерациями.
Понимание того, где заканчивается планирование и начинается дизайн, или почему парадокс пестицида заставляет нас автоматизировать тесты — это те знания, которые отличают «кликальщика» от инженера по обеспечению качества. В следующих главах мы детально разберем, как эти принципы реализуются в различных моделях разработки и на разных уровнях — от маленькой функции до огромной распределенной системы.
Завершая обсуждение основ, важно помнить: тестирование — это не поиск совершенства. Совершенного ПО не существует. Тестирование — это предоставление объективной информации о рисках. Мы не делаем программу «идеальной», мы делаем её «достаточно хорошей» для пользователя и бизнеса, понимая, где именно могут скрываться проблемы.