Что такое тестирование ПО?

Что такое тестирование ПО? #

Тестирование программного обеспечения — это процесс оценки программного приложения с целью найти расхождения между ожидаемым и фактическим поведением. Но это определение из учебника лишь поверхностно описывает суть.

На практике тестирование ПО — это систематическое исследование, проводимое для предоставления заинтересованным сторонам информации о качестве тестируемого продукта. Оно включает выполнение программы или системы с целью нахождения дефектов, проверки соответствия заданным требованиям и подтверждения того, что продукт удовлетворяет потребности пользователей.

Представьте это так: если разработчик — архитектор и строитель дома, то тестировщик — это строительный инспектор. Инспектор не просто проверяет, красиво ли выглядит дом — он проверяет структурную целостность, электробезопасность, работу водопровода и соответствие строительным нормам. Он думает о землетрясениях, наводнениях и о том, что произойдёт, когда семья из пяти человек одновременно включит все души.

Более полное определение #

Стандарт IEEE 610 определяет тестирование как:

Процесс эксплуатации системы или компонента в заданных условиях, наблюдения или записи результатов и оценки какого-либо аспекта системы или компонента.

ISTQB (International Software Testing Qualifications Board) расширяет это определение: тестирование — это не только выполнение тестов. Оно включает планирование, анализ, проектирование, реализацию, выполнение, завершение и отчётность.

Тестирование ПО — это и техническая дисциплина, и образ мышления. Оно требует аналитического мышления, внимания к деталям и — возможно, самое главное — способности думать о том, что может пойти не так.

Четыре цели тестирования ПО #

1. Нахождение дефектов #

Самая очевидная цель. Каждый раз, когда вы слышите «тестировщик нашёл баг» — речь именно об этом. Тестирование систематически исследует приложение, чтобы обнаружить места, где оно ведёт себя не так, как ожидалось.

Но нахождение дефектов — дело более тонкое, чем кажется. Опытный тестировщик не кликает наугад, надеясь случайно наткнуться на баг. Он применяет техники — анализ граничных значений, эквивалентное разбиение, тестирование переходов состояний — чтобы максимизировать шансы найти дефекты за минимальное время.

2. Формирование уверенности в качестве #

Когда тщательный набор тестов проходит успешно, это даёт свидетельство того, что система работает корректно в протестированных условиях. Эта уверенность позволяет продакт-менеджерам одобрять релизы, руководителям подписывать запуски, а клиентам — доверять ПО свои данные.

Обратите внимание на аккуратную формулировку: «в протестированных условиях». Тестирование формирует уверенность, а не гарантию. Это различие имеет огромное значение.

3. Предоставление информации для принятия решений #

Результаты тестирования обеспечивают критически важные бизнес-решения:

• Готов ли продукт к выпуску? Отчёты о тестировании помогают руководству оценить риски.
• Какие функции требуют доработки? Метрики плотности дефектов выявляют проблемные области.
• Укладываемся ли мы в сроки? Отслеживание прогресса тестирования показывает состояние разработки.

Команда QA, которая только сообщает «прошёл/не прошёл», не даёт полной ценности. Лучшие QA-команды предоставляют богатую контекстную информацию, которая помогает принимать лучшие решения.

4. Предотвращение дефектов #

Это, пожалуй, наименее интуитивная цель, но, возможно, самая ценная. Активности тестирования, которые происходят рано — ревью требований, анализ дизайна, написание тест-кейсов до появления кода — действительно предотвращают внесение дефектов.

Когда тестировщик просматривает документ с требованиями и спрашивает «что произойдёт, если пользователь введёт отрицательное число?», он предотвращает дефект ещё до того, как будет написана хотя бы одна строка кода.

Тестирование vs. Отладка #

Эти две активности часто путают, особенно начинающие специалисты.

Тестирование обнаруживает, что нажатие кнопки «Отправить» с пустым email вызывает ошибку 500 сервера.

Отладка выясняет, почему сервер падает (отсутствует проверка на null в функции валидации на строке 142 в UserController.java) и исправляет это.

Тестировщик говорит: «Вот что сломано, и вот как это воспроизвести.» Разработчик говорит: «Вот почему это сломано, и вот как я это починил.»

Обе роли необходимы. Ни одна не заменяет другую.

Краткая история тестирования ПО #

Понимание истоков тестирования помогает оценить, где оно находится сегодня.

1950-1960-е: Тестирование = Отладка. В ранние дни вычислительной техники различий не было. Программисты писали код и проверяли его сами. Знаменитый «первый компьютерный баг» — моль, застрявшая в реле Harvard Mark II в 1947 году — был буквально debugging-ом.

1970-е: Тестирование как демонстрация. Тестирование означало демонстрацию того, что ПО работает. Фокус был на показе правильного поведения, а не на поиске проблем.

1980-е: Тестирование как разрушение. Мышление сместилось к активным попыткам сломать ПО. «Искусство тестирования программ» Гленфорда Майерса (1979) определило тестирование как «процесс выполнения программы с целью нахождения ошибок».

1990-е: Тестирование как предотвращение. Индустрия признала, что позднее обнаружение багов обходится дорого. Появились планирование тестов, ревью и ранние активности тестирования.

2000-е — настоящее время: Тестирование как инженерия качества. Современное тестирование охватывает автоматизацию, непрерывную интеграцию, shift-left тестирование и встраивание качества на каждом этапе разработки.

Место тестирования в SDLC #

Тестирование — это не фаза, которая происходит в конце. В современной разработке активности тестирования происходят на каждом этапе:

На каждом этапе активности тестирования обеспечивают обратную связь:

• Фаза требований: Тестировщики проверяют требования на тестируемость, полноту и непротиворечивость
• Фаза дизайна: Тест-архитекторы планируют стратегию тестирования и проектируют тест-кейсы
• Фаза реализации: Разработчики пишут модульные тесты; тестировщики готовят тестовые среды
• Фаза тестирования: Формальное выполнение тестов, отчёты о дефектах, регрессионное тестирование
• Фаза развёртывания: Smoke-тестирование, sanity-проверки, верификация в продакшене
• Фаза сопровождения: Регрессионное тестирование для исправлений и новых функций

Чем раньше вы находите дефект, тем дешевле его исправить. Ошибка в требованиях, обнаруженная при ревью, стоит почти ничего. Та же ошибка, обнаруженная в продакшене, может стоить миллионы.

Почему тестирование важно #

Если вы всё ещё сомневаетесь, действительно ли тестирование необходимо, задумайтесь: каждая программа, которую вы используете ежедневно, была протестирована. Ваше банковское приложение, мессенджер, прошивка тормозной системы автомобиля — всё это прошло тестирование.

Когда тестирование выполняется плохо или пропускается, последствия варьируются от мелких неудобств (приложение вылетает) до катастроф (медицинские устройства работают неправильно, финансовые системы теряют миллионы, космические аппараты уничтожаются).

Тестирование не опционально. Это страховочная сеть между человеческой ошибкой и программными системами, от которых зависит современное общество.

Реальные провалы в тестировании #

Понимание важности тестирования становится особенно ощутимым, когда рассматриваешь реальные катастрофы.

Therac-25 (1985-1987) #

Therac-25 — аппарат лучевой терапии, используемый в больницах. Из-за состояния гонки (race condition) в программном обеспечении, которое не было должным образом протестировано, аппарат подвергал пациентов смертельным дозам радиации — как минимум шесть человек пострадали, трое погибли.

Корневая причина: программный флаг не сбрасывался корректно, когда оператор быстро изменял параметры лечения. Условие возникало только когда оператор был достаточно быстр, чтобы выполнить определённую последовательность за 8 секунд — сценарий, который модульные тесты и медленное ручное тестирование никогда не выявляли.

Урок тестирования: Граничные случаи и состояния гонки убивают. Буквально. Тестирование должно учитывать тайминг, конкурентность и паттерны поведения операторов.

Knight Capital Group (2012) #

Knight Capital развернула новое торговое ПО с критическим дефектом: старый тестовый код случайно остался в продакшен-сборке. За 45 минут система совершила ошибочные сделки, которые привели к убытку в 440 миллионов долларов.

Компания обанкротилась через несколько дней.

Урок тестирования: Верификация деплоя и smoke-тестирование в продакшене не опциональны. Простая проверка — «система торгует как ожидается в первые 60 секунд?» — могла бы остановить катастрофу.

Ariane 5, рейс 501 (1996) #

Ракета Ariane 5 Европейского космического агентства взорвалась через 37 секунд после запуска. Ущерб: 370 миллионов долларов. Причина: 64-битное число с плавающей точкой было преобразовано в 16-битное целое, что вызвало переполнение. Код был повторно использован из Ariane 4, где значения никогда не превышали диапазон 16 бит.

Урок тестирования: Повторно используемые компоненты должны быть перетестированы в новом контексте. Допущения из предыдущей системы автоматически не переносятся.

Упражнение: определите цели тестирования #

Прочитайте следующий сценарий и определите, какие цели тестирования применимы:

Сценарий: Ваша команда разрабатывает мобильное банковское приложение. Продакт-менеджер хочет запуститься через 6 недель. Приложение позволяет проверять баланс, переводить деньги и оплачивать счета.

Для каждой ситуации определите, какая основная цель тестирования достигается:

1. Тестировщик обнаруживает, что перевод ровно $10,000 вызывает ошибку округления на $0.01
2. QA-лид представляет отчёт, показывающий, что 94% тест-кейсов прошли, а 6% провалились в некритичных функциях
3. Во время ревью требований тестировщик спрашивает: «Что должно произойти, если сессия пользователя истечёт посередине перевода?»
4. После исправления ошибки округления команда запускает полный регрессионный набор тестов — все проходят

Профессиональные советы из опыта работы в продакшене #

Совет 1: Тестирование начинается до появления кода. В тот момент, когда вы получаете документ с требованиями или user story, вы уже тестируете. Читайте критически. Задавайте вопросы. Ставьте под сомнение допущения. Самые дешёвые баги — те, которые никогда не были написаны в коде.

Совет 2: «На моей машине работает» — это не тестирование. Демонстрация happy path разработчиком — это валидация, а не верификация. Настоящее тестирование означает целенаправленные попытки сломать вещи в реалистичных условиях.

Совет 3: Документируйте, что вы протестировали И что НЕ протестировали. Заинтересованным сторонам нужно понимать и покрытие, и пробелы. «Мы протестировали все платёжные потоки, но не тестировали производительность под нагрузкой» ценнее, чем «все тесты прошли».

Ключевые выводы #

• Тестирование ПО — это систематический процесс оценки качества, а не случайные клики
• У тестирования четыре цели: нахождение дефектов, формирование уверенности, предоставление информации и предотвращение дефектов
• Тестирование и отладка — взаимодополняющие, но различные активности
• Тестирование эволюционировало от «проверки, работает ли» до «встраивания качества на каждом этапе»
• Активности тестирования принадлежат каждой фазе SDLC, а не только концу
• Стоимость обнаружения дефектов резко возрастает с каждой последующей фазой