Функциональное тестирование ПО. Часть 1

Функциональное и ручное тестирование – одно и то же?

Ручное тестирование — это общее понятие. По факту ручное тестирование — это то, что мы делаем в ручном режиме, и можно его выделить как общий класс. Ручное тестирование мы можем выполнять и функционально, чтобы убедиться, что система или продукт соответствуют требованиям. Если говорить простым языком, чаще всего, когда мы говорим о функциональном тестировании, оно выполняется вручную. Конечно, есть и автоматизированное тестирование, но это уже другая тема. При этом можно выделить подклассы. Функциональное тестирование – это проверка соответствия требованиям. Есть ещё подкласс: функционально – интеграционное. Оно позволяет проверить, что работают интеграции двух или более систем. Например, мы должны получить с Яндекс.Погода и их API информацию на наш сайт, чтобы данные попадали под это требование и «болтались тучки». Это будет функциональное тестирование, но при этом оно будет и интеграционное, потому что связано два разных продукта.

Ручным тестированием могут быть все подклассы функционального тестирования: интеграционное, модульное, системное, и тд. И ещё можно множество различных классификаций предложить. Например, в ручном нефункциональном тестировании можно проверять такие вещи как: установку (инсталляционное), конфигурационное, приемочное тестирование (UAT). Приемочное (или UAT – кто как любит называть) подразумевает, что бизнес-заказчики проверяют ПО после всех этапов тестирования, как работает софт по их требованиям. Например, заказчику в Интернет-банке надо кнопку какую-то добавить для расчета ипотеки. Эти пользователи, которые эту кнопку будут фактически использовать, проверяют, как она работает - корректно или нет. Правильно ли реализована их идея, перешла ли их идея в сформулированную цель бизнес-аналитиком, а далее - в нормальное техническое задание или какой-то документ, чтобы это разработал программист. Естественно, когда мы начинаем проводить UAT, то уже все проблемы должны быть решены: документы скорректированы, ошибки в софте исправлены.

Это тоже ручное тестирование по факту. Всё что мы делаем руками и не используем какие-то скрипты и дополнительные средства кода.

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

У заказчиков бывают разные потребности в функциональном тестировании. Есть вариант, когда они приходят со своим решением: понимают, что надо делать и как. Им нужна команда, которая это выполнит. Есть заказчики, которые хотят автотесты: это тренд, панацея для замены ручного тестирования. И когда мы проводим с ними встречи, в итоге приходим к тому, что автоматизировать на данном этапе их софт бесполезно, поскольку они просто «закопают» деньги. На старте без тестовой модели и нормальной документации мы можем написать автотесты, но получит ли заказчик пользу? А смысл автотестов, как и любого тестирования, заключается в том, что это проверка работы софта по требованиям, нахождение дефектов и их последующее исправление. То есть тестирование не ради поиска дефектов, а именно то, что софт соответствует требованиям.


Зачем нужно функциональное тестирование ПО

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

Например, на моей предыдущей работе был очень подробный документ HLA (High Level Architecture). В нем было описано всё максимально подробно, вплоть до: какая XML должна уйти в такой-то API, и что должно быть в результате. Всем было понятно, что требуется доработать\разработать, что и как будет сделано. Если надо что-то уточнить - посмотри HLA, там максимально всё понятно. Однако в любом документе могут быть ошибки. Для этого мы тоже тестируем нестыковки.

У разных заказчиков есть свои стандарты и аббревиатуры для разного уровня документов. Есть BRD (Business Requirement Document) и FSD (Functional specifications document). BRD – это бизнес-требования верхнего уровня. FSD – это функциональные требования, где подробно расписано, не как бизнес это видит, а как это должно работать. Там могут быть макеты, подробное описание бизнес-процессов.

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