Финансовые приложения известны своей сложной природой, включающей многоуровневую функциональность, масштабную интеграцию и пакетную обработку операций в реальном времени с высокой скоростью транзакций. Учитывая все эти тонкости, мобильные банковские приложения следует тестировать очень тщательно, чтобы убедиться, что продукт отвечает требованиям пользователей и остается безопасным.
В этом руководстве мы рассмотрим базовые аспекты тестирования банковских приложений. Также мы приведем практические примеры создания эффективных и управляемых тест-кейсов, которые необходимо включить в тестирование при развертывании приложения. Давайте начнем!
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Что следует и чего не следует делать при написании тест-кейсов
Тест-кейсы должны содержать следующие компоненты:
- Уникальный ID. Каждый тест-кейс должен иметь идентификатор: это облегчает навигацию по тестовым наборам.
- Название и описание. Лаконичное название и краткое описание помогают быстро найти тест-кейс среди других.
- Предусловия. Не имея прямого отношения к тестируемой функциональности, предусловия дают информацию об окружении тест-кейса и предыдущих результатах, создавая необходимый контекст для выполнения теста.
- Шаги воспроизведения. Это шаги, которые должен выполнить тестировщик для достижения ожидаемых результатов.
- Ожидаемый результат. Описание результата, который предполагается после выполнения теста.
Рекомендуется избегать:
- Нечетких формулировок. Следите за тем, чтобы инструкции к тест-кейсу и описание ожидаемых результатов были четкими, краткими и недвусмысленными. Это поможет избежать путаницы или неправильного толкования.
- Зависимости от других тест-кейсов. Проектируйте тест-кейсы так, чтобы они были независимы друг от друга или результатов других тестов. Это способствует гибкости и простоте обслуживания тестов.
- Избыточности или недостатка информации. Соблюдайте баланс, включая в тест-кейс все необходимые детали, но не перегружая его излишней информацией. Это поможет эффективно выполнять и интерпретировать тест.
Важнейшие типы тест-кейсов для тестирования банковских приложений
Тестируя банковские приложения, нельзя упускать из виду несколько основных типов тест-кейсов. Давайте их рассмотрим.
Функциональное тестирование
- Убедитесь, что с использованием валидных данных новые учетные записи успешно созданы.
- Оцените, как ведет себя приложение при создании учетных записей с невалидными данными.
- Протестируйте функциональность входа в систему с невалидными данными.
- Проверьте правильность обновления баланса после выполнения операций.
- Убедитесь, что регулярные платежи сохраняются и выполняются в указанное время.
- Проверьте, можно ли отправлять и анализировать большое количество сообщений.
- Проверьте правильность обработки запросов в службу поддержки.
Тестирование баз данных
- Убедитесь в правильности структуры данных.
- Проверьте правильность формата данных.
- Проверьте точность расчета вычисляемых полей.
- Проверьте, есть ли в каждой таблице необходимые ограничения (внешние ключи, первичные ключи и уникальные индексы).
- Убедитесь, что в таблицах нет дублирующихся или избыточных данных.
- Проверьте правильность использования и обработки нулевых значений.
- Проверьте правильность обработки данных при создании или обновлении профиля.
- Оцените поведение приложения при недоступности сервера базы данных.
- Проверьте сохранность данных.
Тестирование производительности
- Оцените производительность приложения при различных пользовательских нагрузках.
- Протестируйте производительность при различном уровне заряда батареи.
- Проверьте производительность приложения на различных типах и моделях устройств.
- Проверьте работу приложения в условиях медленного соединения.
- Проследите за производительностью приложения во время транзакций и при изменении скорости интернета.
Регрессионное тестирование
- Проверьте соответствие требований и тест-кейсов.
- Сравните текущий релиз с предыдущим, чтобы выявить возможные проблемы.
- Проверьте соблюдение соответствующих стандартов.
- Регулярно пересматривайте и обновляйте наборы регрессионных тестов, удаляя те тесты, которые больше не актуальны, и добавляя новые.
Тестирование доступности
Руководство по обеспечению доступности веб-контента (WCAG) было разработано W3C для установления общепризнанного стандарта. Каждая рекомендация в руководстве имеет тестируемые критерии успеха трех уровней: A, AA и AAA. В основе рекомендаций лежат четыре принципа: воспринимаемость, управляемость, понятность и надежность.
1. Воспринимаемость
- Предоставьте описательные альтернативы для нетекстового контента.
- Убедитесь, что мультимедийный контент содержит субтитры и альтернативные варианты.
- Разрабатывайте контент, который можно гибко представлять с помощью различных методов, включая вспомогательные технологии.
- Улучшите видимость и слуховые ощущения, чтобы сделать контент более доступным для пользователей.
2. Работоспособность
- Убедитесь, что пользователю, использующему исключительно клавиатуру, будут доступны все функции.
- Предоставьте пользователям достаточно времени для чтения и взаимодействия с контентом.
- Избегайте использования контента, который может вызвать судороги или иные физические реакции.
- Облегчите навигацию и поиск контента для пользователя.
- Улучшите удобство работы с другими устройствами ввода, помимо клавиатуры.
3. Понятность
- Убедитесь, что текст разборчив и понятен.
- Убедитесь, что контент ведет себя последовательно и предсказуемо.
- Окажите помощь пользователям в предотвращении и исправлении ошибок.
4. Надежность
- Оптимизируйте совместимость с существующими пользовательскими инструментами.
Тестирование безопасности
- Проверьте реакцию приложения на несколько попыток входа в систему.
- Оцените эффективность функциональности ”Забыли пароль” для быстрого восстановления данных учетной записи.
- Оцените надежность требований к паролям.
- Убедитесь, что ID пользователей и пароли зашифрованы.
- Убедитесь, что приложение использует безопасный протокол, например HTTPS.
- Проверьте, что пароль маскируется при его вводе пользователем (например, скрывается под точками или другими символами).
- Проверьте меры защиты от бессрочных сеансов входа пользователей в систему.
- Проверьте реакцию приложения на очистку кэша.
Приемочное пользовательское тестирование
- Проверьте интуитивность и настраиваемость навигации в пользовательском интерфейсе.
- Проверьте согласованность шрифтовых и цветовых схем, чтобы обеспечить единство визуальных элементов.
- Проверьте, насколько единообразно используется язык на всех страницах приложения.
- Убедитесь, что все ссылки и кнопки имеют понятные и описательные названия.
- Убедитесь, что сообщения об ошибках и предупреждениях понятны для пользователей.
Примеры тест-кейсов для банковских приложений
Хотя универсального тест-кейса для банковской сферы не существует, все же есть различные примеры, к которым можно обращаться как к образцам для проведения эффективного тестирования. Вот несколько примеров того, что можно протестировать в банковской сфере.
Верификация администратора
- Проверьте вход администратора в систему с валидными данными.
- Проверьте вход администратора в систему с невалидными данными.
- Проверьте возможность входа администратора в систему без предоставления каких-либо данных.
- Проверьте функциональность всех домашних ссылок администратора.
- Проверьте функциональность смены пароля администратора.
- Проверьте смену пароля администратора с использованием невалидных данных.
- Проверьте смену пароля администратора без предоставления каких-либо данных.
- Проверьте смену пароля администратора с использованием существующих данных.
- Проверьте выход администратора из системы.
Верификация новых пользователей
- Создайте нового пользователя с валидными / невалидными данными.
- Создайте нового пользователя без предоставления каких-либо данных.
- Проверьте опции отмены и восстановления.
- Обновите пользователя с валидными / невалидными данными.
- Обновите пользователя с помощью существующих данных.
- Проверьте функцию удаления пользователя.
Верификация клиентов и посетителей
- Проверьте существующие связи между клиентом и посетителем.
- Проверьте аутентификацию клиента с помощью валидных и невалидных данных, а также без ввода данных.
- Проверьте вход в систему с помощью с помощью валидных и невалидных данных, а также без ввода данных.
Верификация новой роли
- Создайте новую роль с валидными / невалидными / существующими данными.
- Проверьте параметры отмены и воостановления.
- Валидируйте тип роли и ее описание.
- Проверьте удаление роли с зависимостями и без них.
- Проверьте подлинность существующих ссылок на странице сведений о роли.
Заключение
Разработка тест-кейсов для финансовых приложений может быть сопряжена с определенными трудностями из-за таких факторов, как уникальная среда развертывания, строгие требования к соответствию политикам и сложные тестовые сценарии. Именно здесь опыт команды тестировщиков, специализирующейся в области банковского сектора, становится решающим фактором в обеспечении высочайшего качества вашего финансового программного обеспечения.
Перевод статьи «Essential Test Case Types for Testing Financial Applications».