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

[Slava V]

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

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

логическими аргументами - например, на пальцаx объяснить чем подxод А (в данныx конкретныx условияx) лучше подxода В

[Slava V]

Без тестов невозможно, а без TDD, BDD, и прочая, и прочая, вполне возможно.

скажите, а в чем (по-Вашему) смысл всего этого мероприятия?

[АццкоМото]

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

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

логическими аргументами - например, на пальцаx объяснить чем подxод А (в данныx конкретныx условияx) лучше подxода В

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

[stenking]

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

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

логическими аргументами - например, на пальцаx объяснить чем подxод А (в данныx конкретныx условияx) лучше подxода В

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

А что, хорошая идея.

Дано: довольно сложная система ну скажем типа Jira. 50К платящих клиентов, множество всяких настроек, воркфлоус, кастомизаций, фильтров, вьюс и т.д. Постоянно нужно что-то улучшать, переделывать и добавить скажем возможность тайм тракинга и аппрувания часов для админов. Есть команда из 20 программистов которая это все дело делает из разных офисов.

Задача: наладить процесс разработки.

Дополнительные условия: Поддержка существующих клиентов это абсолютный приоритет - они же платят деньги. Т.е. самое главное что бы у существующих клиентов было как можно меньше проблем.

[АццкоМото]

А что, хорошая идея.

Дано: довольно сложная система ну скажем типа Jira. 50К платящих клиентов, множество всяких настроек, воркфлоус, кастомизаций, фильтров, вьюс и т.д. Постоянно нужно что-то улучшать, переделывать и добавить скажем возможность тайм тракинга и аппрувания часов для админов. Есть команда из 20 программистов которая это все дело делает из разных офисов.

Задача: наладить процесс разработки.

Дополнительные условия: Поддержка существующих клиентов это абсолютный приоритет - они же платят деньги. Т.е. самое главное что бы у существующих клиентов было как можно меньше проблем.

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

[rorp]

А если подождать -- вариант, то можно нанять русских теток из портновской школы. Они тебе столько багов нароют, сколько никакой *DD не сможет.

Найти баги в релизе - это ерунда. Как обеспечить стабильность системы которая активно разрабатывается - вот в чём вопрос. TDD/CI/CD и прочее - нужно именно для этого.

Иначе начинается бесконечный ад с чиним одно а ломается другое.

Товарищ выше уже ответил.

[АццкоМото]

TDD/CI/CD и прочее - нужно именно для этого.

Иначе начинается бесконечный ад с чиним одно а ломается другое.

кстати, добавлю. ничего не имею против ci/cd. но tdd ведет к еще большему аду - пишем в два раза больше, а меняем потом 100500 тестов. потому что почти всегда серьезное изменение требований, которое может быть реализовано тем не менее в одно рыло за день-два, ломает столько тестов, что мама не горюй. понятно, что если цвет кнопки перекрасили, все скорей всего пройдет гладко. переставили местами два экрана в популярном воркфлоу - ура, триста тестов фейлд, нормальным поцанам нет времени править, нужен либо пердиш насрал (со всеми последствиями), либо включается режим "потом поправим", который не закончится никогда.

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

[Slava V]

А что, хорошая идея.

Дано: довольно сложная система ну скажем типа Jira. 50К платящих клиентов, множество всяких настроек, воркфлоус, кастомизаций, фильтров, вьюс и т.д. Постоянно нужно что-то улучшать, переделывать и добавить скажем возможность тайм тракинга и аппрувания часов для админов. Есть команда из 20 программистов которая это все дело делает из разных офисов.

Задача: наладить процесс разработки.

Дополнительные условия: Поддержка существующих клиентов это абсолютный приоритет - они же платят деньги. Т.е. самое главное что бы у существующих клиентов было как можно меньше проблем.

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

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

[АццкоМото]

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

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

[Slava V]

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

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

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

не иначе, телегонией телепатией?

[АццкоМото]

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

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

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

не иначе, телегонией телепатией?

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

[Slava V]

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

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

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

не иначе, телегонией телепатией?

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

ну и чем Вас не устраивает идея запускать автоматические е2е тесты по тем же требованиям?

[АццкоМото]

ну и чем Вас не устраивает идея запускать автоматические е2е тесты по тем же требованиям?

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

плюс, не надо путать автотесты с юнит тестами

[Slava V]

ну и чем Вас не устраивает идея запускать автоматические е2е тесты по тем же требованиям?

всем устраивает
но писать их раньше кода - не устраивает

плюс, не надо путать автотесты с юнит тестами

юнит тесты меня вообще не интересуют (см выше большую дискуссию о ниx)

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

писать так, чтобы понял идиот - не устраивает

почему? просто лень или xочется чтоб все помучились, читая невнятное описание задачи?

[АццкоМото]

почему? просто лень или xочется чтоб все помучились, читая невнятное описание проекта?

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

полная бессмыслица. как и идея о том, что огуречные тесты это "описание проекта"

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

[АццкоМото]

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

[Slava V]

почему? просто лень или xочется чтоб все помучились, читая невнятное описание проекта?

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

полная бессмыслица. как и идея о том, что огуречные тесты это "описание проекта"

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

Вы так и не рассказали нам, почему описание задачи не должно быть написано понятным языком, при чем тут чтение кода? при постановке задачи кода еще нету

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

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

начерта девелоперу тесты, написанные для домохозяйки?

потому что эти тесты пишут домоxозяйки (т.е. тестеры и люди которые разбираются в сути бизнеса)
и другие тесты взять неоткуда, да и незачем

[АццкоМото]

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

Вы так и не рассказали нам, почему описание задачи не должно быть написано понятным языком, при чем тут чтение кода? при постановке задачи кода еще нету

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

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

и другие тесты взять неоткуда, да и незачем

прям неоткуда? а откуда берутся тесты, написанные, например, на жабе? прямо с неба даром божьим?

[Slava V]

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

т.е. Вы любитель делать двойную работу? (и даже не двойную - кто будет проверять что тесты покрыли все требования?)

и вот так у ниx все ...

откуда берутся тесты, написанные, например, на жабе?

юнит тесты?
см выше

[АццкоМото]

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

т.е. Вы любитель делать двойную работу? (и даже не двойную - кто будет проверять что тесты покрыли все требования?)

я же написал - двойная интерпретация требований есть суть тестирования - см. выше

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

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

откуда берутся тесты, написанные, например, на жабе?

юнит тесты?
см выше

нет, не юнит тесты, а те самые, которые жмякают по кнопочкам

[Slava V]

я же написал - двойная интерпретация требований есть суть тестирования - см. выше

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

бдд предлагает верифицировать продукт по исxодному заданию (при том что задание могут читать все)
в Вашей версии появляется куча лишниx артефактов, которые еще надо проверять на соответствие друг другу

[АццкоМото]

извините, но это бред.

Не извиню, простите

1) оценку успешности реализации может дать только бизнес (если Вы не забыли, вся эта затея с проектом делается именно для бизнеса)

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

2) чем больше "интерпретаций" Вы навертите, тем больше возможности для ошибки

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

бдд предлагает верифицировать продукт по исxодному заданию (при том что задание могут читать все)
в Вашей версии появляется куча лишниx артефактов, которые еще надо проверять на соответствие друг другу

еще раз: исходное задание и тесты должны быть разными вещами. потому что в исходном задании я хочу, чтобы логин/ пароль admin/admin подходил, а в тесте я могу проверять, что аппа не крешится при разрыве соединения. потому что так было раньше. эти вещи уаще не связаны. и только не надо мне рассказывать, что в случае, если нам пришлось обновить тесты, то это кагбэ новое требование. оно не пришло оттуда же, откуда изначальное. это не естественно.

[stenking]

А что, хорошая идея.

Дано: довольно сложная система ну скажем типа Jira. 50К платящих клиентов, множество всяких настроек, воркфлоус, кастомизаций, фильтров, вьюс и т.д. Постоянно нужно что-то улучшать, переделывать и добавить скажем возможность тайм тракинга и аппрувания часов для админов. Есть команда из 20 программистов которая это все дело делает из разных офисов.

Задача: наладить процесс разработки.

Дополнительные условия: Поддержка существующих клиентов это абсолютный приоритет - они же платят деньги. Т.е. самое главное что бы у существующих клиентов было как можно меньше проблем.

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

Ну так значит мы об одном и том же говорим. Просто эти авто-тесты вешаются на каждый коммит/PR, выполняются параллельно на сервере а их результат пишется в Jenkins. Это и есть самое настоящее TDD/CI/CD

А писать эти функциональные тесты до или после, писать кодом или BDD это по обстоятельствам - мне кажется это не сильно влияет на процесс.

[stenking]

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

Ну так это и есть TDD/BDD. Ты хоть видел этот огурец?

Вот он https://github.com/cucumber/cucumber-js ... example.md" onclick="window.open(this.href);return false;

[АццкоМото]

А что, хорошая идея.

Дано: довольно сложная система ну скажем типа Jira. 50К платящих клиентов, множество всяких настроек, воркфлоус, кастомизаций, фильтров, вьюс и т.д. Постоянно нужно что-то улучшать, переделывать и добавить скажем возможность тайм тракинга и аппрувания часов для админов. Есть команда из 20 программистов которая это все дело делает из разных офисов.

Задача: наладить процесс разработки.

Дополнительные условия: Поддержка существующих клиентов это абсолютный приоритет - они же платят деньги. Т.е. самое главное что бы у существующих клиентов было как можно меньше проблем.

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

Ну так значит мы об одном и том же говорим. Просто эти авто-тесты вешаются на каждый коммит/PR, выполняются параллельно на сервере а их результат пишется в Jenkins. Это и есть самое настоящее TDD/CI/CD

А писать эти функциональные тесты до или после, писать кодом или BDD это по обстоятельствам - мне кажется это не сильно влияет на процесс.

Не-не-не! То, что я описал - это CI/CD. А чтобы оно стало TDD/BDD, нужно соответствовать куче других критериев, с которыми я в корне несогласен