Re[4]: Зачем вообще QA и мэнэджеры? - О работе

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, StanislavK, Вы писали:

SK>>От одного менеджера ты фиг избавишься, но тестеры и аналитики, на мой взгляд, это лишний груз.
CC>Ох не попадалось вам работать с толковыми менеджерами, тестерами и аналитиками.
Не поверишь, как не поговорю с ними, так и говорят! Ты, говорят, просто не понимаешь как мы нужны! Плати давай нам бабло!

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

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

Теперь аналитики. Тут я совсем теряюсь. Они типа должны говорить с бизнесом узнавать, что же они хотят, потом это аккуратно записывать и передавать дальше. Ессесно это порождает кучу процесса, вопросов и документации, что в итоге все замедляет и искажает изначальные требования. Еще это поощряет тупых разработчиков с подходом типа "А че, я накодил как написано было!".
Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу. Решит много проблем — надо меньше документыции, меньше процесса, из-за экономии времени фичи тоже становятся меньше, так как бизнес не старается впихнуть все и сразу из-за боязни, что шас все убегут делать и пол-года ни фич и ни фидбэка.

Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, CreatorCray, Вы писали:

CC>>Здравствуйте, StanislavK, Вы писали:

SK>>>От одного менеджера ты фиг избавишься, но тестеры и аналитики, на мой взгляд, это лишний груз.
CC>>Ох не попадалось вам работать с толковыми менеджерами, тестерами и аналитиками.
SK>Не поверишь, как не поговорю с ними, так и говорят! Ты, говорят, просто не понимаешь как мы нужны! Плати давай нам бабло!
дело не в том, что говрят они. Делов в том, что есть разрабы, работавшие с клевыми тестерами, аналитиками, и , не побоюсь этого слова — менеджерами.
И по опыту этих людей такие роли на проекте были полезны.
Что, конечно, не отменяет вашего опыта работы с бестолковыми аналитиками. Но бестолковые спецы есть в любой области, в разработке их не меньше, а вреда от них — больше

SK>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически.
Это как, юнит тестами? Это необходимо, но не достаточно.
Если же вы пишете автоматизированные тесты, если проводите нагрузочное тестирование и т.д. — то значит, вы выполняете работу тестеров вместо них

SK>Теперь аналитики. Тут я совсем теряюсь. Они типа должны говорить с бизнесом узнавать, что же они хотят, потом это аккуратно записывать и передавать дальше. Ессесно это порождает кучу процесса, вопросов и документации, что в итоге все замедляет и искажает изначальные требования. Еще это поощряет тупых разработчиков с подходом типа "А че, я накодил как написано было!".
Это, как было сказано выше, потому что неправильные аналитики вам попадались. Аналитик должен не быть передастом, переклаывая кучку говнотребований из однго места в другое. А Должен выдавать полные и непротиворечивые требования, понятные разработчику, технически реализуемые. Должен быть спецом предметной области заказчика. Должен структурировать поток бреда, генерируемый заказчиком. Согласовывать бред нескольких представителей заказчика друг с другом.

У меня был опыт, когда этим всем занимались разрабы, а потом появились аналитики. Сразу такой груз снялся с плеч! И, главное, было сохранены нервы разрабов и освободилось время что-то реально разрабатывать, а не совещания совещать

SK>Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу.
Если разработчик начитает формировать требования в процессе общения с бизнесом — он сам становится аналитиком

Здравствуйте, Gradiens, Вы писали:

G>Что, конечно, не отменяет вашего опыта работы с бестолковыми аналитиками. Но бестолковые спецы есть в любой области, в разработке их не меньше, а вреда от них — больше

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

SK>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически.
G>Это как, юнит тестами? Это необходимо, но не достаточно.
G>Если же вы пишете автоматизированные тесты, если проводите нагрузочное тестирование и т.д. — то значит, вы выполняете работу тестеров вместо них

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

SK>>Теперь аналитики. Тут я совсем теряюсь. Они типа должны говорить с бизнесом узнавать, что же они хотят, потом это аккуратно записывать и передавать дальше. Ессесно это порождает кучу процесса, вопросов и документации, что в итоге все замедляет и искажает изначальные требования. Еще это поощряет тупых разработчиков с подходом типа "А че, я накодил как написано было!".
G>Это, как было сказано выше, потому что неправильные аналитики вам попадались. Аналитик должен не быть передастом, переклаывая кучку говнотребований из однго места в другое. А Должен выдавать полные и непротиворечивые требования, понятные разработчику, технически реализуемые. Должен быть спецом предметной области заказчика. Должен структурировать поток бреда, генерируемый заказчиком. Согласовывать бред нескольких представителей заказчика друг с другом.
Как так он не "передаст", если он "должен выдавать полные и непротиворечивые требования, понятные разработчику" из требований бизнеса? Еще какой "передаст", только этим и занимается. Если заказчик бредовый, то да, надо как-то решать проблему, но это тогда специально человек "для общения со сложным заказчиком" и он не нанимается просто по умолчанию.

G>У меня был опыт, когда этим всем занимались разрабы, а потом появились аналитики. Сразу такой груз снялся с плеч! И, главное, было сохранены нервы разрабов и освободилось время что-то реально разрабатывать, а не совещания совещать
А нефиг было совещания совещать. Не, серьезно. Если процесс поставлен так, что совещая надо совещать, то да, тут без совещателей не обойтись.

SK>>Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу.
G>Если разработчик начитает формировать требования в процессе общения с бизнесом — он сам становится аналитиком

Да, становится. И бизнес знает и сам влияет на продукт.

А я как тестировщик согласен что мы нафиг не нужны для части проектов)

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

Тогда ответсвенность повысится и продукт будет лучше. Пусть и чуть меньшей моментальной скорости разработки. Как мне видится просто нужно больше чего-то типа ТДД (БДД) и парного программирования (и других практик). И даже может в цене разработка не вырастет, а оплата может подняться серьезно.

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

Здравствуйте, cocacola, Вы писали:

C>Привет! Раньше в it конторах хоть как то в респектах были разработчики.
C>Счас какая-то хрень, набрали на одного разраба по 2 qa и по 2 мэнэджера, они сидят в носу ковыряют, важные такие, один
C>есть у нас Lead QA, жирный такой, ленивый, важный. А сам тупой, как валенок. Даже авто тесты не может написать. Вот накуя они нужны? ведь разрабы без них обойдуться, а они без них нет.
C>Только бюджет компании проедают. Что за тенденция? И лезут же, лезут, знаний нет, а пирог IT вкусный, за счет наглости кусочек урвать то хотят. С одного митинга на другой ходят. Создают видимость работы. ДА нахрен ваши митинги, продукты пишут разрабы, а вы там хоть обмитингуйтесь, ни хрена само не напишеться.

Мэнэджер должен руководить процессом разработки.
Lead QA должен руководить процессом тестирования.
И в том и том случае полно организационной работы которую девелоперу не понять если нет такого опыта.
Думать что "разрабы без них обойдуться" несколько наивно, как в прочем и судить о их тупизне и бесполезности митингов.
Если в процессе участвует только "разраб" то это называется наколеночное производство CMM уровень 1 (при 5 возможных).
Как исключение "разраб" может делать все (не факт что качественно). Но в таком случае он будет физически не успевать.
Если так думать то можно исключить всех кто не производит основной продукт, например бухгалтерию.
Единственно что верно в сообшении что на одного "разрабы" по 2 qa и по 2 мэнэджера быть не должно.

без QA и PM ты в офисе загнешься очень быстро

Здравствуйте, Gradiens, Вы писали:

G>Если разработчик начитает формировать требования в процессе общения с бизнесом — он сам становится аналитиком

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

Здравствуйте, StanislavK, Вы писали:

SK>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически.
Далеко не всё так можно протестировать.

SK>Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо.
То, что ты не сталкивался с такими задачами говорит лишь о том, где построена твоя колокольня.

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

SK>Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу.
1. Человек не может находиться в двух местах одновременно.
2. В сутках 24 часа.
3. Человек устаёт и ему надо отдохнуть.
4. После кучи говорильни с заказчиком на собственно работу времени не остаётся.

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

Я когда то давно тоже так думал, пока проекты были крошечные.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Здравствуйте, Gattaka, Вы писали:

G>В итоге происходит рассинхрон между реализацией и тем что нужно.
Это задача менеджмента — отслеживать что надо и что сделано.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Здравствуйте, cocacola, Вы писали:

C>Только бюджет компании проедают. Что за тенденция? И лезут же, лезут, знаний нет, а пирог IT вкусный, за счет наглости кусочек урвать то хотят. С одного митинга на другой ходят. Создают видимость работы. ДА нахрен ваши митинги, продукты пишут разрабы, а вы там хоть обмитингуйтесь, ни хрена само не напишеться.
Чувак, ты только что открыл, как разрабатывать продукта в два раза дешевле, чем это делают другие конторы.
Срочно открывай свой бизнес и реализуй это конкурентное преимущество — озолотишься!

Здравствуйте, StanislavK, Вы писали:

SK>Теперь аналитики. Тут я совсем теряюсь. Они типа должны говорить с бизнесом узнавать, что же они хотят, потом это аккуратно записывать и передавать дальше. Ессесно это порождает кучу процесса, вопросов и документации, что в итоге все замедляет и искажает изначальные требования. Еще это поощряет тупых разработчиков с подходом типа "А че, я накодил как написано было!".
SK>Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу.

People skills же ж

https://www.youtube.com/watch?v=hNuu9CpdjIo

Здравствуйте, cocacola, Вы писали:

C>Привет! Раньше в it конторах хоть как то в респектах были разработчики.

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

Здравствуйте, playnext, Вы писали:

P>Мэнэджер должен руководить процессом разработки.

Не руководить, а организовывать. Это не совсем одно и тоже. Но да, в некоторых конторах, особенно бСССР, PM это другое название для начальника отдела. При таком построении есть суровый риск, что человек в части принимаемых им решений будет некомпетентен.

Здравствуйте, StanislavK, Вы писали:

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

А если наоборот? Я вот вижу какой объем работы делают мои PM и Product Owner. И я прекрасно понимаю, что без них все это свалитлось бы мне на голову и я бы утонул во всей этой фигне с головой. Но если заказчик один или продукт вообще коробочный, да работают над проектом полтора разработчика, то да, тут можно и без этих людей.

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Gradiens, Вы писали:

G>>Если разработчик начитает формировать требования в процессе общения с бизнесом — он сам становится аналитиком

K>И это очень круто и очень сильно ценится. Такие обычно работают контракторами/консультантами за очень серьёзные бабки, которые обычным кодерам не платят, т.к. такой человек-оркестр позволяет убрать отдельного аналитика и съэкономить бабки даже несмотря на то, что платить ему приходится существенно выше обычного.

Да, это круто и ценится, но проблема усидеть на двух стульях.
Или обнаруживается, что он оба дела (разработка и аналитика) делается со скоростью 1/2, а бизнесу надо быстрее, ему дают подчиненных. И вроде все круто, он — тимлид. Но из-за того, что бизнес-анализ жрет много времени, чувак отходит от разработки в торону менеджмента и аналитики.

Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, Gradiens, Вы писали:

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

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

Здравствуйте, Gradiens, Вы писали:

G>Другое дело, что тут происходит подмена понятий. От того, что некоторый конкретные тестеры и аналитики в конкретной компании с непрозрачными процессами напрасно кушали, вовсе не следует что тестеры и аналитики как роли на проекте не нужны.

Мы же не про роли, а про конкретные штатные единицы, которые получают ЗП. Если можно построить процессы так, что без тестеров и аналитиков можно обойтись, то тестеры и аналитики не нужны по-умолчанию и обратное надо доказывать. Желательно в цифрах.

Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, cocacola, Вы писали:

C>>Только бюджет компании проедают. Что за тенденция? И лезут же, лезут, знаний нет, а пирог IT вкусный, за счет наглости кусочек урвать то хотят. С одного митинга на другой ходят. Создают видимость работы. ДА нахрен ваши митинги, продукты пишут разрабы, а вы там хоть обмитингуйтесь, ни хрена само не напишеться.
0>Чувак, ты только что открыл, как разрабатывать продукта в два раза дешевле, чем это делают другие конторы.
0>Срочно открывай свой бизнес и реализуй это конкурентное преимущество — озолотишься!

Собственно так сделал в свое время. Работал в интеграторе, понял что можно делать такие же проекты, но с затратами в 2-3 меньше и большей прибылью. Не то чтобы озолотился, но зарабатываю прилично.

P>Единственно что верно в сообшении что на одного "разрабы" по 2 qa и по 2 мэнэджера быть не должно.
Да такого и нет. Это преувеличение для нагнетания.

Здравствуйте, Muxa, Вы писали:

M>Да такого и нет. Это преувеличение для нагнетания.

Если матричная структура, то и не такое бывает. Слышал истории про то как на трех разработчиков было 7 менеджеров.

Здравствуйте, gandjustas, Вы писали:

G>Собственно так сделал в свое время. Работал в интеграторе, понял что можно делать такие же проекты, но с затратами в 2-3 меньше и большей прибылью. Не то чтобы озолотился, но зарабатываю прилично.
Это круто, уважаю.

Здравствуйте, Gradiens, Вы писали:

G>Да, это круто и ценится, но проблема усидеть на двух стульях.
G>Или обнаруживается, что он оба дела (разработка и аналитика) делается со скоростью 1/2, а бизнесу надо быстрее, ему дают подчиненных. И вроде все круто, он — тимлид. Но из-за того, что бизнес-анализ жрет много времени, чувак отходит от разработки в торону менеджмента и аналитики.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, StanislavK, Вы писали:

SK>>А кто сказал, что они были бестолковые? Все умнейшие люди и знают свое дело. Но дело не в этом. И с хорошими аналитиками да, не хуже, в большистве случаев. Глобальная проблема в том, что очень сложно контролировать то, что как-бы работает — аналитики анализируют, тестеры тестируют, программисты программируют, все вроде заняты.
НС>А если наоборот? Я вот вижу какой объем работы делают мои PM и Product Owner. И я прекрасно понимаю, что без них все это свалитлось бы мне на голову и я бы утонул во всей этой фигне с головой. Но если заказчик один или продукт вообще коробочный, да работают над проектом полтора разработчика, то да, тут можно и без этих людей.
Эту дискуссию давайте начнем и закончим тем, что дискуссия была про аналитиков и тестеров. Где вы там PM и Product Owner разглядели? Вот свой топик про них начинайте

Про полтора человека разговора тоже не было.

Бедный ТС, которому никогда не приходилось работать с хорошим менеджером.

Про КУА вообще молчу.

Здравствуйте, Gradiens, Вы писали:

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

G>Нужны, еще как, и твои же слова это подтверждают.
G>Разрабам приходится больше тестировать, и приходится общатся с заказчиком. Т.е. выгнав тестеров и аналитиков приходим к тому, что разрабы становятся частично тестерами и частично аналитиками.
Точно так и есть! Только при это есть интересная штука — когда в проекте такой подход, то все тестирование и "аналитика" становится жутко эффективным процессом, так как разработчикам это все жуть как не интересно и он стараются делать так, чтобы этого всего было как можно меньше. Кстати, совсем забыл, что 2-3 line саппорт тоже надо на разработчиков кидать. Получается порочный круг — нагадишь с качеством — будешь радоваться саппорту.

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

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, StanislavK, Вы писали:

SK>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически.
CC>Далеко не всё так можно протестировать.
Не все, конечно, но очень много, что нельзя, то можно "практически" автоматизировать. Очень редко когда совсем нельзя.

SK>>Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо.
CC>То, что ты не сталкивался с такими задачами говорит лишь о том, где построена твоя колокольня.
Где же это она построена?

SK>>Когда же встает задача тестирования работы приложения при реальной коммуникации с другими системами, то там тоже нефиг тестеров брать — разрабы быстро выбешиваются от этого и пилят всякие приблуды, чтобы этого руками не делать.
CC>А руками нормальные тестеры и не делают, они автоматизацию пишут, сами.
Зачем? Разработчики же лучше пишут!

SK>>Что же мешает разработчику самому поговорить с бизнесом и все закодить я понять не могу.
CC>1. Человек не может находиться в двух местах одновременно.
CC>2. В сутках 24 часа.
CC>3. Человек устаёт и ему надо отдохнуть.
CC>4. После кучи говорильни с заказчиком на собственно работу времени не остаётся.
Суть не в том, чтобы перерабатывать, а в том, чтобы делать ту же работу, но с меньшим кол-вом людей. Разработчикам не хочется заниматься тестированием, поэтому они это делают так, чтобы делать этого как можно меньше. Тоже же самое с бизнес-требованиями, мало того, что они гораздо лучше чем любой аналитик понимают, что можно реализовать и как, но они еще стараются сократить ненужные обсуждения, так как это отнимает время разработки.

CC>

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

Здравствуйте, StanislavK, Вы писали:

SK>Эту дискуссию давайте начнем и закончим тем, что дискуссия была про аналитиков и тестеров.

Не аналитиков, а менеджеров. РМ это самый менеджерский менеджер в разработке, а owner это самое близкое к аналитику в скрамоподобной модели разработки.

Здравствуйте, StanislavK, Вы писали:

CC>>А руками нормальные тестеры и не делают, они автоматизацию пишут, сами.
SK>Зачем? Разработчики же лучше пишут!
А у разработчиков ну вот вообще больше никаких задач сделать не осталось?

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

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

SK>Вы не знаете, что у меня за проект и если мы тут начнем пиписьками мериться, то будем просто... пиписьками мериться.
SK>Проекты совсем не крошечные.
Ну раз ты решил поднять вопрос писькомеряния. Сколько миллионов человек пользуются твоим проектом?

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, StanislavK, Вы писали:

CC>>>А руками нормальные тестеры и не делают, они автоматизацию пишут, сами.
SK>>Зачем? Разработчики же лучше пишут!
CC>А у разработчиков ну вот вообще больше никаких задач сделать не осталось?
Осталось, конечно. Почему нет?

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

SK>>мало того, что они гораздо лучше чем любой аналитик понимают, что можно реализовать и как
CC>Вот только осталось понять, что заказчик таки от них хочет. Плюс свести это всё к тому, чтобы заказчик таки получил то, что ему нужно а не "а, ну это делать геморно, чот как то влом, мы не будем".
И это тоже правильно, так как некоторые вещи делать настолько геморно, что даже и не стоит. А некоторые можно буквально чуть по-другому и получится намного дешевле и разработчик это лучше всех знает. Конечно, если утрировать и разработчик идиот, то да, клиент останется не доволен. Но от идиотов надо избавляться.

SK>>Вы не знаете, что у меня за проект и если мы тут начнем пиписьками мериться, то будем просто... пиписьками мериться.
SK>>Проекты совсем не крошечные.
CC>Ну раз ты решил поднять вопрос писькомеряния. Сколько миллионов человек пользуются твоим проектом?
Текущим — немного, там фишка не в этом. До этого были вебовские проекты, где-то миллион посещений в день, где-то 50 миллионов зарегистрированных пользователей.
Но вы меня не поняли. Я о том, что это как раз не сильно принципиально в для этой дискуссии. Вебовский проект с миллионами пользователей может быть на порядок проще специализированной софтины для 20 человек. К слову и размер проекта не сильно коррелирует с тем сколько народу им пользуется. Хотя... если нанять достаточно аналитиков...

Здравствуйте, StanislavK, Вы писали:

SK>>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически.

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

Спасибо.

Не надо быть семи пядей во лбу, дабы понять, что ТС работает в конторе рога и копыта, в которой всего 5 человек штата и финансовой ответственности 0.0. Посмотрел бы я как он запускал свой код в продакшн без тестирования и менеджеров в моей конторе на проекте стоимостью пару десятков миллионов. Мне кажется клиент даже контракт с нами отказался подписывать, если бы узнал, что у нас ни тестировщиков, ни менеджеров в штате нету.

Здравствуйте, StanislavK, Вы писали:

SK>Точно так и есть! Только при это есть интересная штука — когда в проекте такой подход, то все тестирование и "аналитика" становится жутко эффективным процессом, так как разработчикам это все жуть как не интересно и он стараются делать так, чтобы этого всего было как можно меньше. Кстати, совсем забыл, что 2-3 line саппорт тоже надо на разработчиков кидать. Получается порочный круг — нагадишь с качеством — будешь радоваться саппорту.

Это тонкая шутка? Или я чего-то не понимаю.
Потому что когда людям хочется что-то не делать, они просто берут, и _не_ делают это что-то. Если аналитика может быть интересна разрабам (в плане погружения в предметную область, а не в плане написания спек), то тестирование и саппорт разрабам не интересны. Они будут отлынивать, терять мотивацию. Как результат, скорость разработки значительно упадет, а текучка кадров — возрастет.

Порочный круг — нагадишь с качеством, а радоваться саппорту будет следующий неудачник, который придет на твое место. После того, как он поймет, где оказался — придет череда следующего. Вам доводилось видеть проекты без требований, без тестирования, которые писало пять поколений разрабов? Душераздирающее зрелище (С)

SK>Единственный тонкий момент, что разработчик должен чувствовать личную ответственность за продукт.
Личная ответственность легко похерится необходимостью разруливать противоречивые хочучки заказчика про семь перпендикулярных красных линий, а потом еще необходимостью тестировать и поддерживать. Особенно в том нередком случае, когда проект уже не девочка, и первым у проекта был не ты.

Здравствуйте, cocacola, Вы писали:

C>Привет! Раньше в it конторах хоть как то в респектах были разработчики.
так и сейчас в респектах.
C>Счас какая-то хрень, набрали на одного разраба по 2 qa и по 2 мэнэджера, они сидят в носу ковыряют, важные такие,
Так если в пирог добавить стакан соли вместо ложки — тоже хрень получится.
По моему опыту в 90% случаев на одного разраба должно быть 0.3-0.5 qa, 0.2-0.4 аналитика и 0.1-0.2 менеджера. Тогда взлетит.

Здравствуйте, StanislavK, Вы писали:

SK>>>Зачем? Разработчики же лучше пишут!
CC>>А у разработчиков ну вот вообще больше никаких задач сделать не осталось?
SK>Осталось, конечно. Почему нет?
Значит у разработчиков на написание тестов времени нет, пока есть более приоритетные задачи.

SK>И это тоже правильно, так как некоторые вещи делать настолько геморно, что даже и не стоит.
Заказчик готов за этот гемор платить деньги.
Да и вообще всегда все готовы платить деньги именно за решение гемора.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Здравствуйте, Gradiens, Вы писали:

G>Потому что когда людям хочется что-то не делать, они просто берут, и _не_ делают это что-то. Если аналитика может быть интересна разрабам (в плане погружения в предметную область, а не в плане написания спек), то тестирование и саппорт разрабам не интересны. Они будут отлынивать, терять мотивацию. Как результат, скорость разработки значительно упадет, а текучка кадров — возрастет.
Если людям интересен продукт, область и они чувствуют за него ответственность, то все нормально. Разумный человек понимает, что надо и саночки катать. Если же посрать, то ничего не поможет.

G>Порочный круг — нагадишь с качеством, а радоваться саппорту будет следующий неудачник, который придет на твое место. После того, как он поймет, где оказался — придет череда следующего. Вам доводилось видеть проекты без требований, без тестирования, которые писало пять поколений разрабов? Душераздирающее зрелище (С)
Не надо только придумавать проблемы и последствия. Кто сказал, что при таком подходе ничего не документируется? Где сказано, что разрабочик сразу уходит как только нагадит?

SK>>Единственный тонкий момент, что разработчик должен чувствовать личную ответственность за продукт.
G>Личная ответственность легко похерится необходимостью разруливать противоречивые хочучки заказчика про семь перпендикулярных красных линий, а потом еще необходимостью тестировать и поддерживать. Особенно в том нередком случае, когда проект уже не девочка, и первым у проекта был не ты.
Все правда. Единственный момент, что "ответственность легко похерится необходимостью разруливать противоречивые хочучки заказчика" не только у разработчика, а у кого угодно — тестера, аналитика, да у кого угодно.

Здравствуйте, StanislavK, Вы писали:

SK>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо.

Браво — исполнители сами контролируют качество. То есть, исполнитель всегда прав. Гы-гы.
В этой схеме нет и не может быть гарантий качества.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, StanislavK, Вы писали:

SK>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо.
I>Браво — исполнители сами контролируют качество. То есть, исполнитель всегда прав. Гы-гы.
Почему это проблема? Если продукт не качественный в техническом плане, то девелоперу это не выгодно, так как саппорта становится много. Если он не качаственный с бизнес точки зрения, то спрос опять с разработчика — претензии бизнеса будут именно к нему.

I>В этой схеме нет и не может быть гарантий качества.
Я как раз в схеме с тестерами и аналитикам не вижу гарантий качества. Аналитикам выгодно переусложнять требования и утяжелять процесс, так как это делает их все более значимыми и нужными. Тестерам же выгодно чтобы багов было больше и было бы меньше автоматизации, так как тогда без них просто никуда. А самое обидное, что в итоге проблемы продукта становятся "коллективной ответственностью" и все начинают разводить руками и косится на других, типа недотестили/неправильно записали/криво закодили (подчеренуть нужное).

Здравствуйте, opt1k, Вы писали:

O>Не надо быть семи пядей во лбу, дабы понять, что ТС работает в конторе рога и копыта, в которой всего 5 человек штата и финансовой ответственности 0.0. Посмотрел бы я как он запускал свой код в продакшн без тестирования и менеджеров в моей конторе на проекте стоимостью пару десятков миллионов. Мне кажется клиент даже контракт с нами отказался подписывать, если бы узнал, что у нас ни тестировщиков, ни менеджеров в штате нету.

не надо, у нас 100 чел штата.
Просто в отделе 2 разраба, 4 ПМ, и 3 тестера. Такое вот соотношение

Так что вас конкретно напрягает? Что для того чтоб вы работали нормально вам надо 4 ПМа? Или то что ваш код три тестера тестят, а иначе продуктив падает?

Здравствуйте, StanislavK, Вы писали:

SK>>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо.
I>>Браво — исполнители сами контролируют качество. То есть, исполнитель всегда прав. Гы-гы.
SK>Почему это проблема? Если продукт не качественный в техническом плане, то девелоперу это не выгодно, так как саппорта становится много. Если он не качаственный с бизнес точки зрения, то спрос опять с разработчика — претензии бизнеса будут именно к нему.

Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ?
И каким это образом бизнес без тестеров скажет, что продукт некачественный?

I>>В этой схеме нет и не может быть гарантий качества.
SK>Я как раз в схеме с тестерами и аналитикам не вижу гарантий качества. Аналитикам выгодно переусложнять требования и утяжелять процесс, так как это делает их все более значимыми и нужными. Тестерам же выгодно чтобы багов было больше и было бы меньше автоматизации, так как тогда без них просто никуда. А самое обидное, что в итоге проблемы продукта становятся "коллективной ответственностью" и все начинают разводить руками и косится на других, типа недотестили/неправильно записали/криво закодили (подчеренуть нужное).

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

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

Здравствуйте, cocacola, Вы писали:

O>>Не надо быть семи пядей во лбу, дабы понять, что ТС работает в конторе рога и копыта, в которой всего 5 человек штата и финансовой ответственности 0.0. Посмотрел бы я как он запускал свой код в продакшн без тестирования и менеджеров в моей конторе на проекте стоимостью пару десятков миллионов. Мне кажется клиент даже контракт с нами отказался подписывать, если бы узнал, что у нас ни тестировщиков, ни менеджеров в штате нету.

C>не надо, у нас 100 чел штата.
C>Просто в отделе 2 разраба, 4 ПМ, и 3 тестера. Такое вот соотношение

Так у вас похоже нету внятного проектного управления, раз в отделе ажно 4 пм на двух разрабов и трех тестеров. Наверняка один пм занят девелоперами, другой тестерами, третий координацией, а четверный всем проектом занимается

В целом понятно, почему у тебя тестеры "лишние" — плохой руководитель обычно сталкивает тестеров и девелоперов лбами. Т.е. ты говоришь про свои страхи и боль.

Здравствуйте, StanislavK, Вы писали:

CC>>4. После кучи говорильни с заказчиком на собственно работу времени не остаётся.
SK>Суть не в том, чтобы перерабатывать, а в том, чтобы делать ту же работу, но с меньшим кол-вом людей. Разработчикам не хочется заниматься тестированием, поэтому они это делают так, чтобы делать этого как можно меньше. Тоже же самое с бизнес-требованиями, мало того, что они гораздо лучше чем любой аналитик понимают, что можно реализовать и как, но они еще стараются сократить ненужные обсуждения, так как это отнимает время разработки.

Именно — разработчикам не хочется заниматься тестированием. Потому они его избегают, ты сам же про это и говоришь(делать этого как можно меньше). Девелоперы до кучи как раз плохо понимают бизнес-требования. Они хорошо понимают технические возможности. Бизнес-аналитик — бизнес требования. Обсуждения нужны для того, что бы сократить разработку, что бы обе стороны лучше понимали, что хотят другие.
Странно, если было бы иначе. Бизнес-аналитик — специалист по домену, например по страхованию, и он обычно собаку в этом съел. Разработчик в страховании том же может весьма слабо разбираться.
Технические проблемы это не повод менять бизнес-требования. А то похоже у тебя такой кейс — девелоперам трудно, вот они и меняют требования под себя.

Здравствуйте, StanislavK, Вы писали:

G>>Если же вы пишете автоматизированные тесты, если проводите нагрузочное тестирование и т.д. — то значит, вы выполняете работу тестеров вместо них

SK>Да, именно так и значит. И очень стараемся сделать так, чтобы ее было меньше и больне никогда к ней не возвращаться. Признаться, я не вижу разницы в написании одного типа кода или другого, зачем для этого разные люди?

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

В тестировании самое важно не код, а тест-кейсы, сценарии, планы и тд. И вот здесь выясняется, что скилы нужны принципиально иные. Девелоперу надо думать о проектировании продукта, а тестеру думать о выявлении проблем и проверке соответствия требованиям. У девелопера огромная часть работы напрямую на требования не мапится. У тестера ровно наоборот — вся работа целиком с требованиями.
Формально обе группы могут быть программистами. Только методы решения проблем у них разные. Программист еще не значит девелопер. Программисты нынче и админы, и девопсы, и безопасники и вообще кто угодно. Это не повод всю работу давать девелоперам.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, StanislavK, Вы писали:

SK>>Почему это проблема? Если продукт не качественный в техническом плане, то девелоперу это не выгодно, так как саппорта становится много. Если он не качаственный с бизнес точки зрения, то спрос опять с разработчика — претензии бизнеса будут именно к нему.
I>Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ?
Извиняюсь, но ничего не понял. То тестеры, то саппорт.

I>И каким это образом бизнес без тестеров скажет, что продукт некачественный?
У бизнеса только один способ сказать что продукт качественный или не качественный — пользоваться им, если бизнес им пользуется. Если пользуется не непосредственно бизнес, а клиенты, то дать клиентам. Тогда все узнают насколько он качественный. До этого момента можно только предполагать основываясь на чем-то мнении.
Вы не забывайте, что я не предлагаю отказаться от тестирования, я предлагаю отказаться от тестеров — за качество при этом на 100% отвечает разработчик.

SK>>Я как раз в схеме с тестерами и аналитикам не вижу гарантий качества. Аналитикам выгодно переусложнять требования и утяжелять процесс, так как это делает их все более значимыми и нужными. Тестерам же выгодно чтобы багов было больше и было бы меньше автоматизации, так как тогда без них просто никуда. А самое обидное, что в итоге проблемы продукта становятся "коллективной ответственностью" и все начинают разводить руками и косится на других, типа недотестили/неправильно записали/криво закодили (подчеренуть нужное).
I>Тестировщики как раз заинтересованы в автоматизации — никому не нравится вручную кликать одно и то же.
Как не нравится? за это же деньги платят!

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

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

Здравствуйте, StanislavK, Вы писали:

SK>Вы не забывайте, что я не предлагаю отказаться от тестирования, я предлагаю отказаться от тестеров — за качество при этом на 100% отвечает разработчик.

Давайте уже от разработчиков отказываться, чо, пусть клиент за качество сам отвечает.

Вы вообще представляете себе объём тестирования корпоративного мастодонта в котором 500 отделений и каждое работает на одной и той же системе, только с разными процессами? Ваше предложение имеет смысл только в случае маленькой конторы, где разработчик 15 минут пишет код и 45 минут тестирует, а потом идёт пить чай.

Здравствуйте, opt1k, Вы писали:

O>Давайте уже от разработчиков отказываться, чо, пусть клиент за качество сам отвечает.

Да хорошо бы, но все же кто-то должен делать продукт.

O>Вы вообще представляете себе объём тестирования корпоративного мастодонта в котором 500 отделений и каждое работает на одной и той же системе, только с разными процессами? Ваше предложение имеет смысл только в случае маленькой конторы, где разработчик 15 минут пишет код и 45 минут тестирует, а потом идёт пить чай.
Я конечно извиняюсь, но строить аргумент только на том, что вам кажется, что кто-то что-то видел или не видел имеет крайне малое отношение к логике. А вы не предполагали, что возможно все дело в том я как раз видел такие компании и знаю как они работают, а возможно даже работаю в такой, и поэтому знаю, что будет если сделать не так как делают все?

Здравствуйте, StanislavK, Вы писали:

SK>>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически.
G>>Если же вы пишете автоматизированные тесты, если проводите нагрузочное тестирование и т.д. — то значит, вы выполняете работу тестеров вместо них

SK>Да, именно так и значит.

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

Но сам я хороших тестеров пока ещё не встречал.

Здравствуйте, StanislavK, Вы писали:

I>>Здравствуйте, StanislavK, Вы писали:

SK>>>Почему это проблема? Если продукт не качественный в техническом плане, то девелоперу это не выгодно, так как саппорта становится много. Если он не качаственный с бизнес точки зрения, то спрос опять с разработчика — претензии бизнеса будут именно к нему.
I>>Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ?
SK>Извиняюсь, но ничего не понял. То тестеры, то саппорт.

Это и неудивительно — ты такими вопросами никогда не задавался. Кто контролирует девелоперов ? Из опыта других индустрий оказывается, что исполнитель всегда плохой контролёр.

I>>И каким это образом бизнес без тестеров скажет, что продукт некачественный?
SK>У бизнеса только один способ сказать что продукт качественный или не качественный — пользоваться им, если бизнес им пользуется. Если пользуется не непосредственно бизнес, а клиенты, то дать клиентам. Тогда все узнают насколько он качественный. До этого момента можно только предполагать основываясь на чем-то мнении.
SK>Вы не забывайте, что я не предлагаю отказаться от тестирования, я предлагаю отказаться от тестеров — за качество при этом на 100% отвечает разработчик.

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

SK>>>Я как раз в схеме с тестерами и аналитикам не вижу гарантий качества. Аналитикам выгодно переусложнять требования и утяжелять процесс, так как это делает их все более значимыми и нужными. Тестерам же выгодно чтобы багов было больше и было бы меньше автоматизации, так как тогда без них просто никуда. А самое обидное, что в итоге проблемы продукта становятся "коллективной ответственностью" и все начинают разводить руками и косится на других, типа недотестили/неправильно записали/криво закодили (подчеренуть нужное).
I>>Тестировщики как раз заинтересованы в автоматизации — никому не нравится вручную кликать одно и то же.
SK>Как не нравится? за это же деньги платят!

А вот так — не нравится. Однообразный механический труд никому не нравится. И тестировщики стремятся автоматизировать поиск регрессии. Руками надо только эксплорейтори выполнять.
Что характерно, девелоперы кое как справляются с автоматизацией, но у них весьма хилые тест-кейсы и тест-планы. А вот эксплорейтори у девелоперов отсутствует как класс.

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

Нет конфликта интересов, если только начальство не сталкивает лбами и тех и других. И девелоперы, и тестеры заинтересованы в качестве продукта. Высокое качество — и те и другие занимаются новой работой. Низкое — и те и другие мусолят одно и то же по сотне раз.

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

Прочел внимательно твои сообщения.

Здравствуйте, StanislavK, Вы писали:

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

Согласен.
Но, правды ради, надо оговориться, что фирмы есть разные и продукты у них разные, и задачи тестирования тоже очень разные.
Я напр. работал в фирме (платёжный шлюз), где отдел тестирования занимался в основном подключением клиентов к системе, созданием для них тестового
и рабочего окружения и проверки работы их с системой после этого. Это наверное 60% их работы.
Потому что фирма технологичная, и продукта внешнего почти нет, работа с клиентами только через технологические каналы.
Там их работа не то что незаменима -- она центральная.

Здравствуйте, Ikemefula, Вы писали:

I>>>Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ?
SK>>Извиняюсь, но ничего не понял. То тестеры, то саппорт.
I>Это и неудивительно — ты такими вопросами никогда не задавался.
Ну это грубо.

I>Кто контролирует девелоперов ?
Зарплата, бонусы, гордость за то, что они делают. Все так же как у всех. Тестеров контролирует то же самое.

I>Из опыта других индустрий оказывается, что исполнитель всегда плохой контролёр.
На то они и другие. Многие идустрии напрямую зависят от того, что люди каждый день делают ровно одно и то же, в таком случае индивидуальный вклад минимален. Если у вас есть конктерный сравнимый привмер, то его можно обсудить.

SK>>Вы не забывайте, что я не предлагаю отказаться от тестирования, я предлагаю отказаться от тестеров — за качество при этом на 100% отвечает разработчик.
I>Это и есть проблема. Разработчик заинтересован в том, что бы все зависели от него. И качество будет падать, при чем обнаруживается это далеко не сразу.
Конечно, коненчо. Только это проблемы не только разработчика, это проблема всех кто участвует в процессе — и тестерова и аналитиков. Только когда есть тестеры и аналитики эти проблемы возникает в трех местах, соответственно контролировать их сложнее.

SK>>Как не нравится? за это же деньги платят!

I>А вот так — не нравится. Однообразный механический труд никому не нравится. И тестировщики стремятся автоматизировать поиск регрессии. Руками надо только эксплорейтори выполнять.
I>Что характерно, девелоперы кое как справляются с автоматизацией, но у них весьма хилые тест-кейсы и тест-планы. А вот эксплорейтори у девелоперов отсутствует как класс.
Правду сказать, у нас тут диссонанс. Я верю в разработчиков и вижу примеры, когда они делают все эти вещи хорошо и эффективно. На мой взгляд гораздо более эффективно, чем если бы этим занимались отдельные люди. Причем благодаря тому, что они это делают сами, разработка становится быстрее. Они знают бизнес лучше, лучше понимаю фичи, соответственно далют их быстрее и "правильнее". Приложения становятся более дружелюбные для тестирования, так как разработчик с самого начала знает, что его ему надо будет тестированить. и т.д и т.п.
Вы же (как мне кажется, поправьте если не прав!) уверены, что разрабочик это узокнаправленный человек, конвеерный рабоник. Я ни разу не работал на проекте, где бы это было так.

I>>>Тестерам выгодно создавать не баги, а тест-кейсы и тест-планы. В нормальной организации именно так и делается. Т.е. решение проблем, а не просто количество чего то. Тестеры, они прикинь, тоже решаются решением проблем, а не просто чего то кликают.
SK>>Верю, верю. Но все же конфликт интересов никуда не пропадает — тестерам выгодно чтобы было больше работы. При этом совсем не значит, что они будут ее плохо делать. Делать могут на отлично, но много не нужного.
I>Нет конфликта интересов, если только начальство не сталкивает лбами и тех и других. И девелоперы, и тестеры заинтересованы в качестве продукта. Высокое качество — и те и другие занимаются новой работой. Низкое — и те и другие мусолят одно и то же по сотне раз.
Я же написал, что "При этом совсем не значит, что они будут ее плохо делать". Т.е. я совсем не утверждаю, что от тестеров будет страдать качество. Я говорю, что без них оно не будет хуже, если разработчики достаточно ответственны и понимают, что делают.

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

Здравствуйте, StanislavK, Вы писали:

I>>>>Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ?
SK>>>Извиняюсь, но ничего не понял. То тестеры, то саппорт.
I>>Это и неудивительно — ты такими вопросами никогда не задавался.
SK>Ну это грубо.

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

В разработке тестировщики защищают сторону заказчика или бизнеса, а не исполнителя. Девелоперы — именно сторону исполнителя. Если тестировщиков убрать, то заказчик попадает в зависимость от девелоперов — девелоперы начинают диктовать условия. Бывает так, что девелоперы объясняют заказчику, что де проблемы имеют под собой объективные причины (юзеры не те, компы у юзеров не те, а что вы хотите и тд). Скажем, в энтерпрайзе такое может цвести не то что годами, а десятками лет. Например потому, что основной бизнес не может выбрать себе других исполнителей по ряду внутриполитических причин.

I>>Кто контролирует девелоперов ?
SK>Зарплата, бонусы, гордость за то, что они делают. Все так же как у всех. Тестеров контролирует то же самое.

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

I>>Из опыта других индустрий оказывается, что исполнитель всегда плохой контролёр.
SK>На то они и другие. Многие идустрии напрямую зависят от того, что люди каждый день делают ровно одно и то же, в таком случае индивидуальный вклад минимален. Если у вас есть конктерный сравнимый привмер, то его можно обсудить.

Недавно мы узнали, что под словом контроль ты понимаешь зарплату. Между тем контроль качества во всех индустриях это проверка на соответствие требованиям. Её выполняют люди. Исполнитель всегда и везде заинтересованое лицо, ему выгодно что бы проблемы не были найдены. Потому нужно найти то лицо, которому выгодно выявлять проблемы.
И вот парадокс — разработка и контроль в одном лице совмещаются плохо.

Для того, что бы это понять, нужно перестать называть контроль зарплатой и наоборот.

I>>Это и есть проблема. Разработчик заинтересован в том, что бы все зависели от него. И качество будет падать, при чем обнаруживается это далеко не сразу.
SK>Конечно, коненчо. Только это проблемы не только разработчика, это проблема всех кто участвует в процессе — и тестерова и аналитиков. Только когда есть тестеры и аналитики эти проблемы возникает в трех местах, соответственно контролировать их сложнее.

Разумеется, сложнее. Зато и качество будет классом выше.

I>>Что характерно, девелоперы кое как справляются с автоматизацией, но у них весьма хилые тест-кейсы и тест-планы. А вот эксплорейтори у девелоперов отсутствует как класс.
SK>Правду сказать, у нас тут диссонанс. Я верю в разработчиков и вижу примеры, когда они делают все эти вещи хорошо и эффективно.

А мы не обсуждаем веру. Где гарантия что твоё "эффективно" это то же самое "эффективно" что и у других людей ? Ну вот контроль у тебя есть эквивалент зарплаты. Эффективность ты тоже в своей зарплате меряешь ?

>На мой взгляд гораздо более эффективно, чем если бы этим занимались отдельные люди.

Как ты установил эту закономерность ?

SK>Вы же (как мне кажется, поправьте если не прав!) уверены, что разрабочик это узокнаправленный человек, конвеерный рабоник. Я ни разу не работал на проекте, где бы это было так.

Я даже не знаю, какой смысл ты в это вкладываешь.

SK>Я же написал, что "При этом совсем не значит, что они будут ее плохо делать". Т.е. я совсем не утверждаю, что от тестеров будет страдать качество. Я говорю, что без них оно не будет хуже, если разработчики достаточно ответственны и понимают, что делают.

Как у вас дела с эксплорейшн тестированием ? Кто из девелоперов занимается им неделями и месяцами, то есть, вообще все время ?

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

Цитирую некоего StanislavK, http://rsdn.org/forum/job/6789260.1

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

Итак — ты уже начал отказываться от своих слов. Это говорит о том, что твоим словам цена около нуля и ты сам с этим согласен

Здравствуйте, Ikemefula, Вы писали:

I>>>Кто контролирует девелоперов ?
SK>>Зарплата, бонусы, гордость за то, что они делают. Все так же как у всех. Тестеров контролирует то же самое.
I>Интересно, как зарплата может проверить продукт на соответсвие требованиям ? Или Зарплата это имя индуса который вручную кликает ?
I>Пожалуйста, подробнее, а то я вижу, что ты говоришь про бонусы и стимулы, а не про контроль.
Контроль? Тесты, многие тысячи тестов — покрыто все.

Здравствуйте, StanislavK, Вы писали:

SK>>>Зарплата, бонусы, гордость за то, что они делают. Все так же как у всех. Тестеров контролирует то же самое.
I>>Интересно, как зарплата может проверить продукт на соответсвие требованиям ? Или Зарплата это имя индуса который вручную кликает ?
I>>Пожалуйста, подробнее, а то я вижу, что ты говоришь про бонусы и стимулы, а не про контроль.
SK>Контроль? Тесты, многие тысячи тестов — покрыто все.

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

Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях. Т.е. 'внезапность' и 'неопределенность'. Этот класс проблем покрывается эксплорейшн тестами. У них такая особенность, они абсолютно не автоматизируются. Это понятно, или надо объяснять ? Часто это тест в стиле 'кликать как юзер' со всеми вытекающими проблемами.

И возвращаемся к старому вопросу — кто у вас делает эксплорейшн тестирование ?

Здравствуйте, Ikemefula, Вы писали:

SK>>Контроль? Тесты, многие тысячи тестов — покрыто все.
I>Отлично, уже лучше. Но это автоматические тесты, они не выявляют новых видов багов. Т.е. если у тебя один тест на длину строки, то он найдет только баги с длиной строки и не сможет ничего сделать, если в строке символы не те. Далее, если ты допишешь тест на символы, то оба твоих теста будут делать одно и тоже годами — длину строки и символы.
Если не полный дебил пишет, то будет приличный тест. В принципе ничего не выявляет новые баги пока это кто-то не протестирует и не обнаружит баг.

I>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях. Т.е. 'внезапность' и 'неопределенность'. Этот класс проблем покрывается эксплорейшн тестами. У них такая особенность, они абсолютно не автоматизируются. Это понятно, или надо объяснять ? Часто это тест в стиле 'кликать как юзер' со всеми вытекающими проблемами.
Не, объясни. Что именно не автоматизируется? Постановка рандомных параметров в сервис? Или какие-то экстреммальные знаечения не кодятся? Или ты намекаешь, что никто не заменит обезъяну рандомно стучащую по клавишам?

I>И возвращаемся к старому вопросу — кто у вас делает эксплорейшн тестирование?
Разработчики делают тестирование. Надо гонять свой код так, чтобы шанс ошибки был минимален. Называть это "эксплорейшн тестирование" или нет, я не скажу. В нашей области ошибка легко может стоить несколько десятков миллионов, так что к этому серьезно относятся.

Здравствуйте, StanislavK, Вы писали:

K>>>Контроль? Тесты, многие тысячи тестов — покрыто все.
I>>Отлично, уже лучше. Но это автоматические тесты, они не выявляют новых видов багов. Т.е. если у тебя один тест на длину строки, то он найдет только баги с длиной строки и не сможет ничего сделать, если в строке символы не те. Далее, если ты допишешь тест на символы, то оба твоих теста будут делать одно и тоже годами — длину строки и символы.
SK>Если не полный дебил пишет, то будет приличный тест. В принципе ничего не выявляет новые баги пока это кто-то не протестирует и не обнаружит баг.

Браво! И кто же у вас решает эту проблему "ничего не выявляет новые баги пока это кто-то не протестирует и не обнаружит баг" ?
Вот QA именно этим и заняты и это называется эксплорейшн тестирование.

I>>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях. Т.е. 'внезапность' и 'неопределенность'. Этот класс проблем покрывается эксплорейшн тестами. У них такая особенность, они абсолютно не автоматизируются. Это понятно, или надо объяснять ? Часто это тест в стиле 'кликать как юзер' со всеми вытекающими проблемами.
SK>Не, объясни. Что именно не автоматизируется? Постановка рандомных параметров в сервис? Или какие-то экстреммальные знаечения не кодятся? Или ты намекаешь, что никто не заменит обезъяну рандомно стучащую по клавишам?

Придумывание новых кейсов, которые еще не прогонялись на приложении, новых стратегий, новых последовательностей и тд и тд. Т.е. __исследование__ качественных свойств системы. У девелоперов крайне плохо с этим, т.к. основная их обязанность — код писать и проектировать. А исследование, это самые разные инструменты. Смотришь, как работает система, делаешь наблюдения, анализируешь закономерности, придумываешь новые тесты и так 100% времени.

I>>И возвращаемся к старому вопросу — кто у вас делает эксплорейшн тестирование?
SK>Разработчики делают тестирование. Надо гонять свой код так, чтобы шанс ошибки был минимален. Называть это "эксплорейшн тестирование" или нет, я не скажу. В нашей области ошибка легко может стоить несколько десятков миллионов, так что к этому серьезно относятся.

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

Здравствуйте, Ikemefula, Вы писали:

I>Отлично, уже лучше. Но это автоматические тесты, они не выявляют новых видов багов. Т.е. если у тебя один тест на длину строки, то он найдет только баги с длиной строки и не сможет ничего сделать, если в строке символы не те.

А если, как это обычно и бывает, тесты просто сравнивают образец и результат?

I>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях.

А можно пример такого неизвестного случая?

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Отлично, уже лучше. Но это автоматические тесты, они не выявляют новых видов багов. Т.е. если у тебя один тест на длину строки, то он найдет только баги с длиной строки и не сможет ничего сделать, если в строке символы не те.

НС>А если, как это обычно и бывает, тесты просто сравнивают образец и результат?

Это чтото навроде approved tests? С ними ситуация ничем не лучше, просто некоторые кейсы проще покрывать вот такими тестами.

I>>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях.

НС>А можно пример такого неизвестного случая?

Теоретически, если у тебя астрономическое число тестов, таких не будет

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

Здравствуйте, Ikemefula, Вы писали:

I>Это чтото навроде approved tests? С ними ситуация ничем не лучше

Можно пример проблемы?

I>>>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях.
НС>>А можно пример такого неизвестного случая?
I>Теоретически, если у тебя астрономическое число тестов, таких не будет

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

Т.е примера не будет?

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Это чтото навроде approved tests? С ними ситуация ничем не лучше

НС>Можно пример проблемы?

Пример — косяки в трансляторах/компиляторах. https://github.com/Microsoft/TypeScript/issues?q=is%3Aissue+is%3Aclosed+label%3ABug

Проблема остаётся той же — старые тесты находят только старые виды багов. Один образец покрывает небольшое количество кейсов, как правило, счетное, см файлы в фолдере тестов из указаного репа. А вот количество комбинаций бесконечно.
Потому коммюнити регулярно находит баги в TS.

I>>>>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях.
НС>>>А можно пример такого неизвестного случая?
I>>Теоретически, если у тебя астрономическое число тестов, таких не будет

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

НС>Т.е примера не будет?

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

Здравствуйте, Ikemefula, Вы писали:

НС>>Можно пример проблемы?
I>Пример — косяки в трансляторах/компиляторах. https://github.com/Microsoft/TypeScript/issues?q=is%3Aissue+is%3Aclosed+label%3ABug

Давай конкретно. Просматривать 118 страниц я точно не буду.

I>Проблема остаётся той же — старые тесты находят только старые виды багов. Один образец покрывает небольшое количество кейсов, как правило, счетное, см файлы в фолдере тестов из указаного репа. А вот количество комбинаций бесконечно.

Я тебе в третий раз повторяю — не надо общих слов, давай конкретные примеры.

НС>>Т.е примера не будет?
I>См выше.

Выше это не пример, это посылание на три буквы.

Здравствуйте, cocacola, Вы писали:

C>Привет! Раньше в it конторах хоть как то в респектах были разработчики.
C>Счас какая-то хрень, набрали на одного разраба по 2 qa и по 2 мэнэджера, они сидят в носу ковыряют, важные такие, один
C>есть у нас Lead QA, жирный такой, ленивый, важный. А сам тупой, как валенок. Даже авто тесты не может написать. Вот накуя они нужны? ведь разрабы без них обойдуться, а они без них нет.
C>Только бюджет компании проедают. Что за тенденция? И лезут же, лезут, знаний нет, а пирог IT вкусный, за счет наглости кусочек урвать то хотят. С одного митинга на другой ходят. Создают видимость работы. ДА нахрен ваши митинги, продукты пишут разрабы, а вы там хоть обмитингуйтесь, ни хрена само не напишеться.
Да вообще никто не нужен, кроме PM-ов (вы их почему-то называете аналитиками).
Вот поговоришь с бизнесом, всё выяснишь, напишешь требования, поизучаешь на предмет реализуемости, заполнишь implementation notes со ссылками на библиотеки, которые брать, и иллюстрациями в псевдокоде.
Разрабы это берут, две недели в носу ковыряют, и потом такие "нуууу, это 40 мэндэев, плюс регрессия — итого через 11 месяцев зарелизим. Если не дропнем в процессе реприоритизации".
На вопрос "а вы не охренели" они такие "нуу, там же сначала надо анализ и дизайн, потом дизайн ревью, потом UX дизайн, потом вам же вечно наш UX не нравится — его переделывать придётся, потом собсно код, потом код ревью, потом автотесты, потом разбор результатов автотеста, вот и набигает!"
Берёт такой PM в руки студию, за два часа код пишет, ещё час проверяет, и отправляет клиенту со словами "вот вам патч, пользуйтесь, только вашему TAMу про него не говорите — этого релиза официально не существует".
Просто в PM надо брать людей не из маркетинга, которые там не справились, а тех разрабов, которые с предметной областью разобрались.

Здравствуйте, Sinclair, Вы писали:

S>Просто в PM надо брать людей не из маркетинга, которые там не справились, а тех разрабов, которые с предметной областью разобрались.

Сам себя не похвалишь — никто не похвалит. Вы нормально платить девелоперам не пробовали?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Можно пример проблемы?
I>>Пример — косяки в трансляторах/компиляторах. https://github.com/Microsoft/TypeScript/issues?q=is%3Aissue+is%3Aclosed+label%3ABug

НС>Давай конкретно. Просматривать 118 страниц я точно не буду.

Ткнуть в первый попавшийся ума не хватило ? https://github.com/Microsoft/TypeScript/issues/16139

I>>Проблема остаётся той же — старые тесты находят только старые виды багов. Один образец покрывает небольшое количество кейсов, как правило, счетное, см файлы в фолдере тестов из указаного репа. А вот количество комбинаций бесконечно.
НС>Я тебе в третий раз повторяю — не надо общих слов, давай конкретные примеры.
НС>>>Т.е примера не будет?
I>>См выше.

НС>Выше это не пример, это посылание на три буквы.

Извини, я тебе не психотерапевт.

Здравствуйте, Sinclair, Вы писали:

S>Берёт такой PM в руки студию, за два часа код пишет, ещё час проверяет, и отправляет клиенту со словами "вот вам патч, пользуйтесь, только вашему TAMу про него не говорите — этого релиза официально не существует".

У нас такие PM называются девелоперы

У вас не так ?

Здравствуйте, Ikemefula, Вы писали:

НС>>Давай конкретно. Просматривать 118 страниц я точно не буду.
I>Ткнуть в первый попавшийся ума не хватило ? https://github.com/Microsoft/TypeScript/issues/16139

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Давай конкретно. Просматривать 118 страниц я точно не буду.
I>>Ткнуть в первый попавшийся ума не хватило ? https://github.com/Microsoft/TypeScript/issues/16139

НС>Ну и? Банальный тест со сравнением вполне такую регрессию поймает, даже если про нее заранее ничего не знать. Если ты намекаешь что набор тестов может эту ситуацию не покрыть?

Именно — любой набор тестов не даёт 100% покрытия.

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

Правильно — со временем. В обычном софте проблемы возникают уже на уровне интеграции компонентов
1 комбинации
2 время
3 многозадачность
4 внешние зависимости
5 зависимости от сторонних компонентов
6 окружение
7 железо

В итоге получается так, что без QA хорошо если п.1, 2 и 3 закроешь, и то "со временем". Всё остальное это требует QA в обязательном порядке. При этом даже п.1 2 и 3 требуют проверки QA
а. девелопер воплощает в тесте ровно то, что и в коде, т.е. своё понимание. Кто проверит, что его понимание соответствует требованиям ?
б. чисто психологически исполнитель сам себя проверяет крайне слабо. То есть, при равной квалификации двух человек (a проверят a и b проверяет a) выигрывает второй вариант.
в. приёмка — как здесь обойтись без QA ?

Здравствуйте, Ikemefula, Вы писали:

НС>>Ну и? Банальный тест со сравнением вполне такую регрессию поймает, даже если про нее заранее ничего не знать. Если ты намекаешь что набор тестов может эту ситуацию не покрыть?
I>Именно — любой набор тестов не даёт 100% покрытия.

Ты прям Капитан Очевидность. Вот только изначально ты несколько иное заявлял:

Но это автоматические тесты, они не выявляют новых видов багов.

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

Правильно — таки набирается. А теперь почсмотри на свою цитату выше.

I> В обычном софте проблемы возникают уже на уровне интеграции компонентов

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

I>В итоге получается так, что без QA хорошо если п.1, 2 и 3 закроешь, и то "со временем". Всё остальное это требует QA в обязательном порядке. При этом даже п.1 2 и 3 требуют проверки QA

Ты слишком категоричен. Я лично лицезрел в рамках одной компании, когда похожие продукты разрабатывались двумя разными командами. В одной были выделенные QA, постоянно что то вручную тестирующие. А во второй вообще ни одного отделного QA спеца не было, ручное тестирование ограничивалось простенькой проверкой нескольких сценариев ПМом перед выкаткой очередного релиза на прод.
И вот что удивительно — багов в проде в первом случае было даже не в разы, а на порядки больше.
При этом я вовсе не утверждаю, что QA вообще не нужны. Просто все бывает очень по разному — разная предметная область, разная сложность и объем решений, разный уровень разработчиков, разный уровень ПМов.

I>а. девелопер воплощает в тесте ровно то, что и в коде, т.е. своё понимание. Кто проверит, что его понимание соответствует требованиям ?

Девелопер, не понимающий требований? Тут никакой QA не поможет.

I>б. чисто психологически исполнитель сам себя проверяет крайне слабо. То есть, при равной квалификации двух человек (a проверят a и b проверяет a) выигрывает второй вариант.

Опять же, не обобщай.

I>в. приёмка — как здесь обойтись без QA ?

Приемка — не всегда бывает, ваш КО.

Здравствуйте, Sinclair, Вы писали:

S>Просто в PM надо брать людей не из маркетинга, которые там не справились, а тех разрабов, которые с предметной областью разобрались.

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

Здравствуйте, pestis, Вы писали:

P>Сам себя не похвалишь — никто не похвалит. Вы нормально платить девелоперам не пробовали?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Ну и? Банальный тест со сравнением вполне такую регрессию поймает, даже если про нее заранее ничего не знать. Если ты намекаешь что набор тестов может эту ситуацию не покрыть?
I>>Именно — любой набор тестов не даёт 100% покрытия.

НС>Ты прям Капитан Очевидность. Вот только изначально ты несколько иное заявлял:
НС>

НС>Но это автоматические тесты, они не выявляют новых видов багов.

Правильно. Я говорил исключительно про автоматические тесты.

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

НС>Правильно — таки набирается. А теперь почсмотри на свою цитату выше.

Ты сам смотри. У меня 100% а у тебя взятые от балды 99.99 и неопределенный промежуток времени, который нужен, что бы покрыть тестами _старый_ функционал. То есть, новый функционал всегда будет иметь недостаточное количество тестов.

I>> В обычном софте проблемы возникают уже на уровне интеграции компонентов

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

Интеграционные тесты во первых, слишком медленные, во вторых, слишком дискретные.

I>>В итоге получается так, что без QA хорошо если п.1, 2 и 3 закроешь, и то "со временем". Всё остальное это требует QA в обязательном порядке. При этом даже п.1 2 и 3 требуют проверки QA

НС>Ты слишком категоричен. Я лично лицезрел в рамках одной компании, когда похожие продукты разрабатывались двумя разными командами. В одной были выделенные QA, постоянно что то вручную тестирующие. А во второй вообще ни одного отделного QA спеца не было, ручное тестирование ограничивалось простенькой проверкой нескольких сценариев ПМом перед выкаткой очередного релиза на прод.

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

НС>Девелопер, не понимающий требований? Тут никакой QA не поможет.

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

I>>б. чисто психологически исполнитель сам себя проверяет крайне слабо. То есть, при равной квалификации двух человек (a проверят a и b проверяет a) выигрывает второй вариант.
НС>Опять же, не обобщай.

Это факты. Так было уже в бородатые 70е, см Гленфорда Майерса.

I>>в. приёмка — как здесь обойтись без QA ?

НС>Приемка — не всегда бывает, ваш КО.

О чем и речь. И тестирование не всегда бывает. И даже девелоперами. И что с того ?

Здравствуйте, Ikemefula, Вы писали:

I>Правильно. Я говорил исключительно про автоматические тесты.

И я тоже.

НС>>Правильно — таки набирается. А теперь почсмотри на свою цитату выше.
I>Ты сам смотри. У меня 100%

Что 100%? Тестирование в принципе штука статистическая, никаких 100% нет нигже, не в автотестах, ни в ручном тестировании.

I>а у тебя взятые от балды 99.99 и неопределенный промежуток времени, который нужен, что бы покрыть тестами _старый_ функционал.

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

НС>>В обычном софте проблемы возникают практически везде. И таки интеграционные тесты тоже существуют и способны выявить баги, о которых ты заранее не подозревал.
I>Интеграционные тесты во первых, слишком медленные

Критерий?

I>во вторых, слишком дискретные.

Тем не менее определенный (существенный) процент багов они выявляют.

НС>>Ты слишком категоричен. Я лично лицезрел в рамках одной компании, когда похожие продукты разрабатывались двумя разными командами. В одной были выделенные QA, постоянно что то вручную тестирующие. А во второй вообще ни одного отделного QA спеца не было, ручное тестирование ограничивалось простенькой проверкой нескольких сценариев ПМом перед выкаткой очередного релиза на прод.
I>Реальность обычно прямо противоположна этому кейсу.

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

I> Более-менее серьезное приложение уже просто не прокликать одним человеком за рабочий день.

Это очень сильно зависит от приложения.

I> Пудозреваю, ты чтото недоговариваешь.

Ну или просто опыт у тебя с другого бока.

НС>>Приемка — не всегда бывает, ваш КО.
I>О чем и речь. И тестирование не всегда бывает. И даже девелоперами. И что с того ?

И то что QA не есть обязательное условие.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Что 100%? Тестирование в принципе штука статистическая, никаких 100% нет нигже, не в автотестах, ни в ручном тестировании.

Разумеется. И чем, по твоему, отличается ручной эксплорейшн тест и автоматический ?

I>>а у тебя взятые от балды 99.99 и неопределенный промежуток времени, который нужен, что бы покрыть тестами _старый_ функционал.
НС>Опять глупости говоришь. В тех же упомянутых тобой компиляторах тесты пишутся в начале, а только потом функционал.

Именно. Потому и вылазят тривиальные баги запросто так.

НС>>>В обычном софте проблемы возникают практически везде. И таки интеграционные тесты тоже существуют и способны выявить баги, о которых ты заранее не подозревал.
I>>Интеграционные тесты во первых, слишком медленные
НС>Критерий?

I>>Реальность обычно прямо противоположна этому кейсу.

НС>Это уж у кого какая реальность. Я вот реальный случай рассказываю, а от тебя даже гипотетических примеров приходится несколько сообщений просить.

Вот интересный пример, из жизни, я месяц кодил на асме, скомпилировал, запустил и всё заработало как положено. И что с того ? В чем тут принципиальная разница с твоим "а я в одной конторе ..." ?

НС>И то что QA не есть обязательное условие.

Спасибо, капитан! В треде речь вообще то про то, что они вообще не нужны.

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не, просто не надо заставлять девелоперов формировать окончательные сроки и планы. PM как раз и должен этим заниматься, а не от девелоперов качественное выполнение свой работы ожидать.
Это на самом деле была шутка про то, что каждая должность считает главной именно себя. Особенно какие-нибудь инфраструктурные подразделения этим грешат — скажем, у админов часто бывает звёздная болезнь; у бухгалтерии тоже.
А если без шуток, то имхо сегрегация конвеера — это тупиковый путь.
Продакт менеджеры, пришедшие из плохого маркетинга (того, где задача ставится в виде "помочь продать это говно", а внутренне понимается как "главное — выбить бюджет"), не могут скомпенсировать неспособность вообще понять технические особенности продукта ежедневными усилиями.
Программисты, намеренно изолирующие себя от потребностей бизнеса, встают в позу "да эти дебилы из продакт департмент сами не знают, чо хотят. Вот я щас как зделаю ровно по требования — пусть поймут, какие они тупые тогда".
При долгой практике умение понимать пользователя вообще атрофируется (особенно если метрики, за которые награждают и карают, измеряются в фуфле вроде количества реализованных сценариев), и программер искренне недоумевает, почему продакт матерится при виде очередного тригрида с пропертидайлогом. (Если бы не NDA, я бы таких вам показал примеров из нашего продукта, что весь форум UX в ужасе разбежится).
Тестеры, которые "без нас всё вообще умрёт", ожесточённо тестируют экзотические сценарии, забывая о банальностях. В итоге растёт взаимная враждебность: "мы этот рейс кондишен три недели всем отделом ловили, а продакт закрыл с формулировкой 'у нас полтора миллиона пользователей, и ни один на это не наступил. Отложим, пока в продакшне не воспроизведётся", и "блин они мне тут эксплоратори месяц гоняли, а на первом же демо партнёрам выяснилось, что заказы с количеством больше 1 в штаты приводят к UnexpectedError".

Причём "корпоративный способ", когда "а давайте зашедулим еженедельные митинги между каждой парой команд" ведёт только к кратковременному улучшению — когда какой-нибудь очевидный идиотизм вроде списка компонентов, не совпадающего у девелоперов и у саппорта, однократно чинится. А потом это превращается в обузу — потому что девелопмент из 40 часов в неделю начинает 8 тратить на "регулярные встречи" с сейлзами, маркетингом, саппортом, QA, продакт менеджментом, UX дизайнерами, юристами, и accounts receivable.

Наиболее толковые результаты возникают всегда на стыке специальностей — когда продакт умеет программировать, или дизайнить, или и то и другое. Или там, девелопер владеет fluent english, и в курсе особенностей рынка и конкурентов на нём, а также умеет работать с QA-инфраструктурой, и читал книги Нильсена и Тафте.
В жизни корпораций такое встречается редко, потому что там начинается гонка — девелопер должен отгружать код 40 часов в неделю; ему некогда заниматься чтением wall street journal.
Или там продакт менеджер тратит недели на изучение обновлённых прайс листов от Microsoft, потому что он не владеет скриптингом и не может написать автоматическую сравнивалку прайсов.

Здравствуйте, Sinclair, Вы писали:

S>А если без шуток, то имхо сегрегация конвеера — это тупиковый путь.

Да кто ж его специально сегрегирует. Вот только девелопера калачом не заманишь на роль PM. C Product Owner, конечно, все немного интереснее, но тут обратная проблема — тех кто хорошо умеет общаться с другими и среди общей массы то очень мало, а уж среди девелоперов вообще швах.

S>Тестеры, которые "без нас всё вообще умрёт", ожесточённо тестируют экзотические сценарии, забывая о банальностях.

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

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Да кто ж его специально сегрегирует.
Как кто? Решения о создании департаментов и принятии штатного расписания принимает непосредственное руководство.
НС>Вот только девелопера калачом не заманишь на роль PM.
А вот это непонятно. Ну, то есть понятно, что PMствовать должен экстраверт. Но в моей практике нормальных программистов-экстравертов мало, но достаточно.
Это, скажем так, неверная установка. Люди хотят копать "вглубь", думая, что это увеличивает их ценность как профессионалов.
Но мы сейчас живём в такое время, когда помнить наизусть штуки типа "как сделать компайл-тайм вычисления на взаимно-рекурсивных частично специализированных шаблонах" нафиг не надо.
Если ты в состоянии более-менее внятно сформулировать проблему, то её решение быстрее найти на stackoverflow, чем придумать самому. Это как помнить таблицу Unicode наизусть — не это делает человека разработчиком.

Важно обучать людей тому, что важно умение работать "поперёк", потому что многогранный специалист гораздо эффективнее самой классной команды в матричной структуре — тупо потому, что внутренняя речь быстрее речи вслух.
НС>Так надо начальником тестеров не ихнего специального сеньор QA, а тимлида, и проблема "тестируем не то" волшебным образом исчезнет.
Ты пойми, что без понимания общей задачи можно делать начальником тестеров кого угодно, и результат всё равно будет идиотическим.
Потому, что тимлид читает "...заказчик выбирает одну из сохранённых в системе кредитных карт..." Отлично! Влепим попап с выбором из списка и поиском! " ... или вводит данные для новой карты..." Отлично! Влепим попап с проперти гридом!.
Ставит задачу девелоперам; ставит задачу тестерам. Тестеры честно проверяют, что попапы показываются, и что нельзя уйти со страницы, не введя карту.
Потом тестеры с гордостью находят разнообразные контрпримеры, типа "на фаерфоксе 18 с отключенным жаваскриптом попап не срабатывает", или "если все сохранённые карты проекспайрились, то возникает unexpected end of list".
Никому и в голову не приходит спросить, а сколько % продаж идут через добавление новой карты, в скольки % используется единственная карта, в скольки % их две, и в скольки их 10 или больше. А чо? Сценарий покрыт, чего ещё.
Если маркетинг начинает пытаться им намекнуть, что надо бы оптимизироваться под наиболее частый сценарий, вводя обороты типа "использовать карту по умолчанию", то тимлид так и хреначит "ок, воткнём радио баттон: карта по умолчанию, новая карта, другая карта".
Идея "а давайте у нас специально обученные люди будут рисовать мокапы, а программисты потом будут их воплощать" — такое же зло, что и идея с выделением QA департамента.
В идеальном мире PM сам прототипирует UI прямо в библиотеке элементов, и вместо уродливых карандашных рисунков мы имеем 99% близкие к финалу формы. Выбрав наиболее понравившийся прототип, мы его обвязываем кодом.
Не обязательно всё это должен делать один и тот же человек, может и команда — но не функционально разделённая команда. Эффективнее будет, если 3 человека строчат каждый по функциональному фрагменту, чем когда мы имеем одного тестера, одного дизайнера, одного программиста, одного PM, и т.п.

Здравствуйте, Sinclair, Вы писали:

НС>>Вот только девелопера калачом не заманишь на роль PM.
S>А вот это непонятно.

А что тут непонятного? Зарплата та же, если не меньше. Работа скучная и нудная. Карьерные перспективы, конечно, получше, но рядовых девелоперов это, обычно, волнует слабо.

S> Ну, то есть понятно, что PMствовать должен экстраверт.

И это тоже.

S>Это, скажем так, неверная установка. Люди хотят копать "вглубь", думая, что это увеличивает их ценность как профессионалов.

Это у тебя какие то странные представления. Люди, как правило, хотят копать вглубь потому что интересно. А которые про ценность постоянно думают — эти да, этим пофик что делать. Вот только, как показывает практика, из таких и разработчкики фиговые, и ПМ.

S>Если ты в состоянии более-менее внятно сформулировать проблему, то её решение быстрее найти на stackoverflow, чем придумать самому.

В 95% случаев. Но есть еще 5, в которых SO тебя не спасет. Вроде и немного, но этих 5% вполне достаточно, чтобы проект у команды, состоящей из таких мелко плавающих спецов по SO либо встал, либо, что еще печальнее, дожил до релиза, а потом с ним в реальных условиях приключился нерековерабельный бада бум. И вот тут то у овнера и настает веселье, когда с одной стороны его задницу поджаривают сейлзы, у которых в момент демонстрации происходят внезапные факапчики, а с другой девелоперы с ПМом, которые разводят руками с выражением на лице в стиле "ну не шмогла я". После чего все великие спецы по SO в полном составе отправляются на выход.

S>Важно обучать людей тому, что важно умение работать "поперёк", потому что многогранный специалист гораздо эффективнее самой классной команды в матричной структуре — тупо потому, что внутренняя речь быстрее речи вслух.

Безусловно. Но это совсем другой вопрос.

НС>>Так надо начальником тестеров не ихнего специального сеньор QA, а тимлида, и проблема "тестируем не то" волшебным образом исчезнет.
S>Ты пойми, что без понимания общей задачи можно делать начальником тестеров кого угодно, и результат всё равно будет идиотическим.

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

S>Потому, что тимлид читает "...заказчик выбирает одну из сохранённых в системе кредитных карт..." Отлично! Влепим попап с выбором из списка и поиском! " ... или вводит данные для новой карты..." Отлично! Влепим попап с проперти гридом!.

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

S>Если маркетинг начинает пытаться им намекнуть

Маркетинг напрямую девелоперам, минуя овнера? Глупее придумать сложно.

S>В идеальном мире PM сам прототипирует UI

ПМ? Это вообще не его задача, это задача овнера. Задача ПМ (который Project) — обеспечить правильное планирование и эффективное использование ресурсов любыми способами. А прототипирование UI, хотя бы на уровне концепции — это, по сути, требования, и прямая обязанность product owner.

S>Не обязательно всё это должен делать один и тот же человек, может и команда — но не функционально разделённая команда. Эффективнее будет, если 3 человека строчат каждый по функциональному фрагменту, чем когда мы имеем одного тестера, одного дизайнера, одного программиста, одного PM, и т.п.

Зависит от размера команды. Ну и как то совмещение ПМ с чем то еще меня лично пугает — ничего хорошего из этого не выйдет. ПМ даже в небольшом проекте обычно загружен по самые яйца своими задачами.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А что тут непонятного? Зарплата та же, если не меньше. Работа скучная и нудная. Карьерные перспективы, конечно, получше, но рядовых девелоперов это, обычно, волнует слабо.
У нас ProdM не зарабатывают меньше девелоперов.
НС>Это у тебя какие то странные представления. Люди, как правило, хотят копать вглубь потому что интересно.
"интересность" — это очень странный параметр. Интересом нужно управлять. Без самоуправления, интерес вывозит человека в эксперта по сериалам и шаурме в окрестных киосках.
Мне вот интересно как делать хорошие продукты. И в это входит вообще всё — и алгоритмы в СУБД, и методики тестирования, и паттерны ООП, и когнитивная психология, и вопросы продуктизации.
Те, кто добровольно отказывается от чего-то из этого, мне непонятны.
НС>В 95% случаев. Но есть еще 5, в которых SO тебя не спасет. Вроде и немного, но этих 5% вполне достаточно, чтобы проект у команды, состоящей из таких мелко плавающих спецов по SO либо встал, либо, что еще печальнее, дожил до релиза, а потом с ним в реальных условиях приключился нерековерабельный бада бум.
А зачем "мелкоплавающих"? Пусть будут глубоко плавающие. Я про то, что надо знать основы — про управление сложностью, про взаимодействие компонентов, уметь быстро в голове построить модель параллельного исполнения кода.
Как ни удивительно, но очень часто бывает так, что разработчик, детально помнящий наизусть все примитивы современных агентно-ориентированных библиотек, в принципе не может вьехать в то, "как это между зачислением и списанием вклинится ещё одна операция".

НС>Было бы странно, если бы тимлид ее не понимал.
Да? А вот я сплошь и рядом встречаю результаты действий команд, в которых тимлид вообще не понял, про что его задача.
НС>Это какой то странный тимлид. То ли молодой очень, то ли профнепригодный.
Это стандартный тимлид, который мыслит категориями стандартной библиотеки компонентов. Таких, к сожалению, большинство.
НС>Я уж не говорю о том, что чекать такие вещи на ранних этапах — прямая обязанность овнера.
Судя по всему, вы овнером называете как раз того, кого у нас называют product manager.
S>>Если маркетинг начинает пытаться им намекнуть
НС>Маркетинг напрямую девелоперам, минуя овнера? Глупее придумать сложно.
Я говорю о Product Manager, который "из маркетинга", и сам ни строчки кода не может написать.
S>>В идеальном мире PM сам прототипирует UI
НС>ПМ? Это вообще не его задача, это задача овнера. Задача ПМ (который Project) — обеспечить правильное планирование и эффективное использование ресурсов любыми способами. А прототипирование UI, хотя бы на уровне концепции — это, по сути, требования, и прямая обязанность product owner.
Тогда мы об одном и том же. Вот у нас в компании мокапами занимается отдельная команда, а прототипирования нету вовсе.
НС>Зависит от размера команды. Ну и как то совмещение ПМ с чем то еще меня лично пугает — ничего хорошего из этого не выйдет. ПМ даже в небольшом проекте обычно загружен по самые яйца своими задачами.
Тот PM, про которого вы говорите — это администратор. От него вообще ничего не надо, кроме умения следить за расходниками и учётом рабочего времени. Я говорю про ProdM.

Здравствуйте, Sinclair, Вы писали:

НС>>А что тут непонятного? Зарплата та же, если не меньше. Работа скучная и нудная. Карьерные перспективы, конечно, получше, но рядовых девелоперов это, обычно, волнует слабо.
S>У нас ProdM не зарабатывают меньше девелоперов.

Под PM, если без расшифровки, обычно понимают Project Manager.

НС>>Это у тебя какие то странные представления. Люди, как правило, хотят копать вглубь потому что интересно.
S>"интересность" — это очень странный параметр. Интересом нужно управлять. Без самоуправления, интерес вывозит человека в эксперта по сериалам и шаурме в окрестных киосках.

Управлять то можно, но есть пределы, у каждого свои.

S>А зачем "мелкоплавающих"? Пусть будут глубоко плавающие.

А глубоко плавающие не только в гугле ответы на SO искать умеют. Ты ж сам написал сперва про то, что копать вглубь не надо.

S>Как ни удивительно, но очень часто бывает так, что разработчик, детально помнящий наизусть все примитивы современных агентно-ориентированных библиотек

Это ты называешь "копать вглубь"?

НС>>Было бы странно, если бы тимлид ее не понимал.
S>Да? А вот я сплошь и рядом встречаю результаты действий команд, в которых тимлид вообще не понял, про что его задача.

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

НС>>Это какой то странный тимлид. То ли молодой очень, то ли профнепригодный.
S>Это стандартный тимлид, который мыслит категориями стандартной библиотеки компонентов.

Это тогда не тимлид, а просто разработчик, даже не сеньор. Тимлид это уже не просто разработчик, более корректно эту должность обзывать developer manager. Чем то там управлять не понимая куда надо двигаться — какая то в высшей степени странная ситуация. Можно еще, к примеру, лобовое стекло затонировать не той стороной, а потом удивляться что ты далеко от стоянки не отъехал.

НС>>Я уж не говорю о том, что чекать такие вещи на ранних этапах — прямая обязанность овнера.
S>Судя по всему, вы овнером называете как раз того, кого у нас называют product manager.

Это примерно одно и тоже, просто owner это скрамовская терминология, несколько более узкое понятие.

НС>>Маркетинг напрямую девелоперам, минуя овнера? Глупее придумать сложно.
S>Я говорю о Product Manager, который "из маркетинга", и сам ни строчки кода не может написать.

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

	От:	cocacola
	Дата:	18.05.17 23:45
	Оценка:	9 (1) +10

От:	Эйнсток Файр	Странный реагент
Дата:	19.05.17 00:37
Оценка:	+7 -1

	От:	StanislavK
	Дата:	19.05.17 07:07
	Оценка:

	От:	CreatorCray
	Дата:	19.05.17 07:24
	Оценка:	1 (1) +14

	От:	StanislavK
	Дата:	19.05.17 08:35
	Оценка:	+3 -1

	От:	Gradiens
	Дата:	19.05.17 11:38
	Оценка:	3 (1) +7

От:	koandrew	http://thingselectronic.blogspot.ca/
Дата:	19.05.17 17:05
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	20.05.17 08:50
	Оценка:	4 (1)

	От:	Ночной Смотрящий
	Дата:	20.05.17 19:39
	Оценка:	+2

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	22.05.17 09:23
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	23.05.17 09:16
Оценка:

От:	Artem Korneev	https://www.linkedin.com/in/artemkorneev/
Дата:	25.05.17 21:57
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	08.06.17 10:10
Оценка: