R(
Это всё понятно, но тестировать фичу всё равно нужно будет после разработки
А про "shift left" в Ваших краях, месье, тоже не слыхали?
Size: a a a
2019 November 07
DA
На планировании фичи описываются в БДД. На первый день те шаги которые не существовали - кодируются (договориться о селекторах). И вот у нас крутится приёмочный тест, который позеленеет сразу как только будет готов под него код приложения
КР
На планировании фичи описываются в БДД. На первый день те шаги которые не существовали - кодируются (договориться о селекторах). И вот у нас крутится приёмочный тест, который позеленеет сразу как только будет готов под него код приложения
Да, именно это я имел в виду в ремарке о селениуме
КР
А про "выполнить приемочное" - в смысле сделать его зеленым
YA
А про "shift left" в Ваших краях, месье, тоже не слыхали?
я не про это говорю
DA
Мой кольт был быстрее :)
Я про кнопку "авто-тест", которая запускает непрерывно все нужные тесты
R(
Ну то, что девелопер тесты подготовил то разработки, выполняет же их после того, как разработал какой-то кусок, не?
Не обязательно. По TDD (или варианту оного) ты сначала прогони, посмотри на красные тесты, а потом уже разрабатывай.
YA
то что ты перенёс большинство активностей тестирование в начало проекта, не говорит о том, что после разрабтки (написания куска кода для авто-ттест), всё равно нужно будет тести првооидть.
YA
Не обязательно. По TDD (или варианту оного) ты сначала прогони, посмотри на красные тесты, а потом уже разрабатывай.
а потом прогони и убедись, что зелёные
R(
я не про это говорю
Ну это понятно, месье, что Вы опять про "ходить строем", но опять не весь мир ходит строем.
КР
На планировании фичи описываются в БДД. На первый день те шаги которые не существовали - кодируются (договориться о селекторах). И вот у нас крутится приёмочный тест, который позеленеет сразу как только будет готов под него код приложения
Я кстати пробовал практику, когда бдд пишет таки сам менеджер, причём совершенно вольным стилем. И оказывается, что когда сам постановщик задачи не способен описать, чего же он хочет, становится гораздо легче попросить его доработать хотелку до вменяемой
YA
Ну это понятно, месье, что Вы опять про "ходить строем", но опять не весь мир ходит строем.
ты как урапатриот, везде видишь козни америки =)
КР
то что ты перенёс большинство активностей тестирование в начало проекта, не говорит о том, что после разрабтки (написания куска кода для авто-ттест), всё равно нужно будет тести првооидть.
Ну мы сейчас обрисовали ситуацию, действительно, написанный в начале задачи приемочный тест станет зеленым только когда разработка завершилась. Точнее даже тест будет критерием завершения разработки
YA
Ну мы сейчас обрисовали ситуацию, действительно, написанный в начале задачи приемочный тест станет зеленым только когда разработка завершилась. Точнее даже тест будет критерием завершения разработки
ну
YA
я об этом и говорю
DA
Я кстати пробовал практику, когда бдд пишет таки сам менеджер, причём совершенно вольным стилем. И оказывается, что когда сам постановщик задачи не способен описать, чего же он хочет, становится гораздо легче попросить его доработать хотелку до вменяемой
Мы сдались на том, что ПО пишет в БДД стиле, а мы на планировании переводим это в наш БДД фреймворк и спрашиваем верно ли всё сделали
YA
я же не говорю, что начинать писать тести и читать спеки нужно только после рзработки
КР
Но тем не менее даже тут последний прогон теста раньше чем вливание разработки
КР
Мы сдались на том, что ПО пишет в БДД стиле, а мы на планировании переводим это в наш БДД фреймворк и спрашиваем верно ли всё сделали
Да, вполне удобный вариант. Особенно если делать вложенные шаги бдд хайлевел типа "я заполнил заявку" в шаги лоулевел типа "я заполнил фио". Высокая читабельность и хранение знаний о процессе получается
DA
И главное что на выходе - то что нужно ПО.