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

Ахах. простите.

ты вот это видет ? > Roman DJ ZX Gorin, [24.10.17 12:51] у девелоперов опыт в тестировании софта обычно больше, так как они софт тестируют в разы чаще и плотнее постоянно

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

хз. все плохо

ты вот это видет ? > Roman DJ ZX Gorin, [24.10.17 12:51] у девелоперов опыт в тестировании софта обычно больше, так как они софт тестируют в разы чаще и плотнее постоянно

как это связано с высказыванием "любой программист тестирует свой код всегда"

хз. все плохо

он работает как задумано, факт

Окей, как вы считаете, почему не хватает опыта?) Может потому что на это не выделяется время?)

все люди едят. я вот сейчас не поел. значит я не человек

тадам

все люди едят. я вот сейчас не поел. значит я не человек

эм, но ведь.. это неверно.

Окей, как вы считаете, почему не хватает опыта?) Может потому что на это не выделяется время?)

желание нет. задачи такой нет.

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

эм, но ведь.. это неверно.

у нас сейчас вот такие контр примеры идут в беседе

желание нет. задачи такой нет.

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

ну нет

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

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

вообще конечно и такая ситуация возможна

есть 2 варианта что разрабы такие молодцы все сам находят, но тогда бизнес решение странное держать целый отдел тестировщиков. Либо отдел тестировщиков находит n-нное кол-во багов в месяц тем самым доказывая что идеальный отдел разрабов лажает на какое-то кол-ва раз в месяц

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

есть 2 варианта что разрабы такие молодцы все сам находят, но тогда бизнес решение странное держать целый отдел тестировщиков. Либо отдел тестировщиков находит n-нное кол-во багов в месяц тем самым доказывая что идеальный отдел разрабов лажает на какое-то кол-ва раз в месяц

наличие багов в продукте обусловленно не только "лажанием" кого либо

о да, всё сказанное звучит как "вот мои фломастры с гумусом самые лучшие".

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

с какими профессионалами? в чём?

но если разрабы все пофиксили протестровали все то откуда вот это все

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

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

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

почему мы тут кидаемся какими то постулатами с жесткими формулировками??

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

вы говорите о глупых ограниченных программистах и о крайне ограниченных тестировщиках

я говорю : все люди едят а роман такой: я вот сейчас не ем, значит я не человек чтоли?

ну и вся дискуссия такая

на каких то глупых контр примерах

на каких то глупых контр примерах

Вы вообще о чем начали холивар?

обо всем

обо всем

Сколько смысла....

ещё раз - тестирование - это активность, обеспечение качества - задача всех разработчиков. девелопер при разработке обязан: 1) проанализировать доменную область софта/фичи 2) задизайнить скелет функционала 3) выяснить кейсы пользования 4) придумать/описать реализацию 5) задизайнить софтину 6) проверить работоспособность функционала

что из этого мы отдаём тестировщику и готовы сказать деву "не делай этого"?

Всё, если это будет выгодно для бизнеса :D

А какие у вас критерии того, что функционал готов и его можно отдать в прод?

А какие у вас критерии того, что функционал готов и его можно отдать в прод?

критерии готовятся же на этапе дизайна и оценки юзкейсов

Кстати, обеспечение качества - задача всей команды, разве нет?

да!

Ну а общие критерии есть? Типа, чтоб вся бизнес-логика работала, например

У Романа главная причина существования тестировщиков

Roman DJ ZX Gorin, [٢٤.١٠.١٧ ٠٤:١٧] нет, не будет, тестировщики дешевле, на них при желании можно сваливать факапы в проде и они выполняют работу, которую кодеры просто не хотят делать

на них при желании можно сваливать факапы в проде

победа

вы взяли один из трёх пунктов

не самый главный, но для бизнеса весомый

помоему ответсвенность на всей команде лежит

помоему ответсвенность на всей команде лежит

в вашем идеальном мире ))

в моей команде так было

в моей команде так было

??

на них при желании можно сваливать факапы в проде

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

и разработчики тестировали задачи

и просили помощи у тестировщика

и советов просили

и просили что-то протестировать

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

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

и мы вместе командой продумывали приемочные критерии к фичам

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

+++

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

отдел должен был найти все баги, правильно?

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

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

отдел должен был найти все баги, правильно?

Вот прям все-все? )

и Роман, вы так и не поделились своим мнением про QA

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

еще раз - отдел должен был найти все баги, в том числе критические?

отдел должен был найти все баги, правильно?

зачем это тестировщикам делать у Ромы же разрабы КАЖДЫЙ ВАРИАНТ ДЕБАЖАТ > я только что пришёл с планирования, где все девелоперы рассказывали про каждую стори, что они проверяют свои чекины, делают смоуки, дебажат каждый вариант до того, как сдать в тестирование тестировщикам

еще раз - отдел должен был найти все баги, в том числе критические?

я достаточно понятно ответил, без фантазий о "все баги"

какие криты в проде с такими то бого-разрабами

я достаточно понятно ответил, без фантазий о "все баги"

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

можно минор пропустить

+

Слушайте, вот вопрос: если у ромы на работе тестировщики не находят багов и в проде нет багов - тогда может действительно ему тестировщики не нужны.

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

Нет. Найти все баги <> отсутствие багов p1 на проде

Слушайте, вот вопрос: если у ромы на работе тестировщики не находят багов и в проде нет багов - тогда может действительно ему тестировщики не нужны.

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

Нет. Найти все баги <> отсутствие багов p1 на проде

фу какое неприятное "неравно"!

Нет. Найти все баги <> отсутствие багов p1 на проде

ок, найти все критические баги?

даешь !=

я слышал аналогичное мнение, что хорошему разрабу и аналитик не нужен

даешь !=

:)

я слышал аналогичное мнение, что хорошему разрабу и аналитик не нужен

ага, а потом получается как в гифке про шлагбаум и поезд

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

нет

ок, найти все критические баги?

нет

я слышал аналогичное мнение, что хорошему разрабу и аналитик не нужен

Хорошему разрабу никто не нужен

воистину

ещё раз - тестирование - это активность, обеспечение качества - задача всех разработчиков. девелопер при разработке обязан: 1) проанализировать доменную область софта/фичи 2) задизайнить скелет функционала 3) выяснить кейсы пользования 4) придумать/описать реализацию 5) задизайнить софтину 6) проверить работоспособность функционала

вот

Когда я такое заявил на одном из собеседований, мне сказали "что я забыл в профессии" ))

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

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

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

опять про меня?

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

Хорошему разрабу никто не нужен

Даже работа =)

И опять +++

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

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

Даже работа =)

Особенно

на самом деле есть хитрость. берем ПМИ(программа и методика испытаний). согласовываем с заказчиком. если по ПМИ нет багов, значит багов нет 100 процентов

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

Опять про нас?)