QAGuild live #8: BDD подход с точки зрения тестирования

[@automation_remarks]

Книги BDD in Action - www.manning.com/books/bdd-in-action ATDD - www.amazon.com/ATDD-Example-Test-Driven-Development-Addison-Wesley/dp/0321784154

[@name1355_0ne]

Спасибо!

[@АннаФарафонова-м9у]

Спасибо огромнейшее!!!

[@serj1013]

А можеш розказати про кращі підходи для паралелізації тестів?

[@automation_remarks]

Сделаю

[@bogart047]

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

[@knock-knock-neo]

полностью согласна с Сергеем, в мыслях о гонках за мнимой подачей простоты BDD и столкновению с реализацией. Как говорится - ожидание и реальность. Поработала во многих проектах и легаси системах и сложных и простых и во всех каналах (вебы, стационарные рабочие станции, мобильники). И всегда для UI автотестов руководство настаивало использовать различные виды подвиды BDD. Одна команда умных и больших разработчиков докручивала фреймворк и называла его каким-нибудь умным словом, а другая команда ручников пыталась на нем автоматизировать свои юайки. Скажу от себя, что имеет смысл навешивать BDD у себя в проекте, если только его функционал больше никогда в жизни не будет меняться))) в остальных случаях поддержка актуальности тестов и развертывания на различных стендах - не оправдывает затраченных сил, на обучение ручников писанию кода на BDD и дальнейшего сопровождения. Можно легко пол года угробить на покрытие регрессом автотестов на BDD, а потом эти тесты можно будет выкинуть на помойку, т.к. придется всё масштабно переписывать из-за нововведений со стороны разработки или ПО. И действительно, если у вас большая, распределенная команда, и одни умеют писать фичи - сяк, а другая команда научилась более модно писать фичи - так, в дальнейшем поддерживать фреймворк будет очень тяжело, особенно если не будет качественного ревью кода, а его скорей всего не будет.

[@knock-knock-neo]

добавлю еще, что тесты на BDD в большинстве случаев тяжелы для прогонов даже не больших объемов тестов (от 5 до 10шт). А если система еще остронагруженная и с зависимостями от других систем, то прохождение такой фичи не представляется возможным. А что бы тесты пробегали быстрее и проворнее нужно уже быть не просто ручником, с навыками автоматизации, а реально понимающим разработчиком, который разберется что и как там устроено в проекте и как починить, чтоб не поломать код у соседей. В общем, BDD - какашка и точка)))

[@yevhenonopriienko9580]

@@knock-knock-neo это ваше субьективное мнение. Как по мне BDD хорош в первую очередь не для кого то а для себя, так как открывая тесты ты сразу понимаеш что за тест и какие шаги ну и плюс это красиво а в реализации не вижу ничего сложного. Например я использую robot framework - философия очень похожа на BDD так как изначально кейворды у робота на понятном языке и писать на нем очень быстро

[@knock-knock-neo]

@@yevhenonopriienko9580 это не субъективное мнение, а практика и опыт) хорошо когда проект небольшой и функционал не меняется. Всё что больше тестовой модели в 100-200 и более штук - уже не весело будет

[@knock-knock-neo]

@@yevhenonopriienko9580 а для себя я бы не писала ничего больше, чем чек-лист в эксельке))) это вопрос приоритетов и чем больше ты в тестировании, тем меньше времени писать какие-либо тесты

[@yevhenonopriienko9580]

@@knock-knock-neo , я согласен с вами что когда ты занимаешся автоматизацией тестирования то со временем задаешся мыслю все оптимизировать и делать меньше движений при этом быть максимально еффективным. Просто для меня все равно не сильно раскрыт ваш посыл в том что BDD плох когда функционал меняется. Если это изменение локаторов то это вообще не проблема, или что имеется ввиду? Если хорошо продумана структура автомейшен проэкта то это может по большей мере решить проблемы как с количеством тестов так и с изменением в функционале

[@РамильИбраев-е5д]

Благодарю!

[@oleksandr_panchenko]

Мне нравится БДД. Конечно, у меня тоже типичное "бдд" без "д" -т.е тесты пишутся на разработаную веб-систему. Но: таких систем в проде - несколько, и отличаются они лишь незначительными параметрами. И еще есть мануальные тестировщики, которые могут этот тест использовать, получать ошибки в понятном виде, заводить их в бгтрекинг. Т.е для меня как для QA - автоматизатора много много плюсов, при том только минусе что да, надо думать иногда над шагами, иногда элементы с одинаковым текстом имеют разный путь xpath. Но при этом, я считаю что результат будет хорошо переносим между сходными дев-системами + использование мануальщиками - т.е плюсов вроде как больше как минусов (минусы только для меня а плюсы у всех)

[@pfcompany885]

А можно ли сказать, что BDD(T) - это один из сценарных видов тест-дизайна?

[@name1355_0ne]

Здравствуйте, Сергей. Нет ссылок на книги в описании. Не расслышал название второй книги. Спасибо за ваши видео, весьма интересно.

[@automation_remarks]

Оставил в закрепленном комментарии

[@DmytroPolischuk]

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

[@user-ce3lm7sz1k]

супер!

[@DmitriyNovikov-j2o]

Опыт с БДД очень плох , у нас очень большое приложение мессенджер с видео связью , сип телефонией и многими другими фичами , и когда я впервые зашел и увидел класс на 1500 строк я прихуел немного так сказать ... Когда пишешь новый тест , начинаешь искать по этим ключевым словам метод(функцию) для какого-то действия , а тебе выпадает в поиске в ИДЕ 5-7 реализаций твоего шага(возможно их может быть и больше во фреймворке..., потому что называются по-другому) который тебе нужен это конечно мрак полный... это только малость того с чем я столкнулся Вывод, не используйте БДД для больших проектов

[@serhiikushnir]

Хороший вопрос подняли. Как раз рассматриваю какой фреймворк использовать для покрытия реста - rest-assured, который юзает бдд или webtau. Последний меня больше привлекает, особенно если писать на груви по сценариям. @QAGuild а как ты считаешь? Спасибо

[@automation_remarks]

Серега Кушнир web tau пока не пробовал. Могу сказать, что на груви я бы не сейчас ничего не писал, лучше уже котлин, если рассматривать альтернативные варианты

[@serhiikushnir]

@@automation_remarks а почему груви не юзал бы? Есть веские причины на то?

[@automation_remarks]

@@serhiikushnir полумертвый язык, лучше брать что-то понадежнее

[@yasenpen]

Я писал тесты на Groovy, очень мощный и подходящий для этой задачи, но да, времёна Груви ушли, его создали в те времена, когда джава была древней и не было Котлина

[@eugenstogniy8680]

Karate framework

[@automation_remarks]

А как вы относитесь к BDD?

[@ihorslipchenko8352]

У нас на проекте используется cucumber. ИМХО, удобно переиспользовать, удобно тэгировать сценарии, и, соответственно, параметризированно запускать.

[@automation_remarks]

Igor Slipchenko а как дела с параллельностью?

[@ihorslipchenko8352]

@@automation_remarks Нормально. В конфиге есть несколько аккаунтов. На каждую фичу из конфига вычитвается следующая пара логин/пароль.

[@yasenpen]

Spock + Geb +Groovy замечательно работал. Несколько попыток внедрить Cucumber или JBehave провалились. Лично я считаю, что в типичном проекте бдд не нужен.

[@dandenchik]

Дуже добре відношусь, комфортно тримати і юзати тест кейси у feature файлах і незалежно від того чи пишеться автоматизація чи ні, feature файли є замінником екселю)

[@matthewmad2999]

молодець!

[@juliapavlenko3429]

А что Джефф Морган сказал по поводу bdd? Какие плюсы называл?

[@automation_remarks]

вот тут можно почитать его мысли leanpub.com/cucumber_and_cheese

[@juliapavlenko3429]

@@automation_remarks это понятно, был интересен сам диалог ваш

[@madsmile777]

ІМО емуляція поведінки користувача - це ж необхідний мінімум в тестуванні. Все логічно і максимально прозоро. Правда зараз топові пани і панесси пропонують використовувати реальних користувачів для тестування - Chaos Testing (principlesofchaos.org/).

[@thisistheway7825]

Стул хорош)