Тестирование графических пользовательских интерфейсов — непростая задача. Полная автоматизация привлекательна, но дорога и не дает хороших результатов. Пользовательский интерфейс — это то, в чем должен участвовать настоящий человек. Используя расширенное тестовое приложение, мы можем эффективно использовать ручное тестирование.
Я обсуждал этот подход к тестированию в подкасте на TestTalks. Это более глубокое исследование этой темы.
Приложение для ручного тестирования
Настоящие тестировщики, люди, обладают удивительной способностью выявлять проблемы. Человек не связан ограниченным количеством проверок, которые выполняет автоматизированный скрипт. Вместо этого они постоянно следят за любыми проблемами макета, графическими сбоями, странностями данных, проблемами с производительностью, сломанным дизайном и поверхностным взаимодействием с пользователем. Вспомогательное ручное тестирование использует эту возможность.
Приложение для ручного тестирования — это пользовательская программа, созданная специально для ручного тестирования. Приложение представляет несколько шагов, которые будет выполнять реальный человек. У нас в Fuse есть три таких приложения.
Наше основное тестовое приложение называется просто «ручное тестовое приложение». Тестировщик устанавливает его на любую из поддерживаемых нами платформ и следует инструкциям в тесте. В нем чуть более 40 страниц, которые охватывают широкий спектр функций, которые мы предлагаем.
Автономные блоки
Каждая страница представляет собой изолированный тест, предотвращающий утечку ошибок на одной странице в другой тест. Мы не хотим, чтобы тестер регистрировал цепочку проблем для одного дефекта.
Обратите внимание на маленький рисунок i в правом верхнем углу. Это инструкции тестировщику для каждой страницы: что делать и чего ожидать. Это устраняет необходимость предоставления длинного тестового сценария. Поддержка сценариев требует значительных затрат в большинстве случаев ручного тестирования, поэтому лучше их избегать.
Мы не хотим, чтобы тестер читал эти инструкции каждый раз, когда он запускает приложение, и мы не хотим, чтобы он посвящал слишком много места мозгу для понимания тестов. Многие тесты говорят сами за себя или очевидны. Тестировщику может потребоваться прочитать инструкции только в первый раз или обратиться к ним, когда произойдет что-то подозрительное.
Только неавтоматизированное
Для создания расширенного тестового приложения требуется достаточно модульная конструкция программного обеспечения. Нам нужно использовать все функции тестового приложения. Здесь нам не нужно беспокоиться о дополнительных усилиях, поскольку модульность — это просто хорошая практика разработки, независимо от тестирования.
Тестовое приложение не должно быть свалкой. Мы хотим включить тесты только в тех случаях, когда набор глазных яблок полезен. Сосредоточьтесь на вещах, которые человек может обработать, но для которых было бы сложно написать модульный тест. Хорошими кандидатами являются функции с визуальными эффектами, анимацией или взаимодействием с пользователем.
Сначала заманчиво все протестировать в ручном тестовом приложении. В краткосрочной перспективе может показаться, что это снижает усилия программиста, но вредит усилиям по тестированию. Если есть слишком много похожих тестов или слишком много тестов, тестировщику будет труднее выявить проблемы. Они вынуждены чаще обращаться к инструкции и с трудом запоминают то, что видели в прошлый раз. Это замедляет тестировщика и затрудняет его способность выявлять дефекты.
Ручные тесты также не должны вести себя как модульные тесты. Мы не пытаемся изолировать одну функцию и не пытаемся сделать исчерпывающий охват API. Мы уменьшаем общее количество тестов, объединяя несколько функций на одной странице. Тестер использует свою удивительную биологическую нейронную сеть для одновременной обработки многих вещей.
Проблемы и многое другое
Хорошо написанное вспомогательное тестовое приложение должно быть включено в любое приложение с графическим пользовательским интерфейсом. Это дает нам преимущество в том, что реальный человек анализирует приложение без необходимости поддерживать дорогостоящие тестовые сценарии. Это позволяет избежать бремени и снижения затрат, связанных с автоматическими тестами пользовательского интерфейса.
Даже программисты могут использовать приложение, чтобы быстро убедиться, что их изменения не нарушили что-то очевидное. Помещенный в руки специального тестировщика, он производит надежный регрессионный тест. Это благо для качества программного обеспечения.
