Связь между модульным тестированием и сквозным (интеграция как таковая) при выполнении BDD

Question

Мой вопрос также связан с тем, кто что делает в типичном BDD.Насколько я понимаю, владелец продукта придумывает User Story (может или не может быть в Gherkin), QA пишет сценарии для сквозного тестирования (в файлах компонентов), Dev пишет свой код (как и где, он также следует BDD?).На этом этапе, если разработчик пишет автоматическое модульное тестирование, может ли оно быть использовано QA для сквозного тестирования или они могут быть абсолютно разными?

Мой вопрос заключается в том, как Dev и QA используют работу друг друга с точки зрения кодирования при выполнении BDD.Я не уверен, как соединить точки.

Давайте возьмем пример приложения на основе JAVA, и QA уже использует Cucumber с Selenium Webdriver для автоматического тестирования.

Answer 1

Как насчет однорангового программирования BDD / TDD между разработчиками Dev и QA, результатом которого является автоматизация тестирования e2e.

Это может повлечь за собой

1. сервисов E2e и автоматизацию развертывания приложений (один раз -идеально для работы на любом портативном компьютере)
2. Настройка варианта использования
   • настройка режима поведения приложения (обновить схему данных / базы данных в хранилище данных / базе данных, файлы конфигурации, если функция использует ключ)
   • выбрать четкое определение для ввода и вывода поведения
   • определить триггер функции и правило проверки
   • реализовать логику приложения
   • проверить правило проверки с помощью реализованной логики

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

Answer 2

Я работаю в проекте, использующем BDD.Когда BA создает заявку и записывает все сценарии, она назначается разработчику.Между тем QA также создает QA-билет для работы, относящейся к этому DEV-билету.Но QA начнет писать тест автоматизации только тогда, когда код билета DEV находится на рассмотрении или уже готов.Это потому, что функция должна быть доступна для тестирования.когда QA начинает кодирование, все модульные тесты для этого тикета должны быть выполнены.Таким образом, чтобы усилить работу DEV и QA, мы предложили решение.Хотя это в пилотной, не официальной заявке.QA должен участвовать в проверке юнит-тестов.Это означает, что он / она должен посмотреть на все юнит-тесты и дать комментарий, если он / она думает, что нужно добавить или удалить еще несколько случаев.А также QA может получить тестовое покрытие в модульном тестировании и принять решение о написании автоматических тестов в соответствии с этим покрытием.Здесь QA нужно активно привлекать и решать, что тестировать в e2e.Было бы проще, если бы вы могли обсудить с разработчиком лицом к лицу покрытие модульных тестов, но я думаю, что более объективно пересмотреть код.Также f2f, а не любой DEV, желающий рассказать QA, какова его работа.Однако это решение требует больше навыков инженера по обеспечению качества.Не любой QA может читать и понимать код DEV.

Это идея, которую наша команда по обеспечению качества дала в текущем проекте, я не знаю, применяет ли это какой-либо проект.Это действительно хороший вопрос.Я также хочу услышать больше мнений / идей от других людей, которые также хотят использовать работу QA и DEV.

Answer 3

Если вы практикуете BDD, вы сначала должны создать спецификации (определить поведение ), а затем реализовать это поведение (т. Е. Написать производственный код).На каком уровне вы определяете поведение менее актуально, хотя на уровне модульного теста большинство людей назвали бы это «TDD» (хотя это не обязательно тестирование, поскольку «тест» - это дизайн кода, который вы хотите написать).Разработчик и QA будут сотрудничать в определении поведения и реализации тестов и производственного кода.В идеале, я бы ожидал разные тесты на разных уровнях, последний (самый высокий) уровень - это тесты E2E.Я также хотел бы не проверять все на каждом уровне, а проверять только то, что имеет смысл на этом уровне.Например: метод, который вычисляет значение, должен подвергаться модульному тестированию, как это значение отображается во внешнем интерфейсе, будет проверяться во внешнем интерфейсе (все еще может быть модульным тестом), как получить значение из внутреннего интерфейса было быинтеграционный тест и т. д. Вам может быть интересно узнать больше о BDD здесь: https://docs.cucumber.io/bdd/, в любом из связанных постов здесь: https://docs.cucumber.io/community/blog-posts/ или в Книге огурцов / Книге огурцов для Java.