Какие бывают виды тестирования

Каждое приложение может сломаться в самый неудобный момент. Например, когда человек оплачивает заказ или сохраняет важный документ. Компании проводят тестирование, чтобы проверить, как работает продукт, где он может дать сбой и насколько удобно им пользоваться. Это помогает найти ошибки до того, как их увидят пользователи. В статье разбираем, какие бывают виды тестирования, в чём их особенности и где их применяют.

Этапы тестирования

Тестирование не начинается с кнопки «запустить». Сначала команда решает, что и зачем проверять. В классическом подходе выделяют несколько этапов — они помогают не упустить важное. Рассмотрим их.

• Смотрят на требования. Тестировщики читают документацию, обсуждают цели проекта и определяют, какие части системы можно протестировать. На этом этапе команда понимает, что и как стоит проверять.
• Планируют работу. Команда подбирает стратегию, инструменты, сроки и нужное оборудование. Потом описывает в плане, что протестировать, зачем, какими методами, на каком стенде. А еще указывает возможные риски и то, как их устранить.
• Пишут тесты. Тестировщики составляют сценарии, подбирают данные и объясняют, как именно будут проверять. Эти материалы используют дальше.
• Запускают тесты. Тестировщики выполняют сценарии, находят ошибки и передают отчеты разработчикам. Чем больше деталей о баге, тем быстрее его исправят.
• Составляют отчеты. Команда собирает сводки и метрики. Сравнивает результат с ожиданиями и решает, готов ли продукт к релизу.
• Разбирают баги. Разработчики и тестировщики проверяют ошибки вместе. Уточняют, какие баги нужно исправить, а какие можно оставить. Иногда система ведет себя не так, как хотелось бы, но при этом работает правильно.
• Проверяют повторно. После правок тестировщики снова запускают нужный сценарий и смотрят, ушла ли ошибка.
• Проводят регрессию. Тестируют старые функции, чтобы убедиться, что новые изменения ничего не сломали. Запускают те тесты, которые касаются измененных частей.
• Завершают проверку. Когда продукт проходит все проверки, команду отключают от проекта. Результаты, журналы и логи сохраняют — на случай, если проект вернется в работу.

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

Запишитесь на курс «Инженер по тестированию» с нуля от Skypro. Если выделять 10–12 часов в неделю, уже через девять месяцев можно сменить профессию. Центр карьеры подскажет, как составить резюме и подготовиться к техническому собеседованию.

Виды тестирования

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

По запуску кода

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

По доступу к коду

• Метод «черного ящика». Тестировщики не смотрят внутрь программы. Они не знают, как работает код, и не изучают его структуру. Проверяют только результат: соответствует ли он ожиданиям. Работают с готовыми сценариями и исходят из требований заказчика.
• Метод «белого ящика». Тестировщики разбираются в архитектуре, читают код и проверяют каждую ветку. Подбирают входные данные так, чтобы пройти все участки программы. Так они проверяют, как работает внутренняя логика.
• Метод «серого ящика». Метод совмещает два первых подхода. Тестировщики не углубляются в логику, но знают, как устроены данные. Они проверяют, как система обрабатывает информацию, и ищут ошибки, которые связаны с ее хранением или передачей.

По уровню проверки

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

Интеграционное. Команда проверяет, как модули работают вместе. Тесты запускают по очереди или одновременно. Иногда разбивают проверку на части:

• Компонентное — тестируют отдельные блоки системы.
• Системное интеграционное — смотрят, как общаются подсистемы.
• Сквозное — проверяют, как система взаимодействует с внешними сервисами.

Интеграционные тесты обычно сложные. Чтобы упростить отладку, их делят на более мелкие.

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

Monkey-тест. Тестировщик жмет случайные кнопки, вводит бессмысленные данные и проверяет, как система реагирует. Так он находит неожиданные сбои, которые обычные тесты не ловят.

Smoke-тест. Команда проверяет, запускается ли программа и выполняет ли базовые функции. Если система стабильно работает, переходят к более глубоким тестам. Smoke-тест отсекает критические баги еще в самом начале.

По роли пользователя

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

• Пользовательское (UAT) — клиент сам тестирует продукт в своем окружении.
• Эксплуатационное (OAT) — проверяют, как система работает в реальных условиях.
• Контрактное и нормативное — сверяют результат с требованиями договора и стандартами.

По способу выполнения

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

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

По подготовленности ПО

• Интуитивное (Ad hoc). Тестировщик не пишет сценарии заранее. Он запускает программу и пробует разные действия, чтобы понять, где она может сломаться. Такой подход работает, если человек уже сталкивался с подобными багами и умеет быстро находить слабые места.
• Исследовательское (Exploratory). Тестировщик изучает продукт и сразу проверяет, как он работает. Он нажимает кнопки, пробует разные пути и ищет, где программа ведет себя странно. Такой способ удобен, когда нет документации или она устарела.
• Проверка документации и требований (Documentation testing). Тестировщик читает технические документы, запускает программу и сравнивает то, что написано, с тем, как система себя ведет. Если результат не совпадает с описанием, это нужно исправить.

Принципы программного тестирования

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

Выявляют дефекты

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

Не тестируют всё подряд

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

Начинают тестировать заранее

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

Проверяют рискованные участки

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

Меняют подход

Программа перестает реагировать на одни и те же тесты. Чтобы находить баги, тестировщики пробуют новые сценарии, пересматривают методы и ищут нестандартные решения.

Подстраиваются под контекст

Каждое приложение работает в своей среде. В интернет-магазине нужно одно, в банковском сервисе — другое. Тестировщик подбирает методы под цели, задачи и риски: для банка в первую очередь важна безопасность, для игры — стабильность и скорость.

Смотрят шире

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

Главное о видах тестирования ПО

• 🔹 Тестирование помогает находить баги до того, как с ними столкнется пользователь. Это экономит время, деньги и нервы всей команды.
• 🔹 Команда не проверяет каждую кнопку. Вместо этого выбирает важные сценарии и тестирует только то, что влияет на работу продукта.
• 🔹 Если начать тестирование в начале разработки, баги не прорастают глубоко. Проще их исправить и не переписывать код целиком.
• 🔹 Сложный модуль почти всегда ломается первым. Тестировщики заранее знают, где искать баги, и не тратят время на очевидное.
• 🔹 Тесты со временем устаревают. Чтобы не пропустить ошибку, нужно обновлять сценарии и менять подходы.
• 🔹 Методы тестирования подбирают под задачу. Безопасность важна в банке, стабильность — в игре, удобство — в приложении для заказов.
• 🔹 Даже если система работает по инструкции, она может раздражать. Удобство — тоже часть качества.