АБ
можно еще и код построчно оплачивать...
Size: a a a
2020 November 11
R(
я понимаю (ТЕОРЕТИЧЕСКИ), что bdd может работать (ТЕОРЕТИЧЕСКИ!) при условии написания требований бизнесом в таком стиле.
https://seleniumcamp.com/archive/selenium-camp-2013/materials/cucumber/ — ну вот тут Дзыня (пересекался с ним когда оба работали в Ciklum) рассказывал почему БДД может работать — для согласования сценариев (но это не "только бизнесом".
DS
И до пятницы ждать не стал. Как можно? :)
завтра выходной для значительного числа русскоязычных айтишников, стало быть сегодня пятница на минималках
R(
Просто у меня тут в соседнем отделе проскочила идея "давайте делать bdd, чтобы ручным тестировщикам было проще писать тесты", и она мне ОЧЕНЬ не нравится уже на этом этапе.
АБ
Спасибо большое всем за ответы, пойду проникаться.
R(
Просто у меня тут в соседнем отделе проскочила идея "давайте делать bdd, чтобы ручным тестировщикам было проще писать тесты", и она мне ОЧЕНЬ не нравится уже на этом этапе.
Из предыдущих БДД срачей.
) BDD это язык. Это новый язык, его реализовать вам, а не сделают за вас. В любом случае это overhead — “нагрузка”: вы создаете второй, “человеческий” язык для описания того что и так будет описано кодом. Я видел отзывы что это может хорошо работать, но лично видел только как это работает плохо.
) Нужен “централизованый орган”, который этот язык будет стандартизировать и поддерживать. Например, из статьи о BDD в “Тинькофф”: “Мы остановились на описании полной иерархии страниц и их элементов…” — это полное описание живет и работает где-то централизованной группой.
Если вы сразу видите что полное описание страниц/экранов и элементов может потянуть на много-много-много страниц и времени, то скорее всего затрат на BDD у вас будет больше чем пользы.
) BDD лишь ограниченно соответствует алгоритмическим языкам. Это “линейный” язык (сценарии линейны), без условных операторов, циклов и пр. Есть мнение что так и надо, есть мнение что это далеко не всегда хорошо (я придерживаюсь последнего). Т.е. нужно придумывать какому коду будут соответствовать фразы BDD, как это реализовать.
) Этот язык требует обучения и коммуникаций. Нельзя просто так взять и писать на Геркине что попало — сначала надо посмотреть и согласовать что уже написано, как и в каких терминах оно написано, всяко стремиться к повторному использованию (reuse). Если у вас нет много повторного использования, BDD, опять же, может значить для вас больше проблем чем решений.
) Если у вас, скажем, всего два-три автоматизатора, вполне возможно что они в этом загрузнут по уши (это было причиной отказа от BDD в тех случаях где я это видел).
) BDD нужна техническая поддержка, и значительная (в вышеупомянутой статье от Тинькоффа описано сколько им пришлось дорабатывать — свой плагин, база локаторов (языка), база BBD-фраз (видна на демо-анимациях), база тестовых данных…
Для небольшой команды усилия по BDD скорее всего того не стоят: они значительны, а эффект может оказаться меньше потраченных усилий (также см. ниже).
) Если ваша продуктовая палитра содержит “много всего”, например веб-портал, пару мобильных приложений, веб-приложение отличное от портала… — вам будет тяжело работать с BDD, потому что нужно много-много языковых элементов.
) BDD не обязательно ускоряет, или опережает. Цитируя опять же статью от Тинькоффа, “Классический вариант {x}DD, когда изначально пишутся все тесты, и только потом начинается непосредственная разработка, в изначальных наших условиях сильно повлиял бы на наш быстрый релизный цикл, что для банковских сервисов непозволительная роскошь.”
Если вам критично что-то зарелизить быстро, вам нужна либо мощная поддержка которая будет быстро писать переводы кода на BDD язык, либо BDD вам для быстрого релиза не нужно. Если вы делаете новый функционал, который надо одновременно исследовать и тестировать как он работает (у меня такое было вот недавно) — Вам BDD тоже вряд ли нужен.
Опыт из которого это написано: три проекта где пытались внедрять BDD.
Очень сложная и разноплановая предметная область, сотни разных приложений и экранов. Туда вообще было бы лучше не соваться с BDD. Итого: BDD выкинуто.
Реализация через BDD (Specflow) формально работала, но ничем не помогла. Вина тут скорее была не BDD а сложности тестируемой системы и проблем с ее аппаратной, но особенно програмной частью (свой проприетарный сервер, своеобразная реализация с использованием Appium). Не расширив особо ни фич ни покрытия, проект закрылся.
Опять таки разноплановая предметная область, хотя и не такая архисложная как в случае 1, но большая. Поддержка BDD требовала значительных отдельных ресурсов программистов, BDD-описания кейсов выходили большими, сложными, непонятными. На него перестали выделять ресурсы и благополучно похоронили. Т.е. хотели “кейсы на BDD читабельные для всех”, а получилось “ни для кого”.
Статья про опыт Тинькова: https://habr.com/company/tinkoff/blog/322688/
Я полагаю что основные проблемы BDD это
) BDD это язык. Это новый язык, его реализовать вам, а не сделают за вас. В любом случае это overhead — “нагрузка”: вы создаете второй, “человеческий” язык для описания того что и так будет описано кодом. Я видел отзывы что это может хорошо работать, но лично видел только как это работает плохо.
) Нужен “централизованый орган”, который этот язык будет стандартизировать и поддерживать. Например, из статьи о BDD в “Тинькофф”: “Мы остановились на описании полной иерархии страниц и их элементов…” — это полное описание живет и работает где-то централизованной группой.
Если вы сразу видите что полное описание страниц/экранов и элементов может потянуть на много-много-много страниц и времени, то скорее всего затрат на BDD у вас будет больше чем пользы.
) BDD лишь ограниченно соответствует алгоритмическим языкам. Это “линейный” язык (сценарии линейны), без условных операторов, циклов и пр. Есть мнение что так и надо, есть мнение что это далеко не всегда хорошо (я придерживаюсь последнего). Т.е. нужно придумывать какому коду будут соответствовать фразы BDD, как это реализовать.
) Этот язык требует обучения и коммуникаций. Нельзя просто так взять и писать на Геркине что попало — сначала надо посмотреть и согласовать что уже написано, как и в каких терминах оно написано, всяко стремиться к повторному использованию (reuse). Если у вас нет много повторного использования, BDD, опять же, может значить для вас больше проблем чем решений.
) Если у вас, скажем, всего два-три автоматизатора, вполне возможно что они в этом загрузнут по уши (это было причиной отказа от BDD в тех случаях где я это видел).
) BDD нужна техническая поддержка, и значительная (в вышеупомянутой статье от Тинькоффа описано сколько им пришлось дорабатывать — свой плагин, база локаторов (языка), база BBD-фраз (видна на демо-анимациях), база тестовых данных…
Для небольшой команды усилия по BDD скорее всего того не стоят: они значительны, а эффект может оказаться меньше потраченных усилий (также см. ниже).
) Если ваша продуктовая палитра содержит “много всего”, например веб-портал, пару мобильных приложений, веб-приложение отличное от портала… — вам будет тяжело работать с BDD, потому что нужно много-много языковых элементов.
) BDD не обязательно ускоряет, или опережает. Цитируя опять же статью от Тинькоффа, “Классический вариант {x}DD, когда изначально пишутся все тесты, и только потом начинается непосредственная разработка, в изначальных наших условиях сильно повлиял бы на наш быстрый релизный цикл, что для банковских сервисов непозволительная роскошь.”
Если вам критично что-то зарелизить быстро, вам нужна либо мощная поддержка которая будет быстро писать переводы кода на BDD язык, либо BDD вам для быстрого релиза не нужно. Если вы делаете новый функционал, который надо одновременно исследовать и тестировать как он работает (у меня такое было вот недавно) — Вам BDD тоже вряд ли нужен.
Опыт из которого это написано: три проекта где пытались внедрять BDD.
Очень сложная и разноплановая предметная область, сотни разных приложений и экранов. Туда вообще было бы лучше не соваться с BDD. Итого: BDD выкинуто.
Реализация через BDD (Specflow) формально работала, но ничем не помогла. Вина тут скорее была не BDD а сложности тестируемой системы и проблем с ее аппаратной, но особенно програмной частью (свой проприетарный сервер, своеобразная реализация с использованием Appium). Не расширив особо ни фич ни покрытия, проект закрылся.
Опять таки разноплановая предметная область, хотя и не такая архисложная как в случае 1, но большая. Поддержка BDD требовала значительных отдельных ресурсов программистов, BDD-описания кейсов выходили большими, сложными, непонятными. На него перестали выделять ресурсы и благополучно похоронили. Т.е. хотели “кейсы на BDD читабельные для всех”, а получилось “ни для кого”.
Статья про опыт Тинькова: https://habr.com/company/tinkoff/blog/322688/
Я полагаю что основные проблемы BDD это
R(
Просто у меня тут в соседнем отделе проскочила идея "давайте делать bdd, чтобы ручным тестировщикам было проще писать тесты", и она мне ОЧЕНЬ не нравится уже на этом этапе.
то что он дополнительная работа, которую нужно делать на ограниченном языке, для которого прописывать некую костыльную поддержку… и, конечно же, тратить на это время.
“новые правила жизни”. Да, действительно, может не быть полных требований наперед: работать так стало слишком медленно.
“новые правила жизни”. Да, действительно, может не быть полных требований наперед: работать так стало слишком медленно.
AV
когда оплата почасовая — можно хоть на геркине, хоть на шмеркине, заказчик платит, мы пишем
Ты прямо секреты профессии выдаешь
AB
упс... сорян
AB
ну а что, у меня был такой случай, когда заказчик прибегал с воплями, что надо срочно пройти аудит SOX, поэтому надо для всех имеющихся автотестов описать, что они делают и (вручную) занести результаты ключевых прогонов в TMS (имени компании хьюлит-паккард, это отдельная боль), аудиторы сказали, что надо это сделать. сидели, писали, а куда деваться... заказчик иногда тоже не по своей воле платит за такую фигню
AB
вот там геркин помог бы хорошо, если бы мы его использовали. но мы же не знали, что аудит нагрянет :)
AB
хотя сейчас бы, конечно, просто прикрутили бы аллюр
VS
Я потерял нить, кто сломал локаторы и зачем их исправлять?
В моём мире на элементы сами дев инженеры навешали data-testid и они не ломаются
В моём мире на элементы сами дев инженеры навешали data-testid и они не ломаются
изменения во фронте ломают
LY
У меня через 12 часов обсуждение этой идеи, сорян.
Относительно недавно Альфа-банк хвастался в своем блоге на Хабре, как они внедрили геркин на русском в тестировании, и как стало хорошо. Правда почему-то сейчас хантят рубистов...
PP
Относительно недавно Альфа-банк хвастался в своем блоге на Хабре, как они внедрили геркин на русском в тестировании, и как стало хорошо. Правда почему-то сейчас хантят рубистов...
Подозреваю, там миллион проектов. И если где-то внедрили, то в другом месте может вообще всё голо и босо
АФ
Относительно недавно Альфа-банк хвастался в своем блоге на Хабре, как они внедрили геркин на русском в тестировании, и как стало хорошо. Правда почему-то сейчас хантят рубистов...
эт потому что ВТБ у них схантило "половину" инженеров
LY
эт потому что ВТБ у них схантило "половину" инженеров
Теперь Акита живет в ВТБ? )
AP
Теперь Акита живет в ВТБ? )
где она не живет под разными названиями хД
R(
Относительно недавно Альфа-банк хвастался в своем блоге на Хабре, как они внедрили геркин на русском в тестировании, и как стало хорошо. Правда почему-то сейчас хантят рубистов...
