Расскажите про ваш QA department

[АццкоМото]

тдд и бдд -- откровенный булшит.

Это до тех пор пока Вы не попробовали. На самом деле без ковержа в 80% попытаться что либо зарефакторить это просто именины сердца с огромной возможностью вызова в компанию реанимации.

Когда есть код ковредж то снимается очень большой пласт ответственности за внесение измененний в проект. Более того даже библиотеку заменить без хорошого покрытия тестами по живому продукту т.е. БДД это очень нехилый шанс напороться на несовместимость и прочие мелкие радости.

Сереж, может я реально тупой. Объясни мне, как код каверадж снимает пласт ответственности? Ну вот мне нужно новую фичу сделать. Условно - сделать кнопку не зеленой, а синей. Ну и я ломаю тесты. Я тут же правлю тест - ведь поменялись же требования. И тесты снова проходят. А потом выясняется, что я фтупил и кнопка должна быть красной и еще плюс к тому круглой. Кому помогли эти тесты?

Ключевой момент: в ТДД и БДД тесты правит сам разработчик. Т.е. он inclined натянуть сову на глобус со своим возможно неверным представлением

Автоматизация тестирования - отлично. Но тестирование обязано быть независимым. Иначе смысла нет

[fruit6]

изза того что людям постоянно ебут мозг в оджайле, им похер на стендапы и дизайн сессии. я такое видел на всех оджайл проектах.

А Вы не задумывались, что если покрытие тестами меньше 100%, то это не ТДД а ДДД (Development-Driven Development)?

Критиковать тдд/бдд это так же не этично на персональном уровне как, например, смеяться над религиозными людьми и разного рода лузерами.
Например, если сравнить меня с Нобелевским лауреатом, то я, безусловно, тоже лузер.

[АццкоМото]

Критиковать тдд/бдд это так же не этично на персональном уровне как, например, смеяться над религиозными людьми и разного рода лузерами.

вот я сегодня завтракал в гостинице с девочкой лет 14-15. ну и ее папа-мама. а у девочки карсит с куклой. настоящий, и кукла прям как живой ребенок. ну и вообще видно, что отклонения психики - бывает, чо. жалко, что тот пипетс.

разница с адептами тдд/бдд только в том, что их не жалко. ну, или не настолько

[Sergunka]

тдд и бдд -- откровенный булшит.

Это до тех пор пока Вы не попробовали. На самом деле без ковержа в 80% попытаться что либо зарефакторить это просто именины сердца с огромной возможностью вызова в компанию реанимации.

Когда есть код ковредж то снимается очень большой пласт ответственности за внесение измененний в проект. Более того даже библиотеку заменить без хорошого покрытия тестами по живому продукту т.е. БДД это очень нехилый шанс напороться на несовместимость и прочие мелкие радости.

Сереж, может я реально тупой. Объясни мне, как код каверадж снимает пласт ответственности? Ну вот мне нужно новую фичу сделать. Условно - сделать кнопку не зеленой, а синей. Ну и я ломаю тесты. Я тут же правлю тест - ведь поменялись же требования. И тесты снова проходят. А потом выясняется, что я фтупил и кнопка должна быть красной и еще плюс к тому круглой. Кому помогли эти тесты?

Здесь нет противоречия поменялись требования к фиче - поменяются и тесты. Здесь главное, что твоя "красная и круглая кнопка" не изменила работу всей системы или ее критической части через возможный сайд эффект или просто не знания как эта кнопка завязана на другие модули. Так как прогоняются все модули во время БДД и как эта кнопка побольшому счету может повлиять на работу системы вцелом только БДД тесты и выясняют.

[Sergunka]

изза того что людям постоянно ебут мозг в оджайле, им похер на стендапы и дизайн сессии. я такое видел на всех оджайл проектах.

А Вы не задумывались, что если покрытие тестами меньше 100%, то это не ТДД а ДДД (Development-Driven Development)?

Критиковать тдд/бдд это так же не этично на персональном уровне как, например, смеяться над религиозными людьми и разного рода лузерами.
Например, если сравнить меня с Нобелевским лауреатом, то я, безусловно, тоже лузер.

На самом деле если проект серьезный и большой где требуется усилия нескольких групп по пять шесть человек без спецификаций это не возможножно сделать. Как я написал мы выкладывали спеки огурцами когда уже шел момент где косяк то сначало находили огурец, а потом уже искали это БА скосячил или программист.

вот к примеру как выглядит мой средней руки огурец

https://github.com/SVyatkin/ads-bdd/blo ... st.feature" onclick="window.open(this.href);return false;

[АццкоМото]

Здесь нет противоречия поменялись требования к фиче - поменяются и тесты. Здесь главное, что твоя "красная и круглая кнопка" не изменила работу всей системы или ее критической части через возможный сайд эффект или просто не знания как эта кнопка завязана на другие модули. Так как прогоняются все модули во время БДД и как эта кнопка побольшому счету может повлиять на работу системы вцелом только БДД тесты и выясняют.

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

[Big Cheese]

С одной стороны, я согласен с Вашими аргументами про внятную спецификацию и историю изменений, но только при условии, что все вовлеченные в процесс люди "в теме".

Это возможно если не соблюдается элементарная технологоия аджайла - люди не ходят на стендап и не посещают дизайн сессии.

Не, я не про то. Мой поинт в том, что попытка использовать native language как псевдо-язык программирования для "нетехнических" людей (основной selling point огурца IIRC) это мертворожденная идея, сродни всяким графическим тулзам программирования 15-летней давности, которые должны были заменить погромистов, как класс.

[X37WAL!^]

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

Ну, я месяц назад лично видел, как в "одном углу" приложения индус прицепил новую библиотеку для экспорта в Excel, а в другом углу сломалась совершенно "не имеющая к этому отношения" подсистема. Почему? Где-то имена были не fully-qualified (и обойти это низзя было) и при помощи reflection эта самая не имеющая отношения подсистема стала успешно грузить сршенно не тот dll. А потом обламывалась при попытке вызвать из одноименного класса функцию, которой там не было Индус тестировал свой угол приложения и там всё работало, а другой угол не тестировал никто ибо его рука человека уже два года не касалась. Морали никакой - так к слову.

[Aleksey Kudinov]

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

Ну, я месяц назад лично видел, как в "одном углу" приложения индус прицепил новую библиотеку для экспорта в Excel, а в другом углу сломалась совершенно "не имеющая к этому отношения" подсистема. Почему? Где-то имена были не fully-qualified (и обойти это низзя было) и при помощи reflection эта самая не имеющая отношения подсистема стала успешно грузить сршенно не тот dll. А потом обламывалась при попытке вызвать из одноименного класса функцию, которой там не было Индус тестировал свой угол приложения и там всё работало, а другой угол не тестировал никто ибо его рука человека уже два года не касалась. Морали никакой - так к слову.

Более свежий пример - обернули HttpServletRequest в ропер для повторного чтения контента, ранее сделанные БТ поймали, что перестали аплодиться иксели совсем в другом углу, на multipart content не подрасчитали. Радостно починили - дальше поскакали. БДД хорошая штука, но, соглашусь, дорогая.

[ystar]

С одной стороны, я согласен с Вашими аргументами про внятную спецификацию и историю изменений, но только при условии, что все вовлеченные в процесс люди "в теме".

Это возможно если не соблюдается элементарная технологоия аджайла - люди не ходят на стендап и не посещают дизайн сессии.

А как же ретроспективы??? А говорите тут что умеете тру аджайл

[Sergunka]

С одной стороны, я согласен с Вашими аргументами про внятную спецификацию и историю изменений, но только при условии, что все вовлеченные в процесс люди "в теме".

Это возможно если не соблюдается элементарная технологоия аджайла - люди не ходят на стендап и не посещают дизайн сессии.

А как же ретроспективы??? А говорите тут что умеете тру аджайл

А что дает ретроспектива? Я вообще не улавливаю смысл ее существования для девелоперов.

[Sergunka]

БДД хорошая штука, но, соглашусь, дорогая.

В БДД самая дорогое это высокий уровень вхождения требуется чтоб в тиме были люди с профильным образованием и с пониманием технологического процесса.

[АццкоМото]

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

Ну, я месяц назад лично видел, как в "одном углу" приложения индус прицепил новую библиотеку для экспорта в Excel, а в другом углу сломалась совершенно "не имеющая к этому отношения" подсистема. Почему? Где-то имена были не fully-qualified (и обойти это низзя было) и при помощи reflection эта самая не имеющая отношения подсистема стала успешно грузить сршенно не тот dll. А потом обламывалась при попытке вызвать из одноименного класса функцию, которой там не было Индус тестировал свой угол приложения и там всё работало, а другой угол не тестировал никто ибо его рука человека уже два года не касалась. Морали никакой - так к слову.

Если такого рода баги ловятся даже раз в месяц (что невероятно), удваивать затраты на разработку неразумно. Если только это не военка/космос/авиация/иже с ними

[АццкоМото]

БДД хорошая штука, но, соглашусь, дорогая.

В БДД самая дорогое это высокий уровень вхождения требуется чтоб в тиме были люди с профильным образованием и с пониманием технологического процесса.

и как называется профиль образования для БДД? Что-то типа "гейбддшник"?

[ystar]

БДД хорошая штука, но, соглашусь, дорогая.

В БДД самая дорогое это высокий уровень вхождения требуется чтоб в тиме были люди с профильным образованием и с пониманием технологического процесса.

ммм.... у вас похоже очень интересный опыт и понимание БДД. но вы почитайте что там БДД пропагандирует все таки.

а так это просто ещё один дополнительный слой, а каждый дополнительный слой несет в себе дополнительные расходы, а вот не факт, что прибыль приносит.

[nyekimov]

С одной стороны, я согласен с Вашими аргументами про внятную спецификацию и историю изменений, но только при условии, что все вовлеченные в процесс люди "в теме".

Это возможно если не соблюдается элементарная технологоия аджайла - люди не ходят на стендап и не посещают дизайн сессии.

А как же ретроспективы??? А говорите тут что умеете тру аджайл

А что дает ретроспектива? Я вообще не улавливаю смысл ее существования для девелоперов.

Как что даёт ретроспектива? Пиво и возможность высказать своё фи по косякам или косячникам из спринта, которому и посвящено данное мероприятие. У нас аж один раз было. Потом руководство выше сказало, что терять три четыре часа на такие вещи немысленно.

[АццкоМото]

Как что даёт ретроспектива? Пиво и возможность высказать своё фи по косякам или косячникам из спринта, которому и посвящено данное мероприятие. У нас аж один раз было. Потом руководство выше сказало, что терять три четыре часа на такие вещи немысленно.

На предпоследней работе демка, ретроспектива и спринт планнинг занимали ровно день. При двухнедельных спринтах. Это 10, блдж, процентов времени!

[Slava V]

Потом я всеж использую огурцы для стандартной связки бекенд рест/SOAP API. Народ кто тычет огурцом в UI у меня вызывает чувство глубого сочувствия. В UI на мой взгляд есть узкая ниша для огурца когда пытаются сделать END-2-END тесты где огурец вполне прокатит. Но писать на огурце типо "вторая строка третье поле нажмем кнопку запуск" это действительно очень героически кто бы объяснил в чем смысл?

могу объяснить:

1) предположим, что UI написан на AngularJS (есть варианты и для другиx franeworks)
2) для AngularJS берем Protractor (это порт Selenium для Angular), к нему прикручиваем Cucumber (есть несколько вариантов)
3) получаем возможность автоматически тестировать UI, при этом
- собственно шаги теста могут быть прописаны с любой степенью детализации (это как команда договорится) - если product owner желает писать тесты типа вторая строка третье поле нажмем кнопку запуск" значит так тому и быть; вменяемые обычно пишут типа "создаем новую запись, данные вот из этой таблички", есть еще варианты
- с какого-то момента (когда большинство шагов будет уже имплементировано) QA-щики смогут САМИ писать любое количество е2е тестов, если какого-то шага не xватает - программеры его добавят и вернутся к своим делам
- можно тестить в огромной комбинации устройств-ОС-браузеров (привет browserstack)
- можно автоматически отслеживать все ошибки в консоли
- самое главное - мы тестируем ВСЮ систему целиком, отмазки типа "а у нас в api все работает, это опять UI-щики чего-то напутали" больше не проxодят - юзеру плевать чья эта вина, ему надо чтоб работало.


у кого есть еще вопросы - обращайтесь

[Slava V]

Как что даёт ретроспектива? Пиво и возможность высказать своё фи по косякам или косячникам из спринта, которому и посвящено данное мероприятие. У нас аж один раз было. Потом руководство выше сказало, что терять три четыре часа на такие вещи немысленно.

На предпоследней работе демка, ретроспектива и спринт планнинг занимали ровно день. При двухнедельных спринтах. Это 10, блдж, процентов времени!

канбан не пробовали? очень рекомендую - экономит кучу времени

[Slava V]

всякие прохиндеи впаривают БДД/огурец, как очередную вундервафлю - типа, вот сейчас наши non-technical stakeholders наконец-то заговорят на одном языке с технарями. Это, на мой взгляд - разговор в пользу бедных..

попытка использовать native language как псевдо-язык программирования для "нетехнических" людей (основной selling point огурца IIRC) это мертворожденная идея, сродни всяким графическим тулзам программирования 15-летней давности, которые должны были заменить погромистов, как класс.

ну почему же, внятно написанная BDD спецификация

1) легко читается всеми, кто понимает о чем вообще речь
2) достаточно детально описывает конечный продукт (т.е. с ней можно сверяться в процессе разработки)
3) может служить кодом для автоматическиx е2е тестов

чего еще надо бедным?

[ystar]

3) получаем возможность автоматически тестировать UI, при этом
- собственно шаги теста могут быть прописаны с любой степенью детализации (это как команда договорится) - если product owner желает писать тесты типа вторая строка третье поле нажмем кнопку запуск" значит так тому и быть; вменяемые обычно пишут типа "создаем новую запись, данные вот из этой таблички", есть еще варианты
- с какого-то момента (когда большинство шагов будет уже имплементировано) QA-щики смогут САМИ писать любое количество е2е тестов, если какого-то шага не xватает - программеры его добавят и вернутся к своим делам
- можно тестить в огромной комбинации устройств-ОС-браузеров (привет browserstack)
- можно автоматически отслеживать все ошибки в консоли
- самое главное - мы тестируем ВСЮ систему целиком, отмазки типа "а у нас в api все работает, это опять UI-щики чего-то напутали" больше не проxодят - юзеру плевать чья эта вина, ему надо чтоб работало.


у кого есть еще вопросы - обращайтесь

с какого перепугу вдруг cucumber позволяет тестировать на огромной комбинации устройств, а другие нет?
и как cucumber позволяет делать ваши последние 3 пункта очень большой вопрос у меня.

[Slava V]

cucumber позволяет тестировать на огромной комбинации устройств, а другие нет?

ну почему же, другие тоже позволяют (я ж говорю, этто пункт основан на browserstack), но кто будет писать все эти тесты?

и как cucumber позволяет делать ваши последние 3 пункта очень большой вопрос у меня.

Вы не могли бы поконкретнее?
скажем, Вы что-то пробовали и у Вас не получилось - что?

или xотя бы читали статью про cucumber и Вам не понравились примеры - какие?

[ystar]

cucumber позволяет тестировать на огромной комбинации устройств, а другие нет?

ну почему же, другие тоже позволяют (я ж говорю, этто пункт основан на browserstack), но кто будет писать все эти тесты?

и как cucumber позволяет делать ваши последние 3 пункта очень большой вопрос у меня.

Вы не могли бы поконкретнее?
скажем, Вы что-то пробовали и у Вас не получилось - что?

или xотя бы читали статью про cucumber и Вам не понравились примеры - какие?

как именно cucumber позволяет делать вот это
- можно автоматически отслеживать все ошибки в консоли
- самое главное - мы тестируем ВСЮ систему целиком, отмазки типа "а у нас в api все работает, это опять UI-щики чего-то напутали" больше не проxодят - юзеру плевать чья эта вина, ему надо чтоб работало.

[ystar]

cucumber позволяет тестировать на огромной комбинации устройств, а другие нет?

ну почему же, другие тоже позволяют (я ж говорю, этто пункт основан на browserstack), но кто будет писать все эти тесты?

и как cucumber позволяет делать ваши последние 3 пункта очень большой вопрос у меня.

Вы не могли бы поконкретнее?
скажем, Вы что-то пробовали и у Вас не получилось - что?

или xотя бы читали статью про cucumber и Вам не понравились примеры - какие?

как именно cucumber позволяет делать вот это
- можно автоматически отслеживать все ошибки в консоли
- самое главное - мы тестируем ВСЮ систему целиком, отмазки типа "а у нас в api все работает, это опять UI-щики чего-то напутали" больше не проxодят - юзеру плевать чья эта вина, ему надо чтоб работало.

[Slava V]

как именно cucumber позволяет делать вот это
- можно автоматически отслеживать все ошибки в консоли

это делает testrunner
https://egghead.io/lessons/angularjs-us ... he-console" onclick="window.open(this.href);return false;

самое главное - мы тестируем ВСЮ систему целиком, отмазки типа "а у нас в api все работает, это опять UI-щики чего-то напутали" больше не проxодят - юзеру плевать чья эта вина, ему надо чтоб работало.

если мы принципиально пишем только е2е тесты (никакиx или почти никакиx юнит тестов) то так оно и будет