BDD с ручными тестами?

Это не очень необычный случай. Даже в Agile может быть невозможно автоматизировать каждый сценарий. Скрам-команды, с которыми я работаю, обычно помечают их как сценарий @manual в файле функций. Мы настроили наш пакет автоматизации (Cucumber — Ruby) на игнорирование этих тегов при выполнении ночных заданий. Одна из проблем с этим, как вы упомянули, заключается в том, что мы не будем знать, каковы были результаты ручных тестов, поскольку тестировщики документируют результаты локально.

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

Надеюсь это поможет.

Чтобы добавить к ответу @Eswar, если вы используете Cucumber (или одного из его братьев и сестер), одним из вариантов будет запуск тестового запуска вручную и включение подсказок тестировщику для проверки определенных аспектов. Затем они проходят / не проходят тест в соответствии со своим суждением.

Это часто полезно для эстетических аспектов, например. кроссбраузерный рендеринг, выравнивание элементов, правильные изображения и т.д.

Как упомянул @Eswar, вы можете исключить эти тесты из своих автоматических прогонов, пометив их.

См. пример в этой статье.

Тест-кейсы, которые нельзя автоматизировать, плохо подходят для теста на огурец. У нас есть куча таких крайних случаев. Практически невозможно заставить Selenium хорошо проверять PDF-документы. То же самое для загрузки CSV (не невозможно, но не стоит усилий). На данный момент тесты «взгляни и почувствуй» просто требуют человеческого глаза. Тестирование доступности с помощью программ чтения с экрана также лучше всего проводить вручную.

Для этого обязательно запишите критерии приемлемости в пользовательской истории любого инструмента, который вы используете для отслеживания рабочих элементов. Напишите ручной тест-кейс. Такие платформы, как Azure DevOps, Jira, IBM Rational Team Concert и им подобные, имеют способы записывать планы ручного тестирования, связывать их с историями и записывать результаты выполнения ручного теста.

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

Иногда нужно просто пойти на компромисс.

Мы используем Azure DevOps с планами тестирования и некоторый пользовательский код для синхронизации огуречных тестов с ADO. Могу описать, как мы реализовали это в наших проектах:

• Сначала начнем с файла огурца. У каждой пользовательской истории есть свой файл функций. Сценарии в Feature являются критериями приемлемости для истории. В итоге у нас получается много Feature-файлов, поэтому мы используем соглашения об именах и папках для их организации.
• Мы аннотируем верхнюю часть файла функций тегом пользовательской истории, например, @Story-1234.
• Мы написали утилиту командной строки, которая читает файлы огурцов с этими тегами. Затем он извлекает все наборы тестов в плане тестирования, которые связаны с историями. В ADO история может быть связана только с одним набором тестов. Если для этой истории не существует комплекта тестов, наш инструмент создает его.
• Для каждого сценария инструмент создает тестовый набор ADO, а затем аннотирует сценарий с идентификатором тестового набора. Это обеспечивает потрясающую отслеживаемость для каждой пользовательской истории, поскольку связанные тестовые случаи автоматически связываются с историей в пользовательском интерфейсе Azure DevOps.
• Хотя мы этого не делаем, мы могли бы заполнить TestCase определениями шагов из нашего сценария огурца. Это базовая структура XML, описывающая шаги, которые нужно предпринять. Это было бы полезно, если бы мы хотели вручную выполнить тестовый пример с помощью пользовательского интерфейса Azure DevOps Test Case. Поскольку мы сосредоточены в первую очередь на автоматизации, мы полагаемся на шаги в наших файлах функций, а наши тестовые примеры ADO в конечном итоге становятся символическими ссылками на сценарии огурца.
• Поскольку наши тесты на огурец написаны на C# (SpecFlow), мы можем получить полное имя класса и метод для кода теста на огурец. Наш инструмент может обновлять тестовый сценарий Azure DevOps, добавляя сведения об автоматизации.
• Любой тестовый пример, который не готов к автоматизации или должен быть выполнен вручную, мы аннотируем Сценарий тегом @ignore или @manual.
• Используя Azure DevOps Pipelines, мы используем тестовую задачу Visual Studio для выполнения наших тестов. Важным моментом здесь является то, что мы выполняем опцию Test Plan. Этот параметр выбирает тестовые случаи в плане тестирования, которые имеют автоматизацию, а затем выполняет определенные тесты огурца. Готовый функционал обновляет статусы Test Case с результатами тестирования.
• После выполнения автоматизации мы используем отчет о плане тестирования в Azure DevOps, который показывает состояние выполнения тестового набора с течением времени и может различать тестовые сценарии, автоматизированные и ручные.
• Мы выполняем все оставшиеся ручные тестовые случаи, чтобы завершить план тестирования.

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

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

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

Вы можете использовать подход, подобный следующему примеру: http://concordion.org/Example.html

Когда вы используете систему сборки или непрерывной интеграции для отслеживания тестовых прогонов, вы можете добавить простые спецификации/тесты для своих ручных случаев, которые содержат текстовое сравнение (например, «пройдено» или «не пройдено»). Затем вам нужно будет обновлять спецификацию после каждого запуска ручного теста, регистрировать ее и запускать тесты в вашей системе сборки/непрерывной интеграции. Затем ручные результаты будут записаны вместе с результатами автоматизированного выполнения теста.

Если вы будете использовать такой инструмент, как Concordion+ (https://code.google.com/p/concordion-plus/) вы даже можете написать сводную спецификацию, которая может содержать сценарии для каждого из ваших ручных тестов. О каждом из них будет сообщаться как об отдельном результате теста в вашей среде выполнения теста.

Ваше здоровье

Делать снимки экрана кажется хорошей идеей, вы все еще можете автоматизировать проверку, но вам придется приложить дополнительные усилия. например, при использовании Selenium вы можете добавить Sikuli (NB: вы не можете запустить безголовый тест), чтобы сравнить результаты (изображения) или сделать снимок экрана с помощью Robot (java.awt), использовать OCR для чтения текста и подтверждения или проверки (TestNG)