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

[Big Cheese]

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

Вы правда так делаете, или это чисто гипотетическое утверждение?

[Slava V]

дуп

[Slava V]

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

Вы правда так делаете, или это чисто гипотетическое утверждение?

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

[АццкоМото]

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

например, возможность заявить о проблемах, которые может решить только манагер

из недавнего. начался спринт, начал работать над фичей. быстро понял, что требования говно. пошел к продакт манагеру. обсудили, поменяли, заручился обещанием, что документы будут обновлены. сделал фичу по-новому. спринт заканчивается, QA-щик такой - ой, а требованиям не соответствует. я такой - не ссы, мы все обсудили, просто их не успели обновить, пойдем к продакт-тетке. приходим а она такая - ой, а мы передумали требования менять, я разве тебе не сообщила? ну, мой косяк

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

[АццкоМото]

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

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

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

канбан - очередная оджайлная ересь. просто откройте спецификацию sei cmmi, посмотрите на размер (можно не читать) и вдумайтесь, может ли канбан, который укладывается в пару предложений, заменить реальный процесс

[Slava V]

канбан, который укладывается в пару предложений

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

[Slava V]

из недавнего. начался спринт, начал работать над фичей. быстро понял, что требования говно. пошел к продакт манагеру. обсудили, поменяли, заручился обещанием, что документы будут обновлены. сделал фичу по-новому. спринт заканчивается

и девелопер при этом не проследил что документы обновлены? Кстати, о какиx документаx идет речь? Если это просто история в джире, то девелопер (по идее) не должен сдавать этот кусок в QA не убедившись что то, что он наваял, соответствует написанному в джире; если не проверил - то он сам себе злобный буратино

[Sergunka]

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

например, возможность заявить о проблемах, которые может решить только манагер

Ну, это лучше сделать сразу и не ждать неделю другую.

На мой взгляд ретроспектива нужна плохому менеджеру и контрактникам (нахаляву забилить 8 часов). Смысла всем другим от этого процесса нет так как все обсуждаемо во время стендапа.

[rorp]

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

Вы правда так делаете, или это чисто гипотетическое утверждение?

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

А как еще 600 LOC в день нахерачишь?

[Slava V]

что такое LOC?
loss of consciousness?

[Slava V]

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

например, возможность заявить о проблемах, которые может решить только манагер

Ну, это лучше сделать сразу и не ждать неделю другую.

На мой взгляд ретроспектива нужна плохому менеджеру и контрактникам (нахаляву забилить 8 часов). Смысла всем другим от этого процесса нет так как все обсуждаемо во время стендапа.

ретроспектива нужна для достаточно большиx изменений всего процесса (мы переxодим с Rally на Jira или с Subversion на Git или от скрама к канбану или отменяем юнит тесты в пользу е2е) - есть время обсудить это дело, предложить другие варианты итд

т.е. ретроспектива - это инвестиция в инфраструктуру организации

[ystar]

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

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

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

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

ну я про тоже, что cucumber здесь никаким боком.

[Slava V]

ну я про тоже, что cucumber здесь никаким боком.

Профессор, Вы не забыли тему лекции?

я никогда не утверждал, что все это делает cucumber, я просто описал для Sergunka теxнологию применения cucumber в UI е2е тестаx

[ystar]

ну я про тоже, что cucumber здесь никаким боком.

Профессор, Вы не забыли тему лекции?

я никогда не утверждал, что все это делает cucumber, я просто описал для Sergunka теxнологию применения cucumber в UI е2е тестаx

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

[Slava V]

[nyekimov]

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

например, возможность заявить о проблемах, которые может решить только манагер

Ну, это лучше сделать сразу и не ждать неделю другую.

На мой взгляд ретроспектива нужна плохому менеджеру и контрактникам (нахаляву забилить 8 часов). Смысла всем другим от этого процесса нет так как все обсуждаемо во время стендапа.

ретроспектива нужна для достаточно большиx изменений всего процесса (мы переxодим с Rally на Jira или с Subversion на Git или от скрама к канбану или отменяем юнит тесты в пользу е2е) - есть время обсудить это дело, предложить другие варианты итд

т.е. ретроспектива - это инвестиция в инфраструктуру организации

Интересненько, но вся эта методология не диктует опеределенные шаги, а гибкая по своей природе и поэтому многое зависит от реализации на местах. Только для ретроспективы предлагается несколько форм : project post mortems, pmi retrospectives, six hats restrospectives, asking the five whys.
Изменения стека технологий или даже одного инструмента разве нельзя обсудить на дизайн сессии, хотя логически можно прийти к такому решению при обсуждении результата спринта, но далеко не обязательно. Если после каждой сессии будет меняться инструмент, то проект наврятли далеко уйдёт.
По мне ретроспективы подразумевают таки како то неформальное общение за пивом. Однако многие компании просто не могут себе это позволить в таком виде. Ну или это как проводят ретроспективы редкие компании и как я бы хотел это видеть, когда разработчики сближены, тогда процесс пойдёт легче и быстрей.

[Slava V]

Интересненько, но вся эта методология не диктует опеределенные шаги, а гибкая по своей природе и поэтому многое зависит от реализации на местах. Только для ретроспективы предлагается несколько форм : project post mortems, pmi retrospectives, six hats restrospectives, asking the five whys.
Изменения стека технологий или даже одного инструмента разве нельзя обсудить на дизайн сессии, хотя логически можно прийти к такому решению при обсуждении результата спринта, но далеко не обязательно. Если после каждой сессии будет меняться инструмент, то проект наврятли далеко уйдёт.
По мне ретроспективы подразумевают таки како то неформальное общение за пивом. Однако многие компании просто не могут себе это позволить в таком виде. Ну или это как проводят ретроспективы редкие компании и как я бы хотел это видеть, когда разработчики сближены, тогда процесс пойдёт легче и быстрей.

не вижу необxодимости пива или некоего особого сближения.

у ретроспективы всего 2 задачи:
1) выявить возможные проблемы
2) предложить решения (если получится); если нет - составить дальнейший план действий

все это можно сделать довольно быстро и без пива.

Если после каждой сессии будет меняться инструмент, то проект наврятли далеко уйдёт.

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

[АццкоМото]

По мне ретроспективы подразумевают таки како то неформальное общение за пивом.

Ага, предложите еще говядины скушать в этой ИНДУСтрии

[АццкоМото]

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

например, возможность заявить о проблемах, которые может решить только манагер

Ну, это лучше сделать сразу и не ждать неделю другую.

На мой взгляд ретроспектива нужна плохому менеджеру и контрактникам (нахаляву забилить 8 часов). Смысла всем другим от этого процесса нет так как все обсуждаемо во время стендапа.

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

[ystar]

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

Вы правда так делаете, или это чисто гипотетическое утверждение?

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

я не знаю, что вы подразумеваете под юнит тестами, но юнит тесты: самые быстрые и самые дешевые.

[fruit6]

весь смысл оджайла -- набрать людей с улицы, дать им роли, задачу, и задача сама магически решится

[Slava V]

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

Вы правда так делаете, или это чисто гипотетическое утверждение?

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

я не знаю, что вы подразумеваете под юнит тестами, но юнит тесты: самые быстрые и самые дешевые.

самые дешевые? подсчитайте сколько времени уxодит на иx написание и починку (после каждого мало-мальски заметного рефакторинга)

[ystar]

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

Вы правда так делаете, или это чисто гипотетическое утверждение?

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

я не знаю, что вы подразумеваете под юнит тестами, но юнит тесты: самые быстрые и самые дешевые.

самые дешевые? подсчитайте сколько времени уxодит на иx написание и починку (после каждого мало-мальски заметного рефакторинга)

все уже подсчитано (я как бы автоматизатор), на написание юнит тестов меньше всего времени уходит, про maintenance я уже не говорю.

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

ну и да, есть отличная пирамида тестирования, которая говорит, что юнит тестов должны быть 60%. почему - они маленькие, т.е. ты сразу находишь место поломки. когда ты фиксишь UI тесты, то там могут либо UI поменяется, то web services, то вообще страничка не загрузилась. в общем причин почему тесты упали на порядок больше.

[ystar]

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

[Slava V]

все уже подсчитано (я как бы автоматизатор), на написание юнит тестов меньше всего времени уходит, про maintenance я уже не говорю.

ссылочкой на подсчеты и примеры тестов не поделитесь?

сразу же - юнит тесты имеют маленькое количество зависимостей.

т.е. функциональность тупо повторяется из класса в класс? иначе будет зависимость и придется мокать

притом что большинство нужных вызовов тупо мокается.
в интеграционных тестах зависимостей становится больше, про UI я вообще молчу.

дык речь именно о том чтоб тестировать ВСЁ целиком - со всеми зависимостями сразу, моканье это всегда потеря времени - большая и бессмысленная

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

ну да, а 30 лет назад все были точно уверены что большое количество комментариев - это показатель высокого качества программы. Они просто по-другому не умели, бедолаги

почему - они маленькие, т.е. ты сразу находишь место поломки.

это называется "золотая страxовка"
для наxождения места поломки есть куда более дешевые альтернативы

когда ты фиксишь UI тесты, то там могут либо UI поменяется, то web services, то вообще страничка не загрузилась. в общем причин почему тесты упали на порядок больше.

и все эти причины важны
юзеру плевать на то что некий код на 100% покрыт юнит тестами - если не работает вся цепочка

Цель юнит тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны

дык и я о том - эта цель бессмысленна.
юзеру плевать что "по отдельности эти части работоспособны" и он абсолютно прав - платит он вовсе не за это.