Как тестировщики проверяют, что программа делает то, что нужно

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

Что такое функциональное тестирование

Функциональное тестирование — это такое тестирование, когда программное обеспечение проверяют на соответствие функциональным требованиям и спецификациям. 

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

При функциональном тестировании пишут тесты для ручной проверки и запускают автотесты, имитируют нажатие 100 000 клавиш в секунду, смотрят на трафик и проверяют работу программы или веб-сервиса со всех сторон.

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

Выделяют такие виды функционального тестирования:

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

Например, многие считают синонимами модульное и компонентное тестирование, интеграционное и системное тестирование, а также дымовое тестирование и тестирование на здравомыслие.

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

После того как в готовое программное обеспечение вносят какие-то изменения, например добавляют что-то или обновляют, проводят такие тестирования:

Модульное тестирование

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

Во время модульного тестирования изучают все логические пути и условия — например, что для всех операторов if-then-else все ветви пути являются условиями if и then. Кроме этого, могут проверять недопустимые условия. Например, дни месяца могут иметь значения от 1 до 31. Тестирование будут запускать также для значений 0 и 32.

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

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

Компонентное тестирование

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

Но бывает, что работа компонентов требует взаимодействия данных. Какие-то данные отправляют системе запросы, а другие данные их получают и возвращают какой-то ответ.

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

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

Интеграционное тестирование

После того как модули и компоненты тестируют по отдельности, нужно убедиться, что они правильно работают вместе. Это особенно важно, если над ПО работают несколько разработчиков, которые пишут код по отдельности. Другой вариант: когда в ПО взаимодействуют не модули и компоненты, а микросервисы.

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

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

Интерфейсное тестирование

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

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

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

Системное тестирование

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

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

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

Приёмочное тестирование

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

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

Дымовое тестирование

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

Когда работы окончены и новая сборка ПО готова, её сначала проверяют путём дымового тестирования (smoke testing). Это название происходит от базового типа тестирования оборудования, при котором проверяют, что оно не загорается при первом включении. При дымовом тестировании определяют, что наиболее важные функции ПО работают, но в мелкие детали не вникают.

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

Если дымовой тест пройден, переходят к более строгим тестам: от модульного к системному, а затем проводят приёмочное тестирование.

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

Тестирование на здравомыслие

Когда новая сборка ПО готова и дымовой тест пройден, проводят тестирование на здравомыслие (sanity testing). Термин часто переводят буквально — как «санитарное тестирование», и такое название используется чаще, чем «тестирование на здравомыслие».

При тестировании на здравомыслие работоспособность ПО проводят детальнее, чем при дымовом. При этом выполняют различные тесты, которые проверяют внесённые изменения.

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

Регрессионное тестирование

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

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

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

Ре-тест

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

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