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

[ystar]

У нас на 25 девелоперов 2 QA(от нас ожидается еще и automation), это ок или нет? У нас 'O'gile и много багов проскакивает, так как релиз каждые две недели обязательно должен произойти. В результате почти всегда hot fixes next day.

А какой код coverage на проекте?

Есть ли BDD и end2end тесты?

У нас примерно так и было 25/2 только правда релиз был каждые 10 спринтов и баг фиксинг после код фриз 2 недели до релиза. Код ковердж был 85% на BDD тестах.

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

лучше всего, чтобы юнит тестов процентов 60 было, ещё 30 апи тестов, ну и 10 % всяких ui тестов.

[ystar]

Ну, это просто показатель отсутствия мозгов у ответственных за процесс разработки.

У нас даже задание раздавали огурцами... но с увольнением ключевых менеджеров на проекте дело очень сильно стопорнулось и померло. Походу кроме меня огурцами в конторе никто не пользуется за редким исключением знаю еще один проект - фсе.

а потому что огурцы могут быть полезны лишь в некоторых случаях. А представьте себе страничку с 30-40 полями ввода.
ну и впринципе, по статистике на огурцах - гораздо ниже успешных автоматизационных проектов.

[АццкоМото]

С огурцами вообще плохая статистика. Почти все, кто принимали их 100 лет назад хоть перорально, хоть... Ну, не будем. Умерли, тащемта. Я бы не рекомендовал.

[Sergunka]

Девелоперы пишут юнит тесты (if they have time), а релиз каждые 2 недели так продукт в стадии активной разработки, по 10-15 фичек каждый спринт.

А какой прок с юнит теста? Если писать фичу то сначала надо БДД тест построить или у Вас там как-то подругому получается? Интересно было бы послушать.

[Sergunka]

С огурцами вообще плохая статистика. Почти все, кто принимали их 100 лет назад хоть перорально, хоть... Ну, не будем. Умерли, тащемта. Я бы не рекомендовал.

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

[Sergunka]

Ну, это просто показатель отсутствия мозгов у ответственных за процесс разработки.

У нас даже задание раздавали огурцами... но с увольнением ключевых менеджеров на проекте дело очень сильно стопорнулось и померло. Походу кроме меня огурцами в конторе никто не пользуется за редким исключением знаю еще один проект - фсе.

а потому что огурцы могут быть полезны лишь в некоторых случаях.
А представьте себе страничку с 30-40 полями ввода.

А как Вы огурцами страничку пытаетесь описать? Огурцы это всеж чистый бекенд для API.

ну и впринципе, по статистике на огурцах - гораздо ниже успешных автоматизационных проектов.

Я ответил чуть выше.

[Sergunka]

У нас на 25 девелоперов 2 QA(от нас ожидается еще и automation), это ок или нет? У нас 'O'gile и много багов проскакивает, так как релиз каждые две недели обязательно должен произойти. В результате почти всегда hot fixes next day.

А какой код coverage на проекте?

Есть ли BDD и end2end тесты?

У нас примерно так и было 25/2 только правда релиз был каждые 10 спринтов и баг фиксинг после код фриз 2 недели до релиза. Код ковердж был 85% на BDD тестах.

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

лучше всего, чтобы юнит тестов процентов 60 было, ещё 30 апи тестов, ну и 10 % всяких ui тестов.

Вы путаете селениум который шарится по веб страницам и который я как понимаю умер не родившись. Я вообще говорю для тестирования API.

[Big Cheese]

Девелоперы пишут юнит тесты (if they have time), а релиз каждые 2 недели так продукт в стадии активной разработки, по 10-15 фичек каждый спринт.

"В стадии активной разработки" это в смысле выкатываете v1.0? Или кастомеры уже есть?

[АццкоМото]

С огурцами вообще плохая статистика. Почти все, кто принимали их 100 лет назад хоть перорально, хоть... Ну, не будем. Умерли, тащемта. Я бы не рекомендовал.

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

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

[rialtoma1]

Кастомеры, конечно, уже есть, и фичи для них. Огурцом мы пользуемся для integration tests, но его нам сейчас предлагают исключить и писать на Pure Rspec. Потому что тесты с огурцом 6+ часов, их не устраивает.

Про unit tests- не знаю деталей, как они их пишут, но вроде сначала feature а потом к ней unit test. Ruby.

[АццкоМото]

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

[rialtoma1]

Очепятка. Fixed

[АццкоМото]

Очепятка.

понял, проехали

[Big Cheese]

Ну, это просто показатель отсутствия мозгов у ответственных за процесс разработки.

У нас даже задание раздавали огурцами... но с увольнением ключевых менеджеров на проекте дело очень сильно стопорнулось и померло. Походу кроме меня огурцами в конторе никто не пользуется за редким исключением знаю еще один проект - фсе.

Огурцы ИМХО - не панацея, даже я бы сказал наоборот. Я сам огурцы не курю, но приходилось на прошлой работе разруливать проект изваянный огурцоводами; общее впечатление - как в том анекдоте про поручика Ржевского ("без окон, без дверей, полна жопа огурцов").

[Sergunka]

Ну, это просто показатель отсутствия мозгов у ответственных за процесс разработки.

У нас даже задание раздавали огурцами... но с увольнением ключевых менеджеров на проекте дело очень сильно стопорнулось и померло. Походу кроме меня огурцами в конторе никто не пользуется за редким исключением знаю еще один проект - фсе.

Огурцы ИМХО - не панацея, даже я бы сказал наоборот. Я сам огурцы не курю, но приходилось на прошлой работе разруливать проект изваянный огурцоводами; общее впечатление - как в том анекдоте про поручика Ржевского ("без окон, без дверей, полна жопа огурцов").

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

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

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

[АццкоМото]

ТДД вообще зло с самого начала

[ystar]

У нас на 25 девелоперов 2 QA(от нас ожидается еще и automation), это ок или нет? У нас 'O'gile и много багов проскакивает, так как релиз каждые две недели обязательно должен произойти. В результате почти всегда hot fixes next day.

А какой код coverage на проекте?

Есть ли BDD и end2end тесты?

У нас примерно так и было 25/2 только правда релиз был каждые 10 спринтов и баг фиксинг после код фриз 2 недели до релиза. Код ковердж был 85% на BDD тестах.

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

лучше всего, чтобы юнит тестов процентов 60 было, ещё 30 апи тестов, ну и 10 % всяких ui тестов.

Вы путаете селениум который шарится по веб страницам и который я как понимаю умер не родившись. Я вообще говорю для тестирования API.

А почему вы считаете, что селениум умер?

[mavr]

тотал коммандер - еще подревнее FAR однако

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

Унылое говно это как раз виндовый и маковский интерфейсы когда регулярно нужно много файловых операций.
FAR кстати к текстовому режиму не имеет никакого отношения он давно графический и в винду интегрирован по самое немогу.

Люблю послушать когда девелоперы рассказывают мне как лучше делать мою работу

[АццкоМото]

FAR кстати к текстовому режиму не имеет никакого отношения он давно графический

Что, простите? ФАР графический? Ояе... Я даже не знаю, как вам возразить. Это так же нелепо, как сегодняшнее заявление в соседней ветке, что типа "мнимая единица присутствует в десятичной системе". Ужоснах

[Big Cheese]

У нас даже задание раздавали огурцами... но с увольнением ключевых менеджеров на проекте дело очень сильно стопорнулось и померло. Походу кроме меня огурцами в конторе никто не пользуется за редким исключением знаю еще один проект - фсе.

Огурцы ИМХО - не панацея, даже я бы сказал наоборот. Я сам огурцы не курю, но приходилось на прошлой работе разруливать проект изваянный огурцоводами; общее впечатление - как в том анекдоте про поручика Ржевского ("без окон, без дверей, полна жопа огурцов").

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

Огурец вроде как БДД. ТДД ИМХО можно делать на любым test framework-е (в разумных пределах), а вот с БДД все как-то неоднозначно на мой взгляд. С одной стороны, я согласен с Вашими аргументами про внятную спецификацию и историю изменений, но только при условии, что все вовлеченные в процесс люди "в теме". С другой стороны, из того, что я видел - всякие прохиндеи впаривают БДД/огурец, как очередную вундервафлю - типа, вот сейчас наши non-technical stakeholders наконец-то заговорят на одном языке с технарями. Это, на мой взгляд - разговор в пользу бедных..

Что касается "а как по-другому?"/"как правильно?" - я, честно говоря, не знаю. У себя я стараюсь все делать максимально итеративно и постоянно показывать свеженаваяное всем заинтересованным сторонам. Так легче собирать фидбек и постепенно выходить на общее видение/понимание задач.

[X37WAL!^]

Рассказываю. У нас вообще QA нет. Упразднили вместе с суппортом лет 10 назад. В нашей команде три недели десяток девелоперов пишут код, потом неделя freeze и cross-testing "чужих" фич, аффтары фиксят баги, потом релиз.

[fruit6]

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

[X37WAL!^]

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

Не соглашусь. Если мы про чистый, назамутнённый software development, где все процессы красиво устроены и все выполняют свои обязанности. Однако есть места, где границы между business/operations/development сильно подразмыты и вот там вместо тдд и бдд старый метод "гадание на кофейной гуще" как ни крути выходит более эффективным.

[Sergunka]

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

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

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

[Sergunka]

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

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