Функциональное тестирование: задачи, виды, методы, цели

Содержание:

• Понятие функционального тестирования программного обеспечения
• Разница между функциональным и нефункциональным тестированием
• Этапы функционального тестирования
• Виды функционального тестирования
• Тест-дизайн: что это и как его применять
• Инструменты для функционального тестирования
• Роль QA Service Lab в функциональном тестировании

Понятие функционального тестирования программного обеспечения

В статье мы постараемся рассказать простым и понятным языком для чего проводится функциональное тестирование. Вы, как пользователь, от любого нового приобретения ждете какого-то конкретного списка способностей, действий. К примеру, часы должны показывать время. Но могут они отображать и дату. Механические часы могут быть снабжены секундомером или тахометром. Электронные часы могут измерить атмосферное давление и показать высоту над уровнем моря. И, перед покупкой, вы изучаете у моделей наличие конкретных функций, необходимых именно вам. Разумеется, вы хотите быть уверенными в том, что те же часы не будут отставать или отображать неверные данные. Ответственный производитель в полной мере разделяет ваше желание получить качественные часы. Выпуск качественного продукта требует гарантий того, что его функционал соответствует требованиям. Для этого продукт проходит несколько этапов проверки: к примеру, на стадии подготовки документации, проектирования, сборки и выпуска.

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

Разница между функциональным и нефункциональным тестированием

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

Начнем с того, что наиболее полную картину ключевых функций ПО должен знать его заказчик. Согласно именно его видению специалисты (например, системные аналитики) составляют техническое задание для разработчика, по которому тот и делает будущий продукт. И с этой же документацией предстоит работать и тестировщику. Он должен будет проверить работу каждой функции, включая все тонкости и нюансы. Ошибки в работе ПО могут стоить не только времени и нервов, но и репутации, денег, а в самых мрачных случаях — и жизни. К примеру, знаменитая ошибка плавающей запятой в процессоре Pentium лишила компанию Intel 475 миллионов долларов. Или не менее известная история, когда одно из не протестированных должным образом обновлений сайта Amazon, в ранние его годы, позволило заказывать отрицательное количество товаров. Т.е. при таких покупках, деньги не списывались со счета, а наоборот, пересчитывались на карту пользователя. Этого бы не случилось, если продукт был бы должным образом протестирован.

Подготовка, проведение и отчет — важнейшие этапы функционального тестирования

Что входит в функциональное тестирование? Разумеется, начать вам нужно с анализа исходной документации о системе. Попросите у заказчика максимум данных — это сильно упростит дальнейшую работу. Это могут быть функциональные и бизнес-требования, подробное ТЗ, паспорт проекта, ожидаемые сценарии использования системы. Основные этапы подготовки – это разработка и согласование плана тестирования, тест-кейсов, согласование проектных сроков, числа итераций, оценка возможных рисков.

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

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

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

В мире функционального тестирования есть место для множества видов в рамках разных классификаций. Разные подходы возникли благодаря тому, что один и тот же функционал можно рассмотреть с разных точек зрения. Есть ли у тестировщика доступ к внутреннему устройству приложения, или ему доступен только пользовательский интерфейс, как конечному пользователю? Из каких элементов состоит приложение? А как эти элементы группируются? Какие зависимости есть между элементами и группами? А между модулями? Между приложением, как единым целым и другими сервисами? Без решения каких задач приложение становится нежизнеспособным? Ответы на эти и другие вопросы породили разные подходы в рамках функционального тестирования.

Метод «черного ящика» и метод «белого ящика» как Инь и Янь мира тестирования. Это подходы к тестированию, которые кардинально отличаются уровнем доступа к продукту.  Самый частый вид — метод «чёрного ящика» — это тестирование без доступа к исходному коду. В этом случае тестировщик «притворяется» простым пользователем и проверяет приложение, исходя из этой логики. А вот метод «белого ящика» подразумевает доступ к самому коду приложения, его внутренней структуре и реализации логики и функций, чтобы тестировщик понимал, как приложение работает изнутри. Для проведения такого типа функционального тестирования, к тестировщикам предъявляются гораздо более высокие требования к квалификации и опыту.

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

Для того, чтобы уверенно подходить к выбору и осуществлению проверок, начинающему тестировщику необходимо понимать различные подходы и методики проведения функционального тестирования. Вот некоторые из них:

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

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

Один из основных видов функционального тестирования обладает необычным называнием smoke-тестирование (в различных версиях может быть как английское smoke testing, так и русская калька «дымовое тестирование»). Если коротко, то это проверка критически важных функций ПО. Сразу ответим на популярный вопрос о возникновении данного названия— единой версии нет, но нам нравится вариант инженеров-электротехников: если при подаче питания на свежую собранную плату идет дым, это плохой знак. Значит что-то спаяно или собранно с дефектами. И если такая проверка не пройдена – дальнейшее тестирование не имеет смысла.

Кстати, новички часто путают smoke-тестирование с sanity-тестированием, но это немного разные понятия — второе подразумевает полноценный тест какого-то отдельного модуля приложения «от и до», не затрагивая остальные, и выполняется такая проверка иногда и перед «дымовым тестированием».

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

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

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

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

Тест-дизайн: что это и как его применять

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

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

Есть подтвержденная теория о том, что при разработке ПО, ошибки скапливаются на границах использования классов эквивалентности, о которых упоминается выше. Протестировать такие зоны помогает техника граничных значений. К примеру, есть требование: «Покупатель получает скидку после каждого десятого товара». Данное требование может быть очень неоднозначно воспринято: скидка должна быть именно на десятый товар, или же, следующий за ним, то есть одиннадцатый? Скидка каждый раз одинаковая, либо растет? И таких вопросов очень много.

Техника состояния переходов —используется для сложных систем, к примеру, CRM-сервисов. Представьте, что есть некий юнит, который внутри такой сложной системы постоянно меняет свое состояние. Хороший пример — товар интернет-магазина, который может быть на складе, а может не быть, может находиться по пути к покупателю, а может быть в стадии возврата. У каждого из таких сценариев есть логические цепочки состояний, по которым этот юнит перемещается. К примеру, он не может появиться в доставке без регистрации на складе. Задача тестировщика — проверить все цепочки, отслеживая, соблюдаются ли все шаги, нет ли пропусков или мест, блокирующих перемещение юнита по цепочке.

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

Инструменты для функционального тестирования

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

• Системы управления тестированием или TMS (test management system) — системы, которые позволяют в одном месте хранить и тест кейсы и другие артефакты по процессу тестирования, позволяя наглядно представить текущее состояние продукта. В качестве примера можно назвать Test IT, Test Rail, Test Link — которые помогут удобно составлять тест-планы, создавать прогоны, хранить тест-кейсы.
• Часть системы из предыдущего пункта, также включают в себя функционал баг-трекеров – системы, которые позволяют фиксировать задачи на разработку и найденные проблемы и отслеживать их жизненный цикл. Например, GitLab, Redmine и многие другие.
• Базы данных являются неотъемлемой частью функционального тестирования. В зависимости от того, какие базы данных используются для реализации продукта, нужно подобрать клиент для взаимодействия с ними. Чаще всего, речь идет про реляционные базы данных, где данные хранятся в виде таблиц, а доступ к данным осуществляется с помощью SQL – языка запросов к структурированным данным. Большинство СУБД имеют свои собственные инструменты, заточенные именно под эти системы, однако есть и универсальные решения, например: HeidiSQL и DBeaver.
• DevTools — инструмент, встроенный в практически любой современный веб браузер. Он используется для тестирования фронтенда в рамках браузера и позволяет выполнять множество полезных операций, например, посмотреть, какие запросы уходят на бекэнд и какие скрипты выполняются.
• Для проведения проверок интеграций между сервисами потребуются отдельные инструменты, с помощью которых можно смоделировать запросы от одного сервиса к другому. Для тестирования REST API (application programming interface, интерфейс программирования приложений) широко распространено использование Postman, SoapUI, Swagger UI, хотя эти же инструменты можно использовать и для работы с другими интеграциями.
• Для работы с логами, зачастую достаточно текстового редактора с расширенным функционалом поиска, например Notepad++, а когда логов на проекте много – их агрегируют в специальных системах, таких как Kibana или Graylog

Роль QA Service Lab в функциональном тестировании

Функциональное тестирование — это одно из основных направлений проверок для любого программного обеспечения. В 95% своих проектов компания QA Service Lab проводит различные вариации функционального тестирования.

Вне зависимости от того, с чем мы имеем дело (веб, мобильное или десктопное программное обеспечение), основное, ради чего оно создавалось — это бизнес-логика, реализация потребностей заказчиков и их клиентов. Именно это и проверяет функциональное тестирование.

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