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

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

Andriano
29.09.2017
12:05:47

roma
29.09.2017
12:05:52

Google

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

roma
29.09.2017
12:06:01

Artem
29.09.2017
12:06:07
поэтому ваш спор заведомо бессмыслен

roma
29.09.2017
12:06:10

Artem
29.09.2017
12:06:44
можете заканчивать =)

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

Pavel
29.09.2017
12:09:48
девопс это про процесс, а не про выделенную роль
Есть должности devops engineer, или по нашему девопсы, которые все время и занимаются подстройкой инфраструктуры, ревьюингом багов и т.д.
Все деления на разрабов/qa/админов/девапсов плюс-минус условны, каждый человек может включать в себя несколько ролей. Иногда можно обойтись без всех.
У нас кстати qa открестились от написания e2e тестов, мы это делаем силами dev команды.

Andriano
29.09.2017
12:10:57

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

Andriano
29.09.2017
12:12:50

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

Google

Dmitry
29.09.2017
12:14:06
После внедрения
Какой Профит итд

Shoo
29.09.2017
12:16:14
Ну, и со всем остальным так же.
Разработчик может писать e2e тесты. Только вот в TDD и XP это не укладывается.
Разработчик может формировать критерии качества, ставить метрики и отвечать за их выполнение. Только в перечисленные практики это тоже не укладывается.
И тестить руками разработчик тоже может, но проблема та же.
Так мы и приходим к тому, что ваше волшебное заклинание "TDD, XP и парное программирование" нифига не решает задач QA, т.е. не работает.
Нужно ещё массу всего поверх накрутить и выстроить, и может быть оно заработает.
Но тут есть проблема: много ли есть на рынке разработчиков, способных параллельно и качественно выполнять функции аналитика, qa и разработчика (а лучше фуллстэка с опытом девопс, ага)?
Нет, таких ребят довольно мало. Плюс к этому они, обычно, довольно хорошо устроены в плане работы и стоят как этот самый аналитик, тестировщик и разработчик вместе взятые.


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

Pavel
29.09.2017
12:23:25
А трипл тестирование бывает?

Vlad
29.09.2017
12:23:47

Egor
29.09.2017
12:23:53
Бывает, в баре

Dieva
29.09.2017
12:24:00

Pavel
29.09.2017
12:24:02
?

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

Shoo
29.09.2017
12:25:14

Egor
29.09.2017
12:26:07
Этот подход использовался, когда в наличие есть руки, но нет времени и нужно писать отчет о том что было протестировано\
ОДин тестирует, второй готовит по ходу отчет

Vlad
29.09.2017
12:27:57

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

Pavel
29.09.2017
12:29:16
Блин неужели это так важно?

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

Google

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

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

Vlad
29.09.2017
12:29:49
почему не тестирует?
если человека зовут разраб, это не значит, что он не должен тестировать.

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

Vlad
29.09.2017
12:31:04
Вам спасибо, что подняли интересный вопрос.

Danil
29.09.2017
12:36:17
Какими инструментами пользуетесь для кроссбраузерного регрессионного тестирования?

Zuboff
29.09.2017
12:40:58
Как по мне в вопросе содержится ответ

Vladimir
29.09.2017
12:45:00
Браузерами, наверное (:

Aleksandr
29.09.2017
12:59:07

Dieva
29.09.2017
13:00:32

Danil
29.09.2017
13:00:32

Dieva
29.09.2017
13:00:47
я думаю что именно это имелось ввиду

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

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

Richard
29.09.2017
13:27:22
Конечно должен.

Dieva
29.09.2017
13:27:31

Shoo
29.09.2017
13:28:14

Vladimir
29.09.2017
13:29:52

Aleksandr
29.09.2017
13:30:23

Google

Shoo
29.09.2017
13:31:15
А кто должен? :)
Если в команде принята практика писать тесты на свой код, то любой разработчик в команде, независимо от степени сеньорности, должен это делать.
Если такой практики в команде нет - то никто не должен. Логично же.

Aleksandr
29.09.2017
13:32:29

Shoo
29.09.2017
13:32:39
Нет, не сомнительная.

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

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

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


Shoo
29.09.2017
13:34:59
Ты сегодня немногословен. Выбивать пояснения надо. :)
Ну, допустим. У вас есть задача: быстро запрототипировать сервис, проверить теорию и или удалить репозиторий, или развивать уже в качестве полноценного продукта.
Вот на этапе создания условного MVP, когда нужно "быстро и дешево" - тесты это очевидный оверхед и нахрен не нужны.
Это в качестве примера.
Друзья, обязательное написание юнитов - это довольно большие косты.
Для всех практик есть соотношение стоимости их применения и выхлопа от оных.
Если у вас есть на продукте высокий регрешшен рейт, например - юниты могут помочь решить эту проблему. Это, правда, выльется в сильное замедление (и увеличение стоимости, как следствие) разработки, но тут надо смотреть на это самое соотношение costs vs values.


Aleksandr
29.09.2017
13:38:29

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

Vladimir
29.09.2017
13:39:17
Costs vs values всегда важны ))

Aleksandr
29.09.2017
13:39:27

Vladimir
29.09.2017
13:39:36
Идеалисты могут про них забыть)

Shoo
29.09.2017
13:39:57

Aleksandr
29.09.2017
13:40:47

Evgeniy
29.09.2017
13:41:00

Aleksandr
29.09.2017
13:41:22

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

Google

Aleksandr
29.09.2017
13:42:20

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

Aleksandr
29.09.2017
13:42:46
Меньше багов уходит на тестирование.

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

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

Filipp
29.09.2017
13:45:06
Слепое утверждение "юнит тесты должны обязательно писаться всегда" - попытка изобрести silver bullet там, где их нет в принципе.
Напоминание об отсутствии серебряных пуль - вещь, безусловно правильная. И анализировать соотношение выгоды/затрат тоже крайне желательно. Но все-таки у меня было ощущение, что за редким исключением юнит-тесты полезны. Это дополнительный барьер для багов, очень серьезная поддержка при рефакторинге и переезде на новые технологии. Жаль, личный опыт - не статистика, но вот как раз с "динамичной кодовой базой" и без тестов проект был болью - отвалиться могло что угодно и где угодно. А сейчас на проекте с юнит-тестами жизнь играет гораздо более позитивными красками
Хотя, конечно, это не статистика, и там много факторов было кроме юнит-тестов


Shoo
29.09.2017
13:46:20
Юниты не гарантирую правильную работу фичи, в этом проблема.

Artur
29.09.2017
13:46:37

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

Filipp
29.09.2017
13:48:01

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

Artur
29.09.2017
13:50:38

Evgeniy
29.09.2017
13:51:17

Filipp
29.09.2017
13:53:14

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