Книги 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

4 жыл бұрын

Спасибо!

Очень доступно объясняешь👍🏻👍🏻 Рад что наткнулся на твой канал .

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

Благодарю!

супер!

молодець!

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

Стул хорош)

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

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

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

@automation_remarks

4 жыл бұрын

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

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

@automation_remarks

5 жыл бұрын

Сделаю

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

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

@knock-knock-neo

5 жыл бұрын

добавлю еще, что тесты на 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 плох когда функционал меняется. Если это изменение локаторов то это вообще не проблема, или что имеется ввиду? Если хорошо продумана структура автомейшен проэкта то это может по большей мере решить проблемы как с количеством тестов так и с изменением в функционале

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

@automation_remarks

5 жыл бұрын

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

@serhiikushnir

5 жыл бұрын

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

@automation_remarks

5 жыл бұрын

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

@yasenpen

5 жыл бұрын

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

@eugenstogniy8680

5 жыл бұрын

Karate framework

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

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

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

@automation_remarks

5 жыл бұрын

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

@juliapavlenko3429

5 жыл бұрын

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

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

@ihorslipchenko8352

5 жыл бұрын

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

@automation_remarks

5 жыл бұрын

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

@ihorslipchenko8352

5 жыл бұрын

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

@yasenpen

5 жыл бұрын

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

@dandenchik

5 жыл бұрын

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