Тест-кейсы для тестирования банковских приложений

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

В этом руководстве мы рассмотрим базовые аспекты тестирования банковских приложений. Также мы приведем практические примеры создания эффективных и управляемых тест-кейсов, которые необходимо включить в тестирование при развертывании приложения. Давайте начнем!

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

Что следует и чего не следует делать при написании тест-кейсов

Тест-кейсы должны содержать следующие компоненты:

Уникальный ID. Каждый тест-кейс должен иметь идентификатор: это облегчает навигацию по тестовым наборам.
Название и описание. Лаконичное название и краткое описание помогают быстро найти тест-кейс среди других.
Предусловия. Не имея прямого отношения к тестируемой функциональности, предусловия дают информацию об окружении тест-кейса и предыдущих результатах, создавая необходимый контекст для выполнения теста.
Шаги воспроизведения. Это шаги, которые должен выполнить тестировщик для достижения ожидаемых результатов.
Ожидаемый результат. Описание результата, который предполагается после выполнения теста.

Рекомендуется избегать:

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

Важнейшие типы тест-кейсов для тестирования банковских приложений

Тестируя банковские приложения, нельзя упускать из виду несколько основных типов тест-кейсов. Давайте их рассмотрим.

Функциональное тестирование

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

Тестирование баз данных

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

Тестирование производительности

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

Регрессионное тестирование

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

Тестирование доступности

Руководство по обеспечению доступности веб-контента (WCAG) было разработано W3C для установления общепризнанного стандарта. Каждая рекомендация в руководстве имеет тестируемые критерии успеха трех уровней: A, AA и AAA. В основе рекомендаций лежат четыре принципа: воспринимаемость, управляемость, понятность и надежность.

1. Воспринимаемость

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

2. Работоспособность

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

3. Понятность

Убедитесь, что текст разборчив и понятен.
Убедитесь, что контент ведет себя последовательно и предсказуемо.
Окажите помощь пользователям в предотвращении и исправлении ошибок.

4. Надежность

Оптимизируйте совместимость с существующими пользовательскими инструментами.

Тестирование безопасности

Проверьте реакцию приложения на несколько попыток входа в систему.
Оцените эффективность функциональности ”Забыли пароль” для быстрого восстановления данных учетной записи.
Оцените надежность требований к паролям.
Убедитесь, что ID пользователей и пароли зашифрованы.
Убедитесь, что приложение использует безопасный протокол, например HTTPS.
Проверьте, что пароль маскируется при его вводе пользователем (например, скрывается под точками или другими символами).
Проверьте меры защиты от бессрочных сеансов входа пользователей в систему.
Проверьте реакцию приложения на очистку кэша.

Приемочное пользовательское тестирование

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

Примеры тест-кейсов для банковских приложений

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

Верификация администратора

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

Верификация новых пользователей

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

Верификация клиентов и посетителей

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

Верификация новой роли

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

Заключение

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

Перевод статьи «Essential Test Case Types for Testing Financial Applications».