Одновременное функциональное и нефункциональное тестирование

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

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

БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"

Содержание:

• Различия между тестированием производительности и функциональным тестированием
• Почему функциональное тестирование и тестирование производительности должны проводиться одновременно?
• Пример из практики
• Заключение

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

	Функциональное тестирование	Тестирование производительности
1	Сравнивается фактический отклик системы на определенные входные данные с ожидаемым результатом	Проверяется работа системы при различных условиях нагрузки
2	Может быть ручным или автоматизированным	Как правило автоматизируется
3	Один пользователь выполняет все операции	Несколько пользователей выполняют нужные операции
4	Требуется участие заказчика, тестировщика и разработчика	Требуется участие заказчика, тестировщика, разработчика, администратора баз данных
5	Тестирование может проходить вне продакшн-окружения, а требования к аппаратному обеспечению минимальны	Требуются тестовая среда максимально близкая к продакшн-окружению и специализированное аппаратное обеспечение для воспроизведения нагрузки

Почему функциональное тестирование и тестирование производительности должны проводиться одновременно?

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

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

Ниже приведен разговор между тест-менеджером и тестировщиком:

(Тест-менеджер – ТМ, тестировщик – Т)

ТМ: Привет… Как дела с тестированием продукта А?

Т: Все отлично, мы довольно быстро продвигаемся.

ТМ: Здорово… А как обстоят дела с тестированием производительности?

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

Из приведенного выше разговора следует несколько вопросов:

• Зависит ли функциональное тестирование от производительности?
• Что если производительность ПО снижена, но выпуск продукта происходит в отсутствие данной проверки?
• Может ли тестирование производительности осуществляться в процессе функционального тестирования?

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

Программное обеспечение работает на основе различных архитектур и моделей:

1. Модели, основанные на ожидании обязательного ответа
2. Системы, основанные на транзакциях
3. Системы на основе нагрузки
4. Системы на основе репликации данных

Функциональное тестирование вышеупомянутой систематической модели зависит от производительности системы.

При автоматизации требуется уделять особое внимания к тестированию производительности.

Ниже приведен разговор между клиентом и тест-менеджером.

(Клиент – К, Тест-менеджер – ТМ)

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

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

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

ТМ: Именно. Мы проработаем его и вернемся к вам для утверждения.

Из приведенного выше разговора ясно, что клиентам необходима оптимизация эффективности тестирования.

Практический пример

Компания ABC работает над проектом по разработке ПО А. Тестированием ПО А занимается компания XYZ.

В договоре между компаниями ABC и XYZ предусмотрены некоторые ограничения на их сотрудничество. Любые обсуждения между ними должны происходить раз в неделю или три раза в месяц. Система работает по модели запрос-ответ. Компания ABC завершила фазу разработки.

Настало время для компании XYZ провести функциональное тестирование ПО А. XYZ начинает работу по тестированию. По заключению XYZ после двух циклов тестирования ПО А допущено к релизу.

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

Так в чем же проблема?

• В ограниченном взаимодействии между командой разработчиков и тестировщиков?
• В том, что требования не были ясны на 100%?
• В том, что продукт не был протестирован в надлежащей тестовой среде?
• Или есть какие-то другие причины?

После тщательного исследования и анализа были сделаны следующие выводы:

1. Несколько зависимых и взаимозависимых приложений испытывали проблемы с производительностью при получении ответов.
2. Использованные тестовые данные не были достаточно точными
3. Надежность программного обеспечения не была обеспечена должным образом.
4. Существовали проблемы с синхронизацией между несколькими независимыми приложениями.
5. В ходе тестирования в ПО вносились изменения, которые не были учтены.

Поэтому после того, как группа планирования корректирующих действий приступила к работе, было предложено следующее:

1. Усилить коммуникацию и сотрудничество между командой разработки и командой тестирования
2. Включить все зависимые приложения в системное функциональное тестирование для выявления и устранения проблем интеграции или совместимости.
3. Увеличить значения времени ожидания запроса и ответа для создания комфортных условий для тестирования в не-продуктовых средах.
4. Использовать в функциональном тестировании разнообразные входные данные, от простых до сложных.
5. Особое внимание уделить нефункциональному тестированию, особенно производительности и нагрузочному тестированию.
6. Проводить интеграционное тестирование системы дополнительно к системному тестированию для проверки взаимодействия различных компонентов и подсистем.
7. Обеспечить минимальный промежуток времени между итерациями тестирования для повторного тестирования ранее выявленных ошибок.
8. Гарантировать, что все ошибки, выявленные в предыдущих итерациях тестирования, будут устранены и проверены в текущей итерации.

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

Наблюдения:

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

Заключение

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

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

Перевод статьи «Functional Testing Vs Performance Testing: Should It Be Done Simultaneously?».