Цели 18-го процесса ГОСТ Р 56939-2024:
Контроль полноты реализованных функциональных возможностей, обнаружение и исправление ошибок с использованием технологий функционального тестирования.
Функциональное тестирование проводится для оценки соответствия ПО заданным функциональным требованиям. Оно проводится по принципу чёрного ящика, в связи с чем функциональность ПО можно протестировать, не зная принципа его внутренней работы.
Включает разные виды тестирования, позволяющие убедиться, что "ПО делает то, что должно делать":
• Ручное тестирование. Производится тестировщиком без использования программных средств для проверки программы или сайта путём моделирования действий пользователя. В роли тестировщиков могут выступать и обычные пользователи, сообщая разработчикам о найденных ошибках.
• Автоматизированное тестирование. Используются программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.
• Дымовое тестирование. Минимальный набор тестов на явные ошибки в основной функциональности. Дымовые тесты позволяют за короткое время определить, готова ли программа к более глубокому тестированию.
• Регрессионное тестирование. Проверка программного обеспечения после внесения изменений (исправлений ошибок, добавления новых функций) с целью убедиться, что новые модификации не нарушили ранее работающую функциональность и не вызвали новых дефектов в других частях системы.
• Юзабилити-тестирование. Выполняется с целью определения, удобен ли некоторый созданный объект (веб-страница, пользовательский интерфейс и т.п.) для его предполагаемого применения.
• Интеграционные тесты. Проверяют взаимодействие и правильную работу двух или более программных модулей, компонентов или систем при их совместной работе. Примером такой проверки может служить тестирование совместимости плагина PVS-Studio с новой версией Qt Creator, которую я описывал в РБПО-039.
Для функционального тестирования PVS-Studio мы больше всего внимания уделяем регрессионным тестам. Это связано с особенностями проекта. Важно следить, что после правки, например, сбора какой-то информации из AST-дерева, не пропадут полезные срабатывания или, наоборот, не вылезут бессмысленные (ложные). Для этого у нас написаны специальные вспомогательные программы, которые запускают анализаторы на наборах открытых проектов (ядра анализаторов и наборы проектов различны для разных языков), а затем позволяют быстро изучать изменения в отчётах, которые выдают ядра анализатора. Если интересно, чуть подробнее познакомиться с нашей внутренней кухней тестирования можно в докладе "Специфика разработки и тестирования статического анализатора".
Тема функционального тестирования большая, хорошо изучена и описана. Более того, почти наверняка вы уже используете в своих проектах различные виды функционального тестирования. Так что речь, скорее всего, идёт не о внедрении чего-то нового, а об усовершенствовании и формализации того, что уже есть. Пришло время написать регламенты тестирования, убедиться, что тестирование выполняется регулярно, а найденные ошибки правильно регистрируются и исправляются.
Дополнительные ссылки:
1. Евгений Балыков. Тестирование программных средств.
2. Блог IBS. Что такое функциональное тестирование?
3. Терминология PVS-Studio: Тестирование.
4. Telegram канал: Тестировщики нужны.
5. Алина Медник. Функциональное тестирование: что это, этапы, виды и инструменты использования.
6. Записи докладов конференции SQA Days (конференция в области обеспечения качества программного обеспечения).
7. Записи докладов конференции Heisenbug (конференция по тестированию программного обеспечения не только для тестировщиков).