Comments 14
о_О кто-то осилил это внедрить?
Сколько человеко-часов затрачено на разработку и внедрение?
Сколько человеко-часов сэкономлено по сравнению с классическими подходами?
Сколько человек занимается поддержкой и развитием этой штуки?
Что говорят рядовые разработчики?
Сколько человеко-часов затрачено на разработку и внедрение?
Сколько человеко-часов сэкономлено по сравнению с классическими подходами?
Сколько человек занимается поддержкой и развитием этой штуки?
Что говорят рядовые разработчики?
BDD неплохо экономит время на разработку новых тестов, когда основная инфраструктура уже готова и есть какая-то база шагов и сценариев
Внедрение заняло пол года и проходило поэтапно: начинали с создания ядра фреймворка с привлечением одного специалиста и затем вводили новые ресурсы по мере наращивания объемов BDD-кейсов. На данный момент мы имеем 30 функциональщиков, пишущих BDD-кейсы и 6 автоматизаторов, успевающих автоматизировать новый функционал и поддерживать большой объем текущих кейсов. Развиваем автоматизацию совместными усилиями — в автоматизации теперь заинтересованы и функциональщики, и автоматизаторы. Все чувствуют фидбек от своей работы.
Вопрос об оправданности внедрения методологии у нас не возникает. Имеем значительную разницу между тем, что было до внедрения BDD, и что стало после. Повысили показатели по и как по объемам автоматизации, так и по скорости. Плюс имеем много дополнительных приятных моментов, начиная от прозрачности процесса автоматизации и заканчивая дополнительной мотивацией функциональщиков в их развитии как специалистов.
Рядовые разработчики положительно восприняли новость о внедрении BDD, активно помогают нам со своей стороны. А самое главное, скоро оно начнут полноценно пользоваться нашими автотестами. Надеемся сократить количество возвратов задач тестировщиками на разработчиков.
Кто знает, возможно это первые шаги к Continuous delivery.
Вопрос об оправданности внедрения методологии у нас не возникает. Имеем значительную разницу между тем, что было до внедрения BDD, и что стало после. Повысили показатели по и как по объемам автоматизации, так и по скорости. Плюс имеем много дополнительных приятных моментов, начиная от прозрачности процесса автоматизации и заканчивая дополнительной мотивацией функциональщиков в их развитии как специалистов.
Рядовые разработчики положительно восприняли новость о внедрении BDD, активно помогают нам со своей стороны. А самое главное, скоро оно начнут полноценно пользоваться нашими автотестами. Надеемся сократить количество возвратов задач тестировщиками на разработчиков.
Кто знает, возможно это первые шаги к Continuous delivery.
Спасибо за ответ
>Рядовые разработчики положительно восприняли новость о внедрении BDD, активно помогают нам со своей стороны. А самое главное, скоро оно начнут полноценно пользоваться нашими автотестами.
Статья интересная, спасибо! Скажите, удалось ли привлечь разработчиков к использованию автотестов?
Простите за некропост :)
Статья интересная, спасибо! Скажите, удалось ли привлечь разработчиков к использованию автотестов?
Простите за некропост :)
Не планируете выложить этот плагин в репозиторий Jetbrains?
Наш плагин в репозитории JetBrains будет загонять пользователей под наши жёсткие рамки формата описания элементов. Плагин должен быть гибким. Будет более правильным выложить исходники в github, и такие мысли у нас есть, и дать возможность пользователям собирать плагин под себя. Или реализовать возможность редактирования формата описания элементов прямо через сам плагин и залить в jetbrains-repo такой вариант.
Заинтересованные в плагине нас стимулируют)
Заинтересованные в плагине нас стимулируют)
Спасибо за развёрнутую статью!
Очень интересен ваш опыт, появилось несколько практических вопросов:
1. Подскажите пожалуйста, как написание сценариев пользователями синхронизируется с тестовыми данными? Возможно, ответ есть в статье, но я не смог понять, что в вашем случае является тестовыми данными, это данные, которые могут быть использованы в процессе работы теста, или это эталонные данные, с которыми тест потом сверяется.
2. У каждого пользователя свои тестовые данные?
3. Задействуются ли программисты в вашей схеме BDD?
Кроме этих трех пунктов, если это не является коммерческой тайной (что было бы справедливо), было бы очень интересно увидеть сценарий происходящего, на некотором практическом примере. Например: есть «постановка задачи», под неё пишется сценарный тест, далее он переходит к функциональщикам, те его шлифуют…и так далее до конца (последовательность здесь вымышленная).
Понимаете, очень часто, статьи про BDD описывают инструментарий и методику вокруг инструментария, но я нигде до конца не находил методику интеграции BDD в процесс разработки. Другими словами, хотелось бы увидеть, как решаются вопросы зачистки базы, что происходит при многократных итерациях запуска тестов, как проверяется бизнес-логика, с чего начинается написание сценария (например, если есть сценарий «Расхода» пишется ли вначале сценарий «Прихода» без которого тест «Расхода» не выполнится). Другими словами всё то, что без правильной методики при отсутствии сверх финансирования, нередко вынуждает отказываться от этой затеи.
Спасибо!
Очень интересен ваш опыт, появилось несколько практических вопросов:
1. Подскажите пожалуйста, как написание сценариев пользователями синхронизируется с тестовыми данными? Возможно, ответ есть в статье, но я не смог понять, что в вашем случае является тестовыми данными, это данные, которые могут быть использованы в процессе работы теста, или это эталонные данные, с которыми тест потом сверяется.
2. У каждого пользователя свои тестовые данные?
3. Задействуются ли программисты в вашей схеме BDD?
Кроме этих трех пунктов, если это не является коммерческой тайной (что было бы справедливо), было бы очень интересно увидеть сценарий происходящего, на некотором практическом примере. Например: есть «постановка задачи», под неё пишется сценарный тест, далее он переходит к функциональщикам, те его шлифуют…и так далее до конца (последовательность здесь вымышленная).
Понимаете, очень часто, статьи про BDD описывают инструментарий и методику вокруг инструментария, но я нигде до конца не находил методику интеграции BDD в процесс разработки. Другими словами, хотелось бы увидеть, как решаются вопросы зачистки базы, что происходит при многократных итерациях запуска тестов, как проверяется бизнес-логика, с чего начинается написание сценария (например, если есть сценарий «Расхода» пишется ли вначале сценарий «Прихода» без которого тест «Расхода» не выполнится). Другими словами всё то, что без правильной методики при отсутствии сверх финансирования, нередко вынуждает отказываться от этой затеи.
Спасибо!
Спасибо за конструктивные вопросы!
1. Если я верно понял ваш вопрос. Тестовые данные, использующиеся в процессе работы теста и являются эталонными. То есть, они заведомо верны, даже для негативных проверок. Стараемся все тестовые данные выносить из самых BDD-кейсов, оставляя только «привязки» к их расположению в БД через API.
2. Да, пользователь сам формирует свои тестовые данные. Это полностью его ответственность. Однако, есть тестовые данные которые являются общими, и мы, автоматизаторы, помогаем их формировать: например, тестовые учетные записи для входа в Интернет-банк.
3. Программисты могут писать свои кейсы, если посчитают нужным. Это приветствуется, но не пока обязательно. У самых программистов большое желание использовать наши web-интерфейсные автотесты для проверки корректности выполнения своих задач, сейчас работаем над этим.
Сценарий происходящего, если его сильно утрировать, следующий:
1. Менеджеры создают новую задачу в багтрекинге и ставят постановку в формате BDD
2. Задача поступает технологам и детализируется ими для разработчиков, задача дополняется новыми BDD-кейсами
3. Задача поступает разработчикам, которые видят всю постановку в формате BDD и начинают её реализовывать. Попутно они могут пополнить постановку своими кейсами
4. Задача поступает в тестирование. Тестировщик получает готовые сценарии для тестирования и быстро их переносит в BDD-фреймворк. Плюс дополняет задачу всеми BDD-кейсами, которых не хватает в постановке и переносит во фреймворк и их
5. Новый BDD-кейс проходит ревью, и если этому кейсу чего-либо не хватает, создается задача на автоматизаторов
6. Новый BDD-кейс попадает в рабочую ветку авторегресса. И его можно использовать при регрессе
1. Если я верно понял ваш вопрос. Тестовые данные, использующиеся в процессе работы теста и являются эталонными. То есть, они заведомо верны, даже для негативных проверок. Стараемся все тестовые данные выносить из самых BDD-кейсов, оставляя только «привязки» к их расположению в БД через API.
2. Да, пользователь сам формирует свои тестовые данные. Это полностью его ответственность. Однако, есть тестовые данные которые являются общими, и мы, автоматизаторы, помогаем их формировать: например, тестовые учетные записи для входа в Интернет-банк.
3. Программисты могут писать свои кейсы, если посчитают нужным. Это приветствуется, но не пока обязательно. У самых программистов большое желание использовать наши web-интерфейсные автотесты для проверки корректности выполнения своих задач, сейчас работаем над этим.
Сценарий происходящего, если его сильно утрировать, следующий:
1. Менеджеры создают новую задачу в багтрекинге и ставят постановку в формате BDD
2. Задача поступает технологам и детализируется ими для разработчиков, задача дополняется новыми BDD-кейсами
3. Задача поступает разработчикам, которые видят всю постановку в формате BDD и начинают её реализовывать. Попутно они могут пополнить постановку своими кейсами
4. Задача поступает в тестирование. Тестировщик получает готовые сценарии для тестирования и быстро их переносит в BDD-фреймворк. Плюс дополняет задачу всеми BDD-кейсами, которых не хватает в постановке и переносит во фреймворк и их
5. Новый BDD-кейс проходит ревью, и если этому кейсу чего-либо не хватает, создается задача на автоматизаторов
6. Новый BDD-кейс попадает в рабочую ветку авторегресса. И его можно использовать при регрессе
ставят постановку в формате BDD
Какой в итоге объём сценариев, поступапающих с задачей к разработчикам?
Хорошая статья, но очень много общих утверждений и практически нет практических демо-примеров.
Давно занимаюсь тестированием для разных языков (С++, C#, 1С ), в т.ч. года три и с Gherkin работаю.
Есть много нерешенных вопросов
grumegargler Задал отличные практические вопросы, но ответ опять слишком общий :(
Давно занимаюсь тестированием для разных языков (С++, C#, 1С ), в т.ч. года три и с Gherkin работаю.
Есть много нерешенных вопросов
grumegargler Задал отличные практические вопросы, но ответ опять слишком общий :(
По поводу тестовых данных сложный вопрос, все зависит от специфики проекта.
У нас на проекте (не Тинькоф) данные постоянно динамически обновляются, если есть что-то создаваемое пользователем, то пользовательская история начинается преимущественно так, если соответствующих данных нет (где это оправдано и возможно). Между собой связаны только сценарии внутри истории.
У нас на проекте (не Тинькоф) данные постоянно динамически обновляются, если есть что-то создаваемое пользователем, то пользовательская история начинается преимущественно так, если соответствующих данных нет (где это оправдано и возможно). Между собой связаны только сценарии внутри истории.
Спасибо Тинькову за хорошую статью) Все никак руки не доходили написать подобную. Этот подход уже опробован и внедрен в нескольких фирмах.
Сроки на автоматизацию проекта резко сокращаются и не требуют большой команды опытных разработчиков.
У нас тесты успешно пишет тестировщик, совсем не знакомый с программированием, постепенно этот человек начился писать локаторы самостоятельно, но по началу использовал готовый пул полей и типов.
Для новых полей достаточно описать котроллеры полей, которые к сожалению уникальны для большинства проектов и в путь) сами тесты набираются довольно быстро.
Сроки на автоматизацию проекта резко сокращаются и не требуют большой команды опытных разработчиков.
У нас тесты успешно пишет тестировщик, совсем не знакомый с программированием, постепенно этот человек начился писать локаторы самостоятельно, но по началу использовал готовый пул полей и типов.
Для новых полей достаточно описать котроллеры полей, которые к сожалению уникальны для большинства проектов и в путь) сами тесты набираются довольно быстро.
Sign up to leave a comment.
Автоматизация по методологии BDD. Наш опыт успешного внедрения