Перейти к содержимому

Фотография

Почему я не люблю огурцы и фитнес — плюсы и минусы BDD и ATDD


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 9

#1 baranceva

baranceva

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 4 150 сообщений
  • ФИО:Баранцева Наталья


Отправлено 20 апреля 2011 - 07:50

Выступление Алексея Баранцева на AgileDays-2011

Идея написания спецификаций на «естественном языке» манит своей внешней красотой и простотой. Мысль о том, что не умеющий программировать product owner станет сам рисовать Fitnesse-таблички и писать Cucumber-спецификации, выглядит очень привлекательно, возникает надежда переложить на него часть работы. Более того, исполнимые спецификации можно использовать как направляющие для разработки, и наряду с test driven development возникают подходы с похожими названиями — Behavior driven development и даже acceptance test driven development.

Однако здесь есть два больших подводных камня.

Помните бородатый анекдот про морскую свинку, которая, вопреки своему названию, и не плавает, и не хрюкает? Когда я слышу про автоматизированное приёмочное тестирование в контексте agile, у меня всегда возникает ассоциация с этой морской свинкой. Автоматизированное? Да, с этим не поспоришь. Но при этом и не приёмочное, и не тестирование. Для тестирования это слишком просто, «программирование в табличках» — адская пытка, паттерн given-when-then не даёт возможности сделать хоть сколько-нибудь сложные автоматизированные тесты, а при ручном тестировании он и вовсе не нужен. Ну а идея автоматизировать приёмку вообще слабо вписывается в концепцию agile: если «приёмочные тесты» будут пройдены, а product owner недоволен — продукт будет считаться успешно сданным или нет?

Второй подводный камень связан с большими скрытыми (или по крайней мере замалчиваемыми) затратами. Да, спецификации на «естественном языке» выглядят красиво. Но, увы, работа по реализации фикстур и шагов сценариев — это уже чистое программирование, причём объём и сложность этой работы в разы превышает размеры табличек и спецификаций. И это немедленно разрушает ореол простоты.

Так стоит ли вообще вкладывать усилия в эту деятельность? Кому BDD и ATDD приносит пользу — заказчику, программистам, тестировщикам? Как разрабатывать тесты, чтобы потраченные усилия всё же не пропали даром? Я постараюсь дать свои ответы на эти вопросы, и с удовольствием выслушаю вашу точку зрения.

Видеозапись доклада можно посмотреть здесь.



Читать дальше
  • 0
Наталья Баранцева
Тренинги по тестированию ПО

#2 OVA

OVA

    Опытный участник

  • Members
  • PipPipPipPip
  • 405 сообщений
  • ФИО:Высоцкий Сергей Павлович
  • Город:Новосибирск

Отправлено 20 апреля 2011 - 09:58

Ух ты. А я все думал как про это и без матов написать.
  • 0

#3 kos32

kos32

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Судиловский Константин Николаевич

Отправлено 26 апреля 2011 - 11:39

Для тестирования это слишком просто, «программирование в табличках» — адская пытка, паттерн given-when-then не даёт возможности сделать хоть сколько-нибудь сложные автоматизированные тесты


Никто не заставляет программировать в паттерне given-when-then и в табличках. Каждая команда выбирает и
договаваритается о том что им удобнее. Николай Алименков правильно упоминул Concordion. Там нет таких ограничений.

если «приёмочные тесты» будут пройдены, а product owner недоволен — продукт будет считаться успешно сданным или нет?

В таком случае PO - идиот. Нужно обновлять приемочные тесты и дописывать чего не хватает PO.

Второй подводный камень связан с большими скрытыми (или по крайней мере замалчиваемыми) затратами. Да, спецификации на «естественном языке» выглядят красиво. Но, увы, работа по реализации фикстур и шагов сценариев — это уже чистое программирование, причём объём и сложность этой работы в разы превышает размеры табличек и спецификаций. И это немедленно разрушает ореол простоты.

Да, но для класического скриптового языка тоже нужно кодировать.
Зато можно скрыть многие технические детали от QA и дать им доменный язык программирования для тестирования.
  • 0

#4 ch_ip

ch_ip

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 097 сообщений
  • ФИО:Павел Абдюшев
  • Город:Москва


Отправлено 26 апреля 2011 - 12:23

Зато можно скрыть многие технические детали от QA и дать им доменный язык программирования для тестирования.

Ну да, и проверки, которые делаются, тоже придется скрыть. Вместе с техническими деталями. Ну или это это будет тесты и проверки на уровне "Hello World"
Зачем QA доменный язык программирования? Сколько реально полезных тестов они смогут написать с его использованием? А сколько стоит поддержка такой возможности? И сколько стоит поддержка тех тестов, которые напишут QA?
Без тесного взаимодействия QA с автомтатизаторами не получится написать хороших автотестов все равно. А при наличии тесного взаимодействия необходимость в специальном доменном языке отпадает.
  • 0

#5 OVA

OVA

    Опытный участник

  • Members
  • PipPipPipPip
  • 405 сообщений
  • ФИО:Высоцкий Сергей Павлович
  • Город:Новосибирск

Отправлено 26 апреля 2011 - 17:40

kos32, вопрос в профите и скрытых издержках. Часто в итоге получаем что проще так тесты писать чем маяться с фитнесом и огурцами. Ну или свой фрейм ваять, что тоже ок.
  • 0

#6 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 26 апреля 2011 - 17:51

Каждая команда выбирает и договаваритается о том что им удобнее. Николай Алименков правильно упоминул Concordion. Там нет таких ограничений.

Кстати, забыл спросить у Николая, спрошу здесь -- для Concordion сделали таки визуальный редактор или нет?
Если нет -- не будут им пользоваться PO. Не будут и всё тут.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#7 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 26 апреля 2011 - 17:52

Вообще-то, надо признать, что тестировщики не первые пытаются ходить по этим граблям. У программистов уже была эта эпопея, правда, в более мягком варианте -- погуглите и почитайте про "литературное программирование" (literate programming), на которое Кнут возлагал большие надежды, но которое "не взлетело". Очень красивая идея, очень убедительно написано про то, как здорово всем этим пользоваться. Но -- не взлетело.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#8 enki86

enki86

    Постоянный участник

  • Members
  • PipPipPip
  • 231 сообщений


Отправлено 29 апреля 2011 - 03:27

понравилось обсуждение
интересно :good:
  • 0

#9 220v

220v

    Активный участник

  • Members
  • PipPip
  • 107 сообщений
  • ФИО:Олег


Отправлено 02 октября 2014 - 05:20

Алексей, Вы не могли бы добавить, чем Ваше обсуждение с девушкой закончилось?


  • 0

#10 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 02 октября 2014 - 10:40

Каждый остался при своём мнении, это же вполне очевидно :)


  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных