> Кто формирует критерии качества продукта, следит за соответствием релизов оным и прочее? Кто пишет E2E тесты на выпускаемый функционал? Разрабы и девопсы могут вполне этим заниматься, в тесном сотрудничестве с product owner

Критерии качества определяет заказчик, разработчик самостоятельно пишет юнит тесты по tdd, пишет интеграционные тесты и e2e. Всё сам делает. Но это работает только когда разработчик очень опытный и заказчик даёт исчерпывающие требования, критерии качетсва, приёмки. А разработчик плюс ко всему следит за логами

Критерии качества определяет заказчик, разработчик самостоятельно пишет юнит тесты по tdd, пишет интеграционные тесты и e2e. Всё сам делает. Но это работает только когда разработчик очень опытный и заказчик даёт исчерпывающие требования, критерии качетсва, приёмки. А разработчик плюс ко всему следит за логами

ну и видимо когда делается лендинг

> Кто формирует критерии качества продукта, следит за соответствием релизов оным и прочее? Кто пишет E2E тесты на выпускаемый функционал? Разрабы и девопсы могут вполне этим заниматься, в тесном сотрудничестве с product owner

девопс это про процесс, а не про выделенную роль

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

ну и видимо когда делается лендинг

не только))

поэтому ваш спор заведомо бессмыслен

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

конечно)

можете заканчивать =)

поэтому я там выше в 14:56 написал как приходится работать)

расходимся)

девопс это про процесс, а не про выделенную роль

Есть должности devops engineer, или по нашему девопсы, которые все время и занимаются подстройкой инфраструктуры, ревьюингом багов и т.д. Все деления на разрабов/qa/админов/девапсов плюс-минус условны, каждый человек может включать в себя несколько ролей. Иногда можно обойтись без всех.

У нас кстати qa открестились от написания e2e тестов, мы это делаем силами dev команды.

У нас кстати qa открестились от написания e2e тестов, мы это делаем силами dev команды.

почему?

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

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

агонь

Расскажи потом об опыте внедрения парного тестирования.

После внедрения

Какой Профит итд

Критерии качества определяет заказчик, разработчик самостоятельно пишет юнит тесты по tdd, пишет интеграционные тесты и e2e. Всё сам делает. Но это работает только когда разработчик очень опытный и заказчик даёт исчерпывающие требования, критерии качетсва, приёмки. А разработчик плюс ко всему следит за логами

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

Ну, и со всем остальным так же. Разработчик может писать e2e тесты. Только вот в TDD и XP это не укладывается. Разработчик может формировать критерии качества, ставить метрики и отвечать за их выполнение. Только в перечисленные практики это тоже не укладывается. И тестить руками разработчик тоже может, но проблема та же. Так мы и приходим к тому, что ваше волшебное заклинание "TDD, XP и парное программирование" нифига не решает задач QA, т.е. не работает. Нужно ещё массу всего поверх накрутить и выстроить, и может быть оно заработает.

Но тут есть проблема: много ли есть на рынке разработчиков, способных параллельно и качественно выполнять функции аналитика, qa и разработчика (а лучше фуллстэка с опытом девопс, ага)? Нет, таких ребят довольно мало. Плюс к этому они, обычно, довольно хорошо устроены в плане работы и стоят как этот самый аналитик, тестировщик и разработчик вместе взятые.

Парное тестирование - это когда один тыкает мышкой в экран, второй записывает его действие ввиде сценариев/ЧЛ. Так ведь?

А трипл тестирование бывает?

Парное тестирование - это когда один тыкает мышкой в экран, второй записывает его действие ввиде сценариев/ЧЛ. Так ведь?

чтозабред....

Бывает, в баре

А трипл тестирование бывает?

трип тестирование бывает

?

чтозабред....

прошу пояснить

в последний раз этот термин "парное тестирование" видел именно в сказанном мной контексте. Вот и хочу уточнить, на сколько этот термин мутировал с тех времен

Парное тестирование - это когда один тыкает мышкой в экран, второй записывает его действие ввиде сценариев/ЧЛ. Так ведь?

Но, простите, зачем?

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

ОДин тестирует, второй готовит по ходу отчет

в последний раз этот термин "парное тестирование" видел именно в сказанном мной контексте. Вот и хочу уточнить, на сколько этот термин мутировал с тех времен

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

Эм. ТО есть парное тестирование - это один тестирует, второй сразу правит?

Блин неужели это так важно?

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

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

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

почему не тестирует?

если человека зовут разраб, это не значит, что он не должен тестировать.

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

Вам спасибо, что подняли интересный вопрос.

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

Как по мне в вопросе содержится ответ

Браузерами, наверное (:

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

Браузерами. Или в чате не поняли вопрос.

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

http://www.internet-technologies.ru/articles/article_2830.html

Браузерами. Или в чате не поняли вопрос.

Конкретно скриншот тестирование. Пример: https://github.com/gemini-testing/gemini

я думаю что именно это имелось ввиду

Так вам скриншотное тестирование, или кроссбраузерное? :)

Вопрос: Developer Senior должен покрывать свой код unit тестами? (по крайней мере он себя так называет Senior =) )

Конечно должен.

Вопрос: Developer Senior должен покрывать свой код unit тестами? (по крайней мере он себя так называет Senior =) )

и не только синьор)

Вопрос: Developer Senior должен покрывать свой код unit тестами? (по крайней мере он себя так называет Senior =) )

Нет, не должен.

Вопрос: Developer Senior должен покрывать свой код unit тестами? (по крайней мере он себя так называет Senior =) )

зависит от того, какие стандарты в компании.

Нет, не должен.

А кто должен? :)

А кто должен? :)

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

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

Логично. Но вот отсутствие такой практики, сомнительная затея.

Нет, не сомнительная.

Ты сегодня немногословен. Выбивать пояснения надо. :)

Все сильно зависит от ситуации и потребностей бизнеса. Все эти ваши "бест практисес" сильно ситуативны и не стоит их применять просто что б применять.

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

Ты сегодня немногословен. Выбивать пояснения надо. :)

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

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

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

Это в качестве примера.

Друзья, обязательное написание юнитов - это довольно большие косты. Для всех практик есть соотношение стоимости их применения и выхлопа от оных. Если у вас есть на продукте высокий регрешшен рейт, например - юниты могут помочь решить эту проблему. Это, правда, выльется в сильное замедление (и увеличение стоимости, как следствие) разработки, но тут надо смотреть на это самое соотношение costs vs values.

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

При прототипировании-то конечно.

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

Costs vs values всегда важны ))

Друзья, обязательное написание юнитов - это довольно большие косты. Для всех практик есть соотношение стоимости их применения и выхлопа от оных. Если у вас есть на продукте высокий регрешшен рейт, например - юниты могут помочь решить эту проблему. Это, правда, выльется в сильное замедление (и увеличение стоимости, как следствие) разработки, но тут надо смотреть на это самое соотношение costs vs values.

Где-то читал, чтобы ускорить выпуск фич, нужно замедлить разработку. Т.е. больше думать и тестировать. Для большинства продуктов, это так и есть.

Идеалисты могут про них забыть)

Где-то читал, чтобы ускорить выпуск фич, нужно замедлить разработку. Т.е. больше думать и тестировать. Для большинства продуктов, это так и есть.

Только написание юнитов может никак не сокращать скорость тестирования вообще.

Только написание юнитов может никак не сокращать скорость тестирования вообще.

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

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

Лол

Лол

Обоснуй. :)

Ну, в итоге длительность разработки у вас увеличивается (порядочно так), длительность тестирования и планирования остается прежней. Вы начинаете быстрее выпускать фичи? (Спойлер: нет)

Ну, в итоге длительность разработки у вас увеличивается (порядочно так), длительность тестирования и планирования остается прежней. Вы начинаете быстрее выпускать фичи? (Спойлер: нет)

У нас увеличивается качество кода.

Я на своей практике видел достаточно много случаев, когда дешевле, проще и правильнее было 3 раза написать хреново, показать feature ownerу, получить фидбэк и вылить, чем классно подумать, хорошо оттестировать, юнитов наворотить, а через N*3 это выкинуть к херам.

Меньше багов уходит на тестирование.

У нас увеличивается качество кода.

Оно может увеличиваться.

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

Тестировщик как проверял 10 сценариев по фиче, так и будет проверять.

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

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

Хотя, конечно, это не статистика, и там много факторов было кроме юнит-тестов

Тестировщик как проверял 10 сценариев по фиче, так и будет проверять.

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

Юниты не гарантирую правильную работу фичи, в этом проблема.

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

Ну я рассматривал время тестирования, т.е. столько, сколько тестировщик проверяет фичу.

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

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

Ну я рассматривал время тестирования, т.е. столько, сколько тестировщик проверяет фичу.

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

при создании мавенского с зависимостями log4j проекта в идее в папке ресурсы файл log4j.properties сам создается или откуда его брать со стандартными настройками?

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

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

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

Процедурное программирование, database oriented разработка . Data driven тестирование - по сути юнит тестирование- если ЭТО не тестирование в таком проекте, тогда что?

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

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

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

Это сильно зависит от очень большого количества факторов.

У нас, например, довольно высокий кавередж на текущем проекте, но падения тестов преимущественно псевдослучайные. Багов от этого меньше не становится.