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

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

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

Функциональное тестирование изучает вероятность выполнения действия. Например, заказчик занимается доставкой еды. Ему требуется реализовать возможность доставку третьему лицу в качестве подарка. Как раз таки функциональное тестирование это и проверяет. Нефункциональное тестирование может проверить, возможно ли совершить это действие в разных браузерах или в приложении на iOS или Android.

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

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

Первая классификация строится по принципу доступа к продукту.

• Черный ящик – стратегия тестирования, когда специалист не имеет доступа к исходному коду, а осуществляет проверку как рядовой пользователь. Она позволяет определить соответствие ожидаемого результата входным данным.

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

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

• Верхний уровень – такой тип тестирования подразумевает изучение и проверку возможностей интерфейса, насколько он соответствует установленным запросам заказчика.

• Средний уровень – Application Programming Interface, то есть тот контракт, который предоставляется программой или приложением. В этом случае тестировщик обращается напрямую к бекенду в обход пользовательского интерфейса.

• Нижний уровень – проверка базы данных, валидных и невалидных значений в аспекте бизнес–логики.

• Уровень взаимодействия – проверка интеграции, то есть возможности программы взаимодействовать с другими ПО, софтами, приложениями и т.д.

Третий тип классификации строится по принципу использования инструментов.

• Ручное – данный метод не подразумевает использования инструментов автоматизации. Все операции производятся тестировщиком вручную. Результаты во многом зависят от человеческих факторов, таких как внимательность, усидчивость, опытность, то есть смесь hard и soft skills.

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

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

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

1. Этап подготовки.

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

Этот документ формируется вместе с заказчиком и командой разработчиков. На его основе создается весь план работ, в том числе и тестирование.

1. Этап создания тестовой документации.

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

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

1. Этап подготовки тестовых данных.

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

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

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

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

1. Этап составления отчетности.

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

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

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

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

Тест–дизайн.

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

Положительное тестирование.

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

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

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

Отрицательное тестирование.

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

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

Другим примером может служить ситуация, когда пользователь интернет–магазина отказался от товара и система должна произвести автоматический возврат денег. Во время тестирования проверяется, чтобы эта процедура не произошла дважды и магазин не понес убытки из–за возникшей ошибки.

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

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

Предположим, что интернет–магазин увеличивает размер скидки в соответствии с увеличением числа позиций в корзине. То есть, если пользователь добавил два товара, то он получает скидку 15%, если от трех до пяти, то скидка составит 25%, если от пяти до семи, то скидка будет равна 50%.

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

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

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

Техника состояния переходов.

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

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

Попарное тестирование.

Проверка всех вариантов системы по указанным параметрам. Обычно в этом случае тестирование осуществляется вручную.

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

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

Ручное функциональное тестирование.

• TestIT – используется для хранения тест–кейсов, тест–планов, а также дает возможность создавать и реализовывать прогоны.

• Allure – универсальный инструмент, так как помогает в управлении ручным и автоматизированным тестированием. Собирает статистику по результатам проверки. Имеет и другие функции, которые были перечислены выше в других программах.

Проверка баз данных.

• DBeaver – кросс–платформенный инструмент тестирования на безвозмездной основе. Поддерживает работу с различными формами СУБД. Например, такими, как MySQL, MariaDB, PostgreSQL, SQLite и многими другими.

• SQL Developer – является безопасной средой для тестирования с возможностью интеграции и администрирования баз данных. Может применяться в Oracle Database. С ее помощью создаются и проверяются различные запросы для отслеживания ошибок.

Проверка Application Programming Interface.

• Postman – позволяет писать автотесты для API, делать запросы, собирать коллекции и делиться ими с другими пользователями. Данная программа поддерживает различные форматы и виды архитектуры API от HTTP до WebSockets.

• SoapUI – приложение, которое имеет открытый код. Используется для тестирования веб–приложений и передачи состояний представлений. Например, оно позволяет проверить доступность REST–сервиса и отслеживать получение ответа.

Логирование.

• Kibana – программная панель для визуализации данных, тестирования. Позволяет отслеживать тренды и осуществлять прогноз предстоящих событий.

• Graylog – в режиме реального времени дает возможность сохранять данные о логах, чтобы в дальнейшем их анализировать.

Фермы устройств.

• Android Studio – дает возможность создания и управления виртуальных устройств, которые работают на системе Android. Это позволяет проверить работу приложения в различных состояниях.

• Xcode – похожий инструмент, который используется для Apple. Может симулировать как iPod, так и Apple TV. В отличие от Android имитирует не все необходимые функции.

Автоматическое тестирование.

• Selenium – имеет открытый исходный код. Дает возможность автоматизировать процесс проверки веб–приложений на различных операционных системах.

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

• Katalon Studio – ещё один инструмент для проверки мобильных и веб–приложений. Использует языки Java или Groovy для написания тестовых скриптов. Особенно подходит для начинающих тестировщиков.

• Ranorex Studio – один из универсальных инструментов автоматизированного тестирования. Его применяют для проверки настольных, мобильных и веб–приложений в операционных системах и браузерах. Инструмент можно использовать без написания кода, поэтому подойдет для новичков в тестировании.

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