GraphWalker Model based testing tool какие мнения

инструменты
, ,
#1

Всем привет.

Начал недавно работать с GraphWalker и в целом с Model based testing подходом.
Довольно интересная тема, но удивлён что она мало популярна.

С одной стороны это объясняется тем, что тема не тривиальна, как pairwise или ещё какие-то около научные подходы.
С другой ну уж автоматизаторы то тоже сообразительные люди и могут увидеть выгоды не только в автоматическом исполнении тестов, но и в автоматической генерации.

Вопрос такой, пробовали ли вы этот подход в целом и этот тул в частности, какие впечатления, что не хватило?
Какие мысли по поводу того что эволюция от DDT->KDT->BDD может перейти(переходит) к MBT?

#2

Идея с визуализацией сценариев сама по себе неплохая. Но все упирается во время. Если вы работаете по гибким методологиям, то на подобные творчества с вырисовыванием графов у вас попросту не будет времени. Мы ведь на графе должны отобразить далеко не один сценарий. А это - глубокая аналитическая работа. В примерах то приведены совсем уж тривиальные кейсы. Да и нужно ли нам на самом то деле автоматизировать все отраженные на диаграмме сценарии?

Давайте поразмыслим, а действительно ли заявленные авторами преимущества дадут нам какой-либо профит? Тул генерирует набор пустых методов. Начинку вам все равно придется сформировать самим (элементы взаимодействия / логику). Т.е. в итоге мы тратим кучу времени на моделирование различных сценариев, затем занимаемся имплиментацией самих степов. Не говоря уже о том, что описанный принцип: “шаг-проверка-шаг-проверка” - весьма холиварный.

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

Что в вашем понимании является “автоматическим выполнением”? Вам все так же надо открыть cmd и вбить какие-то ключевые для запуска команды, подобно любой другой run configuration. Тесты, написанные без использования данного тула, ведут себя точно так же.

П.С. Люди, которые выкладывают подобный код, заставляют во многом усомниться.

#3

Я думал тестирование и есть глубокая аналитическая работа.

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

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

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

Например у нас есть датагрид и на него влияют несколько элементов: чекбоксы, дропдаун меню (несколько), поле поиска, фильтры на столбцы и т.д.
Где у нас выпадет ошибка? На одном из элементов или на комбинации? Писать ли все комбинации руками или дать туле сгенерить их?

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

Мы в любом случае занимаемся моделированием сценариев. Только тут мы:

  1. визуализируем их и записываем
  2. вместо повторяемых размышлений “что я записал в тест, а что ещё нет?” мы просим тулу “сгенерируй мне все возможные шаги взаимодействия с функционалом Н в моделе М” или “сгенерируй мне полное покрытие модели К”

Тест это стимуляция системы и проверка результата.
Автоматическое исполнение теста для меня это автоматическая стимуляция системы и проверка результата.

Я бы оценил ссылку на код самого graphwalker, но ссылаться на прототип и пример использования.
Не вызывает уважения. Это как граммар наци.

В целом спасибо за ваше мнение, я так понял что в целом бенефиты тулы и подхода не достаточно подробно и наглядно описаны.
Что и является одним из порогов для входа.

#4

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

"сгенерируй мне все возможные шаги взаимодействия с функционалом Н в моделе М или “сгенерируй мне полное покрытие модели К”

А как же exhaustive testing principle? Кому, скажите на милость, нужны эти всевозможные шаги? И опять же, каково, по-вашему, будет среднее время выполнения тестового набора при таком подходе?

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

#5

Вот этот доклад может прояснить некоторые вопросы по применимости в аджайл

1 лайк
#6

Вот доклад от Авито на эту тему Model Based Testing в связке с Agile development/testing там пока только слайды, видео организаторы обещают вроде как выложить летом 2019.

хороший доклад или нет не знаю, сам еще не копал эту тему.

2 лайка