testomat.io управление авто тестамиКак-то прям слишком широко под одну гребенку всех. “Люди понимают”. Сообщество развивается и люди начинают смотреть дальше своего носа и того, что происходит в их песочнице. И уже достаточно много людей, которые не воспринимают BDD как отчеты. Мне кажется, Андрей, с вашим авторитетом не стоит писать заведомо ложных утверждений. Ибо к вашему мнению многие новички прислушаются, и не полезут дальше разбираться в теме.
Потом в итоге мы и имеем людей, для которых BDD - это тест-кейсы в формате “givеn-when-then” с лишними слоями абстракций в кода автотестов. Или же отчеты. 
ИМХО.
Праведный гнев! 
Это круто, правда.
Да, мы имеем людей, для которых BDD - это лишние слои или отчёты. Именно это меня и беспокоит. Именно с этим я и борюсь. Но мне кажется, вы переоцениваете мой авторитет. Это понимание BDD возникло в массе задолго до меня.
Вот это золотые слова:
надо понимать зачем команда ввязывается в историю с BDD
Надо, обязательно надо! И постоянно переспрашивать себя и сверяться с курсом. А люди ведь обычно даже не задают себе такой вопрос. “Давайте аджайл!” - “А давайте!” “Давайте BDD” - “А давайте!”
Вот с этим не совсем согласен:
данный подход взлетал только в тех командах, где инициатором выступал в первую очередь бизнес.
Важно не то, кто выступает инициатором. Инициатива может исходить и от разработчиков, и от тестировщиков, и от бизнеса. Важно, чтобы все остальные эту инициативу поддержали и участвовали в процессе. В том числе бизнес участвовал в написании спецификаций. И вот именно в это я не верю. Я хотел бы, чтобы так было, но на практике никогда не видел. А я участвовал во многих проектах и повидал много всяких бизнесов. Если где-то такое есть, я бы с удовольствием посмотрел, но пока не верю.
И ещё про это:
У команда, практикующих данный подход, происходит ориентация на бизнес.
У всех команд, практикующих любые подходы, должна быть ориентация на бизнес. Иначе это гибельный процесс. BDD - это не просто ориентация на бизнес, это именно вовлечение бизнеса в написание спецификаций. И как побочный эффект - отчёты. Поэтому как ни крути, BDD - это отчёты. Но, конечно, не главная цель, а лишь побочный эффект.
P.S. Кстати, хорошая аналогия с TDD. В случае TDD юнит-тесты тоже не главная цель, а лишь побочный эффект. А если делать TDD ради тестов, тоже получается шляпа, как и BDD ради отчётов.
1 лайк
Сколько бы не продолжался этот холивар, вывод один - сейчас слишком мало людей, понимающих зачем вообще использовать BDD, и врядли их появится больше с течением времени. Ведь зачем вообще заниматься этим если большинству компаний, внедряющих автоматизированное тестирование, нужны автотесты на API и UI? И они не спрашивают обязательно TDD или BDD, как хочешь так и пиши! Выбирай любые фреймворки, как угодно настраивай окружение и тд. Выдвигают только несколько требований - чтобы было читаемо, расширяемо, параллелизуемо, поддерживаемо после твоего ухода из компании. И это реалии, поэтому я не знаю что вы мечтаете об облаках каких то)
1 лайк
А лично вы поддерживали BDD AQA фреймворк со всеми слоями абстракции? Писали степы и реализацию под них? На любом ЯП. Мне кажется, что за холиварными “знаниями” теории скрывается скудное понимание всей боли в поддержке данной методологии в проекте.
Потом в итоге мы и имеем людей, которые размышляют о методологиях тестирования, ни разу не принимавших участие в поддержке любой из этих методологий.
2 лайка
Не только поддерживала, но и вывела в open source. И я стояла в истоках создания bdd-библиотеки akita bdd GitHub - alfa-laboratory/akita: BDD steps library for test automation.
И данным инструментом сейчас пользуется почти весь веб в Альфа банке (а это более 30-ти команд если что) + некоторые команды Epam-а. И эту либу берут в качестве прообраза, чтоб сделать ее аналог для .net. Помимо этого, я также участвовала в разработке библиотеки для тестирования мобилок appium+jbehave (collibri ui). Так что знакома не только с cucumber, но и с jbehave.
Но, я понимаю вашу боль. Ибо до того как мы разработали акиту, у одной из команд уже был фреймворк-франкенштейн на jbehave c таким количеством слоев абстракций, что пользоваться и поддерживать это “Добро” было сложно даже самим создателям.
Но как мне кажется, это проблема проектирования и архитектуры. Будь у создателей поболее навыков программирования и умели б они писать не только автотесты, но и в целом различные приложения на java, то умели бы правильно применять различные паттерны программирования.
Чаще всего проблемы с поддержкой возникают, из-за:
- туннельного мышления. Автоматизаторы редко умеют что-то кроме написания автотестов. Дашь им задачку по разработке какого-то приложения, вот тут сразу и выясняется, что толком проектировать и дизайнить код они не умеют.
- хреновой архитектуры
- отсутствия документации (тот же java doc к примеру и то отсутствует у многих в коде)
- отсутствия юнит-тестов. Из-за чего доработка библиотеки приводит к боли.
Это мое ИМХО. Я я понимаю, что мой опыт ограничен только контекстом 2-х организаций и не насчитывает десятки лет кодинга. Но я считаю, что моего опыта в разработке и автоматизации достаточно, чтоб иметь право на рассуждение о методологии. Ибо для меня это не только теория. Я на практике все это внедряла.
1 лайк
Вот бомбануло-то Но в целом, можно подметить, что сторонники, что противники BDD сходятся в одном - это не просто. Мой скромный опыт в разработке (больше все таки инструментов, чем тестов), подсказывает, что в этом и заключается вся проблемность данного подхода.
В одной из моих историй было так: бизнес захотел дешевых автоматизаторов. Бизнес кричал про БДД, что где то на модной конфе слышали, что там даже они смогут писать тесты (ха-ха-ха). Делать было нечего)), пришлось написать фреймворк понятный обезьянке и научить всех более владеющих клавиатурой мануальщиков писать тесты. В итоге все довольны. Правда ручные тестировщики сразу про повышение зарплаты через пару месяцев заговорили - автоматизаторы ж 
В том то и дело, что только сейчас компании начинают понимать, что автотестинг - это дорого и лучше не экономить на этом. И лучше уж потратиться и нанять 1-2 автоматизатора с хорошей подготовкой, чем из уже имеющихся мануальщиков пытаться что-то построить. Просто нужно выбирать технически грамотных ПМов, чтобы вам не ставили такие задачи после просмотра митапа о BDD))
Эх, где ж таких найти на рынке РФ еще)), лан, это конечно другая тема для разговора).
Не впечатлился, если честно. Тесты на русском языке? Сириусли? Это кому-то надо? Это заменяет пользовательскую документацию? Имхо, я бы за время разработки этой либы в двух средних проектах написал бы автоматизацию API и UI с нуля, поднял бы в докер композе несколько нод, распараллелил бы тесты на уровне CI, довольный получил бы денежку и поехал бы отдыхать) Ну а вы бы и дальше слушали ваших неадекватных ПМов и писали бы тесты на русском языке. Боже, это кому-то нужны тесты на русском языке 
4 лайка
Ну как минимум, у нас в компании нет разработчиков автотестов. Совсем. Но есть тестировщики в командах, которые не пишут тест-кейсы во всяких прокси-системах тест-менеджмента и описывают тесты сразу в формате “given-when-then”. И да, это надо командам. Код с автотестами лежит рядом с кодом приложения и вся команда имеет доступ к ним и при необходимости может сама их поправить.
Ну, а так как речь шла о BDD, то вся эта история затевалась, чтоб некоторые команды имели возможность описывать приемочные критерии еще на этапе планирования (до кодинга) сразу на языке тестов. Без прокси-документации, ТЗшек и тд. И все это находится внутри Pipeline jenkins на selenium grid on mesos, никаких ручных запусков и локальных прогонов. После прогона тестов, в артифактори складывается дока, которая генерится в случае успешного прохождения тестов. Дока в HTML.
Которой пользуются. И компания русскоязычная. На каком еще языке может быть спецификация?
Уточню, почему только некоторые команды - к сожалению не все команды обладают должным уровнем зрелости, чтоб формализовать тесты до написания кода приложения.
По поводу сроков разработки. Мы библиотеку не разрабатывали отдельно от продуктовой команды. Ее разработка происходила внутри продукта. Когда создавалось api библиотеки - исходили от запросов команд, потому что они наши потребители. За 2 месяца работы с одной командой - выпустили бету. Которую распространили потом еще в 3 команды. И суммарно спустя 4 месяца у нас появилась своя версия либы, которую уже потом передали на использование всем желающим.
И за все это время, мы никогда не брали паузу, чтоб решить какие-то автотестерские задачи отдельно от задач бизнеса. И наше тестовое покрытие было полностью автоматизировано. На ручное тестирование оставались только те сценарии, которые требовали UX проверок.
И если что, выше речь шла имею ли я нужный опыт работы с bbd-тулзами, чтоб рассуждать о неведомой мне теории. Так вот, опыт имею. А впечатляться или нет - это уже ваше право.
1 лайк
Эта проблема современной подачи BDD =(
На конференциях рассказывают про BDD в контексте - пусть тесты пишут тестировщики. Типа некий конструктор. Только не озвучивают последствия.
Хоспади. Какие PM-ы? Они еще где-то существуют?
Я думала разработка происходит внутри команды,разрабатывающей продукт и процесс должен рулить техлид. А PM - какой-то ненужный middle менеджмент.
И очень интересно, как автоматизатор (в количество 1-2 штука) сможет обсужить более 40ка команд. Каждая из команд которой живет по скраму и имеет в течении недели не менее 3-4х общекомандных встреч, на которых каждый член команды обязан присутствовать?
Я рассказывала о проблеме наличия выделенных автоматизаторов в компаниях, которые идут в сторону agile на одном из своих докладов.
Проблема в том, что неплохой автоматизатор во-первых откажется тестировать руками. То есть объединить в аналитика-тестировщика проектирующего тестовую модель и разработчика автотестов практически нереально.
Во-вторых каким бы неплохим автоматизатором он не был, скорее всего он не справится с продуктовыми задачами, которые стоят у команды. И как результат это специалист, который хорошо справляется с написанием кода на автотесты, но который сам не сможет выполнять задачм в рамках того продукта, который пилит его команда. И занятость этого автоматизатора в лучшем случае будет процентов на 50. И ему становится скучно.
На моем опыте, модем с выделенными автоматизаторами работает только тогда, когда в команде никто кроме него не пишет тесты. То есть разработчики на уровне своего кода не пишут тесты (интеграция, компоненты, системные, юнит). И приходится покрывать все возможные проверки после написания самого кода силами выделенного человека. То есть он фактически всю ту разработанную тестовую модель тестировщика перекладывает в код.
И в таком случае он как минимум отстает от команды на какой-то промежуток времени. И велью от его автотестов команда получает, только когда делает регрессию. То есть сценарий, чтоб сделать сразу приемку автоматизированной - почти нереализуем.
После этого хотел вообще не читать, но любопытно стало.
Вы вообще работаете там или стикеры по скрам доске передвигаете только?
Шта? Я человек простой: вижу метод апи - беру документацию, логику и пишу на него тест. Какие у меня еще продуктовые задачи?
Ну это у вас заблуждение из первой вашей цитаты. Вы их наверное только на митапах и видели. Как правило загруженность соизмерима с девом.
Ага, я буду юнит тесты еще писать за девов, ну ну. Я начинаю уже сомневаться в вашем опыте)) Как вы можете вообще такие фразы не бояться писать на форуме автоматизаторов, где каждый в своей компании и у каждого по-разному, но все равно работает?
А ну да, написать же тест перед деплоем новых фич можно же только по BDD или TDD. Вы реально так считаете?
Резюмирую: у меня сложилось ощущение что на вас висят шоры вашей компании и шире вы пока что не смотрите. Не обижайтесь, мы же тут холиварим. Из всей написанной вами каши вынести что-то достойное обсуждения у меня не удалось. Бывает люди пишут коротко и рука сразу тянется поставить лайк. Хотя одно вынес для себя точно: в Альфа-Банк теперь точно не пойду, присылали как то вакансии, вилка оказалась слишком мала. Спасибо, все понял)
2 лайка
До Альфа Банка я работала автоматизатором. Так что контекст вне энтерпрайза тоже имею. И имею представление о загруженности автоматизатора в зависимости от применяемой пирамиды автоматизации тестирования в команде.
А по поводу продуктовых задач.
Если у вас в команде 7-9 человек, из которых половина разработчики и тестировщик. Плюс добавить туда разработчика автотестов. Пирамида автоматизации выстроена таким образом, что большая часть тестов выполняется на уровне кода приложения. И их пишут сами разработчики.
Выходит разработчику автотестов нужно разрабатывать порядка 30% тестовой модели из слоя e2e тестов и все. CI/CD имеется, инфра налажена. Чем ему заниматься? У меня была гипотеза, чтоб привлекать ребят на продуктовые задачи. Не, ну а чо? Стек похожий, та же java и gradle. Но на практике вышло, что когда на собеседовании спрашивали кандидатов, готовы ли они половину времени заниматься разработкой например микросервисов, народ как-то тушевался.
При этом руками разработчик автотестов тестировать тоже не хочет. Ну например, чтоб он объединил в себе функции автоматизатора и тестировщика-аналитика.
Судя по вашим ответам у вас имеется опыт, которого явно не хватает мне. Вот что бы вы сделали в этой ситуации?
1 лайк
Спорный момент
ИМХО Тех лид + 2 перечуки лучше чем 3 тех лида как правило из-за погружения в контектст. Чего нету у многих поГромистов-автоматизаторов (особенно тех кто пришёл из разработки)
Ну о таких я вообще редко слышал. Обычно наоборот.
И если брать в контекст “погружение в продукт”, то да, тут лучше те, кто уже в курсе что тестировать и что проверять. Тут на одной стороне весов качество кода и архитектура, а на второй качество покрытия тестами.
Не правда. Пирамида отражает только количество тестов, а не важность их для продукта. Основные ошибки содержатся не в коде приложения, а в его логике. А вот саму логику юнит тесты не проверяют. Поэтому уделите больше всего автотестам на API. Через него можно проверить практически всю логику взаимодействия пользователя. И получится что работы у автотестера будет хоть отбавляй, особенно если проверять юзер стори в API, а не просто его правильную работу. И не надо привлекать автотестеров в разработку, захотят - сами уйдут. Разработка автотестов мне всегда казалась интереснее чем разработка приложения, не говоря уже о микросервисах.
Думаю, на этой замечательной ноте можно закончить столь общение.
И, Максим, вы меня извините, но почитайте, пожалуйста, матчасть про пирамиду тестирования, ее цель, способы выстраивания (автор Майк Кон, ну и Лиза Криспин с Джаннет Грегори очень хорошо тему раскрывают в своих книгах по Agile Testing). Ну и обязательно к прочтению Кент Бек и Фаулер.
Ибо не знать, что разработчики могут и должны писать не только модульные тесты…
Ну или как минимум посмотрите доклады с конференций, тот же Гейзенбаг или QAFest. Тема то популярная, контента море.
3 лайка
Вот это аргументы пошли в ход!
Конечно куда там всей этой макулатуре до такого уровня.
1 лайк
Дело не в макулатуре, а реальности реализации вещей на практике, за митингах все умные языком … а на практике дуб дубом!
1 лайк