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

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

P.S.
если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь.
спасиба.

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

O>в последнее время начал слышать подобные утверждения.
O>в большинстве случаев со стороны самих тестировщиков.

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

O>P.S.
O>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь.
O>спасиба.

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

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

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

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

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

M>Если же речь идет именно о менеджерской активности, то тут нужны несколько другие знания и умения. И как по мне, в этом плане тестировщики и разработчики абсолютно равны. Особенно, это проявляется, если проект смешанный: есть не только разработчики, то и тестировщики, а также другие должности.


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



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


Думаю знание технологий у девелоперов гооораздо глубже. соответственно Девелопер Гооораздо лучше может оценить риски "гемора определенного рода".


Для тестеров все что идет глубже UI — черный ящик. Для девелопера — нет.

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

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

M>>Если же речь идет именно о менеджерской активности, то тут нужны несколько другие знания и умения. И как по мне, в этом плане тестировщики и разработчики абсолютно равны. Особенно, это проявляется, если проект смешанный: есть не только разработчики, то и тестировщики, а также другие должности.


O>Девелоперу разобраться в деталях Тестерской работы — думаю легко (особенно девелоперу доросшему до высоких порзиций — вообще не проблемма). Верно? Верно.
O>Крутому Тестеру разобраться в деталях Девелоперской работы — не реально. Верно? верно.

Неверно, дело тут не в том чтобы разобраться в технологии, например в управлении проектами особо технологий то и нет никаких.
Думаю вы слышали о таком понятии как несовместимость ролей ( если нет посмотрите методологии RUF, MSF, и т.д. ).
Например :

программист & пм — несовместимая роль , то есть программист не может совмещать роль пма в проекте, точнее конечно может все , но это будет не эффективно

пограммист & тестировщик — несовместимая роль

программист & архитектор — совместимая роль


тестировщик & аналитик — совместимая роль

аналитик & пм — совместимая роль

тестировщик & пм — совместимая роль

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

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

Были в моей карьере ПМ-ы и из прогеров и из тестеров.

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

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

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

Хотя, конечно, в самом начале работы ПМ-ом и у тех и у других будут косяки первое время.

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

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

M>>Если же речь идет именно о менеджерской активности, то тут нужны несколько другие знания и умения. И как по мне, в этом плане тестировщики и разработчики абсолютно равны. Особенно, это проявляется, если проект смешанный: есть не только разработчики, то и тестировщики, а также другие должности.


O>Девелоперу разобраться в деталях Тестерской работы — думаю легко (особенно девелоперу доросшему до высоких порзиций — вообще не проблемма). Верно? Верно.

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

O>Крутому Тестеру разобраться в деталях Девелоперской работы — не реально. Верно? верно.

Тоже не факт. К тому же, в ряде видов тестирования используются такие же практики, что и для разработки.

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

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

O>Думаю знание технологий у девелоперов гооораздо глубже. соответственно Девелопер Гооораздо лучше может оценить риски "гемора определенного рода".

Да, особенно по части технической реализации. Об этом я и говорил.

O>Для тестеров все что идет глубже UI — черный ящик. Для девелопера — нет.

Как раз всё наоборот: UI — это черный ящик. Но есть и более низкие уровни, на которых работают не девелоперы, а тестировщики.
И в ряде случаев, те же тестировщики работают тоже на уровне кода. Зависит от того, что за система разрабатывается.

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

F>программист & пм — несовместимая роль , то есть программист не может совмещать роль пма в проекте, точнее конечно может все , но это будет не эффективно

F>пограммист & тестировщик — несовместимая роль

F>программист & архитектор — совместимая роль


F>тестировщик & аналитик — совместимая роль

F>аналитик & пм — совместимая роль

F>тестировщик & пм — совместимая роль

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

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

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

O>в последнее время начал слышать подобные утверждения.
O>в большинстве случаев со стороны самих тестировщиков.

Смотря что за "Проджект Менеджер" имеется в виду.

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

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

А так... ПМ, ПМ... оно вам надо? Доход на 10% больше, а ответственности до балды. А девелопером красота, сидишь код ваяешь как нравится, в 9 пришёл, в 6 ушёл, никто тебя не парит.

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

O>>Девелоперу разобраться в деталях Тестерской работы — думаю легко (особенно девелоперу доросшему до высоких порзиций — вообще не проблемма). Верно? Верно.
M>В корне неверно, если, конечно, под тестером подразумевается не джуниор тестер, которому надо только кликать по кнопкам в соответствии с предписаниями.
а скажите, вы видели хоть одного такого тестера который бы не кликал по кнопкам? чем же они тогда занимаются?
если вы скажете что видели тестера который писал сам, с ноля юниттесты или тулзу для нагрузочного тестирования — то это уже полноценный разработчик, и речь не об этих людях. А вот что такого сложного делают тестеры помимо кликания чего не сможет девелопер??? ну приведите хоть ктонибудь хоть один пример.
а то у меня сложилось впечатление что ни один тестер не выходит дальше пределов "кликания", но т.к. человека надо продвигать по службе, карьерный рост или хз что — то начинают навешивать ярлыки — Senior software testing engineer ..lead testing ... и соответствующие з/п сравнимые с разработческими. чем они там занимаются хз — но я внешних отличий не вижу. Расскажите ктонибудь, кто в курсе.

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

ЗИГ>Здравствуйте, Marduk, Вы писали:

O>>>Девелоперу разобраться в деталях Тестерской работы — думаю легко (особенно девелоперу доросшему до высоких порзиций — вообще не проблемма). Верно? Верно.
M>>В корне неверно, если, конечно, под тестером подразумевается не джуниор тестер, которому надо только кликать по кнопкам в соответствии с предписаниями.
ЗИГ>а скажите, вы видели хоть одного такого тестера который бы не кликал по кнопкам?

Конечно видел, знаю. И мерзкую рожу одного из них я вижу каждый день в зеркале.

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

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

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

ЗИГ>а то у меня сложилось впечатление что ни один тестер не выходит дальше пределов "кликания",

А у вас от тестеров ждут чего-то кроме кликанья? Бессистемное кликанье в данный момент более-менее применимо разве что в игроделе и то не факт, что всё совсем бессистемно. То есть, во-первых, кому-то надо бы эту систему выработать, определить метрики, определить задачи.

Затем ,можно посмотреть в сторону автоматизации ряда процессов. А потом полученное решение прикрутить к автосборке.

ЗИГ>но т.к. человека надо продвигать по службе, карьерный рост или хз что — то начинают навешивать ярлыки — Senior software testing engineer ..lead testing ... и соответствующие з/п сравнимые с разработческими.
ЗИГ>чем они там занимаются хз — но я внешних отличий не вижу. Расскажите ктонибудь, кто в курсе.

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

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

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

ЗИГ>>чем же они тогда занимаются?
ЗИГ>>если вы скажете что видели тестера который писал сам, с ноля юниттесты или тулзу для нагрузочного тестирования — то это уже полноценный разработчик, и речь не об этих людях.
ЗИГ>>А вот что такого сложного делают тестеры помимо кликания чего не сможет девелопер???
ЗИГ>>ну приведите хоть ктонибудь хоть один пример.
M>В более-менее крупных проектах врядли девелопер сможет используя свои данные сказать, что разработанный продукт соответствует заявленным требованиям на XX% и на основе этого сделать вывод, пускать его в жизнь или отправить на доработку. Для этого и придумали тех же QA, QC.
M>Опять же, в планировании тестирования может быть много дыр, так как видов тестирования может быть много и каждый из них имеет свой набор подходов, практик и инструментов.
вот знаете, если отбросить все умные слова, лишнюю воду из ваших слов, — мне все равно продолжает оставаться неясным — что же именно вы все-таки каждый день делаете? видов тестирования много.... — это на словах так, а на деле — человек тупо ходит по сайту (если у нас сайт), и начинает с того чтобы проверить — чтоб функционал весь соответствовал спецификации. ищет нестандартные места которые в спеке не описаны — не упадет ли при этом ничего. потом уже может и бессистемно потыкает куда-нибудь. Так вот, это все я называю кликанием. Объясните пожалуйста, что же еще есть помимо этого.
Причем даже этим эти т.н. QA занимаются из рук вон плохо. я в процессе разработки уже в существующем коде вижу места, где нас, разработчиков, можно подловить, — и иной раз штук по 5 в день благодаря мне тестеры заводят багов, — у них у самих так не получается, потому что они слепо тычутся по ui и внутрь не заглядывают. причем что обычные джуниоры что сениоры тестировщики. Вот вы, работаете с исходным кодом, скажите? И что именно вы делаете помимо того что я уже описала?

нет, по-моему король абсолютно голый.

ЗИГ>>а то у меня сложилось впечатление что ни один тестер не выходит дальше пределов "кликания",
M>А у вас от тестеров ждут чего-то кроме кликанья? Бессистемное кликанье в данный момент более-менее применимо разве что в игроделе и то не факт, что всё совсем бессистемно. То есть, во-первых, кому-то надо бы эту систему выработать, определить метрики, определить задачи.
блаблабла. Ну может быть, да — надо выработать систему чтоб поэффективнее проходил процесс кликания. Метрики — это типа если есть хоть один мажорный незакрытый баг, значит билд не качественный и нельзя выпускать в продакшн? Да, спору нет, гениальные метрики. Разработчики бы до таких не додумались. Не поймите мой сарказм превратно — метрика нормальная, только я до сих пор не вижу каких-то недоступных пониманию разработчика вещей, увы.

M>Затем ,можно посмотреть в сторону автоматизации ряда процессов. А потом полученное решение прикрутить к автосборке.
Ок, расскажите, как именно тестеры что-то автоматизируют без работы с исходным кодом?
Крутить автосборкой опять же больших тестерских умений не надо — это и разработчики могли бы делать — тем более что там один раз настроил, и всё..

ЗИГ>>но т.к. человека надо продвигать по службе, карьерный рост или хз что — то начинают навешивать ярлыки — Senior software testing engineer ..lead testing ... и соответствующие з/п сравнимые с разработческими.
ЗИГ>>чем они там занимаются хз — но я внешних отличий не вижу. Расскажите ктонибудь, кто в курсе.
M>Найдите вакансии тестировщиков зп сопоставимыми с разработчиками и там будут описаны требуемые навыки и выполняемые обязанности. Скорее всего вы увидите, что там кликерством не ограничиваются.
да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? работа разработчика в разы сложнее!

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

ЗИГ>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? работа разработчика в разы сложнее!

Вот за то, что мы не увлекаемся такими обобщениями, нас и ценят.

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

R>Здравствуйте, злая и глупая, Вы писали:

ЗИГ>>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? работа разработчика в разы сложнее!

R>Вот за то, что мы не увлекаемся такими обобщениями, нас и ценят.
и опять красивые слова за которыми ничего нет.

Здравствуйте, злая и глупая:
> А вот что такого сложного делают
> тестеры помимо кликания чего не сможет девелопер??? ну приведите хоть
> ктонибудь хоть один пример.

Проникающее тестирование (или как там оно называется, тестирование на
проникновение?).

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

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

1. Тестировщикам часто приходится писать не код, поэтому, как правило, они немножко грамотнее
   
2. Тестировщикам чаще приходится врубаться в предметную область, поэтому им проще получить общую картинку
   
3. Хорошие тестировщики уважительно относятся и к разработчикам, и к заказчикам, не считая ни тех, ни других идиотами и бракоделами
   
4. Тестировщики больше работают с людьми, и легко осваивают боевое НЛП
   
5. Тестировщик делает свое дело и уходит в другой проект, так что имеет больше возможностей для широкого охвата технологий, процессов и команд
   
6. Многие тестировщики приходят в профессию не с программистских специальностей (см. "предметная область"), поэтому они не такие зануды
   
7. ...
   
8. ну и так далее

При наличии способностей, менеджера можно сделать и из разработчика. Но его будет жалко.

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

ЗИГ>Здравствуйте, Marduk, Вы писали:

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

На самом деле мы сейчас сваливаемся в оффтоп. Тема изначально не про это.

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

ЗИГ>>>чем же они тогда занимаются?
ЗИГ>>>если вы скажете что видели тестера который писал сам, с ноля юниттесты или тулзу для нагрузочного тестирования — то это уже полноценный разработчик, и речь не об этих людях.
ЗИГ>>>А вот что такого сложного делают тестеры помимо кликания чего не сможет девелопер???
ЗИГ>>>ну приведите хоть ктонибудь хоть один пример.
M>>В более-менее крупных проектах врядли девелопер сможет используя свои данные сказать, что разработанный продукт соответствует заявленным требованиям на XX% и на основе этого сделать вывод, пускать его в жизнь или отправить на доработку. Для этого и придумали тех же QA, QC.
M>>Опять же, в планировании тестирования может быть много дыр, так как видов тестирования может быть много и каждый из них имеет свой набор подходов, практик и инструментов.
ЗИГ>вот знаете, если отбросить все умные слова, лишнюю воду из ваших слов, — мне все равно продолжает оставаться неясным — что же именно вы все-таки каждый день делаете? видов тестирования много.... — это на словах так, а на деле —

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

Как вы представляете себе тестирование сервисов, которые не имеют UI?

ЗИГ>человек тупо ходит по сайту (если у нас сайт), и начинает с того чтобы проверить — чтоб функционал весь соответствовал спецификации. ищет нестандартные места которые в спеке не описаны — не упадет ли при этом ничего. потом уже может и бессистемно потыкает куда-нибудь. Так вот, это все я называю кликанием. Объясните пожалуйста, что же еще есть помимо этого.

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

А до этого и спеки проревьюить надо бы.

ЗИГ>Причем даже этим эти т.н. QA занимаются из рук вон плохо. я в процессе разработки уже в существующем коде вижу места, где нас, разработчиков, можно подловить, — и иной раз штук по 5 в день благодаря мне тестеры заводят багов, — у них у самих так не получается, потому что они слепо тычутся по ui и внутрь не заглядывают. причем что обычные джуниоры что сениоры тестировщики. Вот вы, работаете с исходным кодом, скажите? И что именно вы делаете помимо того что я уже описала?

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

ЗИГ>нет, по-моему король абсолютно голый.

ЗИГ>>>а то у меня сложилось впечатление что ни один тестер не выходит дальше пределов "кликания",
M>>А у вас от тестеров ждут чего-то кроме кликанья? Бессистемное кликанье в данный момент более-менее применимо разве что в игроделе и то не факт, что всё совсем бессистемно. То есть, во-первых, кому-то надо бы эту систему выработать, определить метрики, определить задачи.
ЗИГ>блаблабла. Ну может быть, да — надо выработать систему чтоб поэффективнее проходил процесс кликания. Метрики — это типа если есть хоть один мажорный незакрытый баг, значит билд не качественный и нельзя выпускать в продакшн? Да, спору нет, гениальные метрики. Разработчики бы до таких не додумались. Не поймите мой сарказм превратно — метрика нормальная, только я до сих пор не вижу каких-то недоступных пониманию разработчика вещей, увы.

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

А как вы сможете определить ,что вы проверили всё, а если не всё, то определить, какую часть и выразить это в численном виде, например в процентном соотношении? Самое главное, как?

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

M>>Затем ,можно посмотреть в сторону автоматизации ряда процессов. А потом полученное решение прикрутить к автосборке.
ЗИГ>Ок, расскажите, как именно тестеры что-то автоматизируют без работы с исходным кодом?

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

ЗИГ>Крутить автосборкой опять же больших тестерских умений не надо — это и разработчики могли бы делать — тем более что там один раз настроил, и всё..

ЗИГ>>>но т.к. человека надо продвигать по службе, карьерный рост или хз что — то начинают навешивать ярлыки — Senior software testing engineer ..lead testing ... и соответствующие з/п сравнимые с разработческими.
ЗИГ>>>чем они там занимаются хз — но я внешних отличий не вижу. Расскажите ктонибудь, кто в курсе.
M>>Найдите вакансии тестировщиков зп сопоставимыми с разработчиками и там будут описаны требуемые навыки и выполняемые обязанности. Скорее всего вы увидите, что там кликерством не ограничиваются.
ЗИГ>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек?

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

ЗИГ>работа разработчика в разы сложнее!

Во сколько раз? И, пожалуйста, методику расчета.

А у вас в "Йоте" менеджеров из кого берут?

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

ЗИГ>Здравствуйте, rlabs, Вы писали:

R>>Здравствуйте, злая и глупая, Вы писали:

ЗИГ>>>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? работа разработчика в разы сложнее!

R>>Вот за то, что мы не увлекаемся такими обобщениями, нас и ценят.
ЗИГ>и опять красивые слова за которыми ничего нет.

за которыми ничего не видите вы.

N_>И как же это следует нука ципочку вывода плиз.
N_>Скорей наоборот, пм лучше проявляет себя в роле тестировщика, чем программисты.

Тут все просто — есть совместимые роли и не совместимые и не важно менеждер выполняет роль тестировщика или тестировщик роль менеджера.

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

Если выразиться по другому — у менеджера тестировщика и аналитика вид с птичьего полета Zoom x 100, они видят местность в общем, но не осязают деталей. У программиста наоборот вид с точки зрения суслика Zoom x 1, то есть он хорошо и детально видит свою область и решение проблем видит также с точки зрения этой локальной области.
Поэтому нельзя программисту поручать работы по тестированию, аналитике и управлению проектом. Он не сможет одновременно находится на Zoom x 100 и Zoom x1 чтобы качественно выполнять обе роли.
Роли тестировщик аналитик и менеджер проектов находятся примерно на одинаковом Zoom и они могут совмещаться , конечно же при наличии соответствующих компетенций.

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

O>в последнее время начал слышать подобные утверждения.
O>в большинстве случаев со стороны самих тестировщиков.

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

O>P.S.
O>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь.
O>спасиба.

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

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