в последнее время начал слышать подобные утверждения.
в большинстве случаев со стороны самих тестировщиков.
т.к. такие утвержедния регулярно слышу но не считаю их верными вообще, ... а также вижу случаИ когда бывшие тестры действительно менеджерят Девелоперов решил организовать так сказать опрос с мнениями почему утвержедние верно или не верно.
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>Вот за то, что мы не увлекаемся такими обобщениями, нас и ценят.
и опять красивые слова за которыми ничего нет.
Здравствуйте, злая и глупая: > А вот что такого сложного делают > тестеры помимо кликания чего не сможет девелопер??? ну приведите хоть > ктонибудь хоть один пример.
Проникающее тестирование (или как там оно называется, тестирование на
проникновение?).
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, oncer, Вы писали:
O>т.к. такие утвержедния регулярно слышу но не считаю их верными вообще, ... а также вижу случаИ когда бывшие тестры действительно менеджерят Девелоперов решил организовать так сказать опрос с мнениями почему утвержедние верно или не верно.
Тестировщикам часто приходится писать не код, поэтому, как правило, они немножко грамотнее
Тестировщикам чаще приходится врубаться в предметную область, поэтому им проще получить общую картинку
Хорошие тестировщики уважительно относятся и к разработчикам, и к заказчикам, не считая ни тех, ни других идиотами и бракоделами
Тестировщики больше работают с людьми, и легко осваивают боевое НЛП
Тестировщик делает свое дело и уходит в другой проект, так что имеет больше возможностей для широкого охвата технологий, процессов и команд
Многие тестировщики приходят в профессию не с программистских специальностей (см. "предметная область"), поэтому они не такие зануды
...
ну и так далее
При наличии способностей, менеджера можно сделать и из разработчика. Но его будет жалко.
Здравствуйте, злая и глупая, Вы писали:
ЗИГ>Здравствуйте, 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>спасиба.
"Проджект менеджер девелоперов" звучит почти как "пастух баранов". Когда ПМы управляют девелоперами, вместо того, чтобы управлять проектами, ничего хорошего не выходит в любом случае.
А кем ПМ был в прошлой жизни, в принципе, не важно, до тех пор пока понимает чем должен заниматься.
... ЗИГ>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? работа разработчика в разы сложнее!
Так речь не о сложности, а о ПМ-стве. Так как работа программиста сложнее, то сочетать ее с ПМ-ством сложнее. Особенно это проявляется при разработке сложных систем, где много различных расчетов, алгоритмов. Где нужно понимать какие данные можно давать на вход и какие при этом данные должны быть на выходе. Программист в таких сложных системах может отвечать и хорошо понимать только свой кусок подсистемы. Тестировщик же может понимать не только всю подсистему, которую тестирует, но так же немного и другие подсистемы, которые с ней взаимодействуют. Т.е. он может иметь более широкое понимание, как работает вся система. Следовательно перейти в ПМ-ы в таком случае ему будет проще.
Здравствуйте, sc, Вы писали:
sc>Здравствуйте, злая и глупая, Вы писали:
sc>... ЗИГ>>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? работа разработчика в разы сложнее!
sc>Так речь не о сложности, а о ПМ-стве. Так как работа программиста сложнее, то сочетать ее с ПМ-ством сложнее. Особенно это проявляется при разработке сложных систем, где много различных расчетов, алгоритмов. Где нужно понимать какие данные можно давать на вход и какие при этом данные должны быть на выходе. Программист в таких сложных системах может отвечать и хорошо понимать только свой кусок подсистемы. Тестировщик же может понимать не только всю подсистему, которую тестирует, но так же немного и другие подсистемы, которые с ней взаимодействуют. Т.е. он может иметь более широкое понимание, как работает вся система. Следовательно перейти в ПМ-ы в таком случае ему будет проще.
не согласна... это вы говорите о проекте у которого один тестировщик, — естественно он будет иметь понимание о системе в целом больше, чем разработчик который сидел только над каким-то ее куском... но если брать среднестатистического тестера котоырй тестит одну свою подсистему — то тут они будут равны, тлько разработчик будет еще и знать как оно все работает внутри, и какие есть невидимые связи с другими подсистемами о которых и не подозревает тестер, и которых часто нет в спеках..
Здравствуйте, Marduk, Вы писали:
M>>>Конечно видел, знаю. И мерзкую рожу одного из них я вижу каждый день в зеркале. ЗИГ>>отлично, т.е. сейчас я из первых уст узнаю наконец ваши секреты.. M>На самом деле мы сейчас сваливаемся в оффтоп. Тема изначально не про это.
меня задели слова о том, что разработчик якобы не сможет выполнять функции тестировщика.
M>Просто бытует мнение будто "слесари умеют выполнять работу плотников, а плотники работу слесарей — нет". С этим я не согласен. Это разные виды деятельности. Ничего более.
пусть разные, но разработчик мгновенно освоит работу тестировщика. другой вопрос — понравится ли ему в этом амплуа
M>А на деле вы видели, как делается нагрузочное тестирование, на основании чего оно делается? Или у вас в компании набирается толпа кликеров и они начинают одновременно работать на одном серваке, а кто-то стоит с секундомером и засекает время работы (видел как-то подобное душераздирающее зрелище)?
я не знаю, может у тестеров есть специальные тулзы для эмуляции одновременонй работы большого количества юзеров — но в реале и правда не видела чтоб тестеры умели или пользовались ими... причем вполне себе все seniorы и leadы. к тому же я сомневаюсь что этот софт сколь либо универсальный — все равно для конкретной задачи скорее всего придется написать своё что=то, с учетом специфики конкретных исходников — а значит это задача для разработчика, а не тестера
M>Как вы представляете себе тестирование сервисов, которые не имеют UI?
юниттесты?
ЗИГ>>человек тупо ходит по сайту (если у нас сайт), и начинает с того чтобы проверить — чтоб функционал весь соответствовал спецификации. ищет нестандартные места которые в спеке не описаны — не упадет ли при этом ничего. потом уже может и бессистемно потыкает куда-нибудь. Так вот, это все я называю кликанием. Объясните пожалуйста, что же еще есть помимо этого. M>Как минимум, есть набор сценариев, по которым это все проверяется. Их надо кому-то разработать, систематизировать. Также распределить, на каком этапе тестирования каждый из них будет задействован. А до этого, надо бы как-то выработать общий подход к тестированию, некую стратегию.
блаблабла. Мне тоже прежде чем садиться кодить надо вначале определить сценарии для работы, план (первым пунктом конечно должно идти 1. Составить план), каждый день эти сценарии актуализировать и не забывать об этом. Ну и конечно каждый день не забывать об общем подходе к разработке, некоей стратегии. И каждый день актуализировать и обновлять соответствующие документы. Дофига конечно работы. А главное производит массу впечатления что я делаю что-то серьезное, важное и полезное.
M>А до этого и спеки проревьюить надо бы.
О да. Офигеть как сложно и специфично, ведь девелоперы-то читать и вникать в текст не умеют, поэтому этим священнодействием могут заниматься только аналитики и тестеры.
ЗИГ>>Причем даже этим эти т.н. QA занимаются из рук вон плохо. я в процессе разработки уже в существующем коде вижу места, где нас, разработчиков, можно подловить, — и иной раз штук по 5 в день благодаря мне тестеры заводят багов, — у них у самих так не получается, потому что они слепо тычутся по ui и внутрь не заглядывают. причем что обычные джуниоры что сениоры тестировщики. Вот вы, работаете с исходным кодом, скажите? И что именно вы делаете помимо того что я уже описала? M>Самое забавное, что ничего из перечисленного вами выше, я не делаю. Зачем? За меня это делают машины. Вот вы как раз зря пропустили планирование, дизайн, реализацию тестирования, а сосредоточились на стадии выполнения. Это как раз самая непродолжительная по времени стадия.
машины за вас это делают.. расскажите как. Или это секрет?
M>А я уже вижу. Например, я о метриках сказал во множественном числе не просто так. Их много. Так, например, вы указали, что не должно быть ни одного критикал бага. Это что, значит, что пусть приложение кишит тучей мелких багов, но оно пригодно к использованию? С определенного момента — врядли. Далее, баги средней тяжести в единичном количестве еще терпимы, но имеет ли смысл пускать билд в продакшн, если плотность таких багов на компонент системы высока? То есть, должен быть некоторый предел. Ведь, если система не отваливается, но работает отвратительно, за такое никто денег не даст.
вы смеетесь что ли? я привела одну метрику (сама приудмала) только как пример, вы ждали я вам тут накатаю весь список который можно придумать?
M>А как вы сможете определить ,что вы проверили всё, а если не всё, то определить, какую часть и выразить это в численном виде, например в процентном соотношении? Самое главное, как?
ну в процентах от проверенного по спеке? у спеки есть разделы? вот может как-то так
M>Всё это очевидные вещи с того момента, когда о них узнаешь. Но их бы знать надо. Иначе, это то же самое, что программировать, не зная циклов ,операторов ветвления или методов/функций. В принципе, можно, но в ряде задач получится что-то страшное.
очевидные вещи любому разработчику и все о них знают, ибо и сами работают с этими тестерами и этих "премудростей" набраться нетрудно
M>>>Затем ,можно посмотреть в сторону автоматизации ряда процессов. А потом полученное решение прикрутить к автосборке. ЗИГ>>Ок, расскажите, как именно тестеры что-то автоматизируют без работы с исходным кодом? M>Вы слышали что-то типа "автоматизированное тестирование" и каким оно бывает? Юнит-тесты — это только одно из под-множеств. M>И в ряде случаев, взаимодействие с системой происходит извне тестируемой системы. Более того, как только работа с тестируемой системой выходит за пределы исходного кода, тут уже работают не девелоперы. И не факт, что это еще уровень UI.
да у нас было система автотестинга, но тесты для нее писали разработчики тестер только запускал ее, следил за результатами выполнения и сигнализировал если что-то его не устраивало.
А еще у нас была система которая раз от разу меряла время выполнения неких длительных операций (в своем роде нагрузочное тестирование), — и потом проводилось сравнение по билдам — что где мы улучшили, или где сломали — в плане производительности. Стоит ли говорить, что и эти тесты тоже были написаны разработчиками, потому что тестеры в искходном коде обычно ни в зуб ногой?
ЗИГ>>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? M>Помимо этого еще требуется обычно понимание тех или иных технологий, некоторый уровень знаний тех или иных языков программирования, опыт работы с определенными системами (в частности, для автотестинга, а их полно всяких разных).
требуется,требуется, требуется.. но на деле не применяется. а если применяется — то с тем же успехом работать с этими уже готовыми системами может и разработчик. а вот свою, с учетом специфики проекта тестер написать уже не сможет.
ЗИГ>>работа разработчика в разы сложнее! M>Во сколько раз? И, пожалуйста, методику расчета.
во много
множество функций которые может выполнять девелопер содержит в себе полностью подмножество функций выполняемых тестировщиками, но не наоборот
вот отсюда и пляшите
Здравствуйте, fdee, Вы писали:
F>Если выразиться по другому — у менеджера тестировщика и аналитика вид с птичьего полета Zoom x 100, они видят местность в общем, но не осязают деталей. У программиста наоборот вид с точки зрения суслика Zoom x 1, то есть он хорошо и детально видит свою область и решение проблем видит также с точки зрения этой локальной области. F>Поэтому нельзя программисту поручать работы по тестированию, аналитике и управлению проектом. Он не сможет одновременно находится на Zoom x 100 и Zoom x1 чтобы качественно выполнять обе роли. F>Роли тестировщик аналитик и менеджер проектов находятся примерно на одинаковом Zoom и они могут совмещаться , конечно же при наличии соответствующих компетенций.
какие-то не убедительныве доводы притянутые за уши.
вы Тестер ?
а как же Абстрагирование, Разбиение на Компоненты, Инкапсуляция — все подходы позволяют просто переключаться с Zoom x 1 на Zoom x 100. — Без проблемм.
21.05.2010 1:45, Marduk пишет: > > ЗИГ>и опять красивые слова за которыми ничего нет. > > за которыми ничего не видите вы.
Я тоже не вижу. Так что уже два слепых.
З.Ы. Боюсь, что если начать нас слепых считать, то зрячими только
тестеры и останутся.
Здравствуйте, злая и глупая, Вы писали:
... sc>>Так речь не о сложности, а о ПМ-стве. Так как работа программиста сложнее, то сочетать ее с ПМ-ством сложнее. Особенно это проявляется при разработке сложных систем, где много различных расчетов, алгоритмов. Где нужно понимать какие данные можно давать на вход и какие при этом данные должны быть на выходе. Программист в таких сложных системах может отвечать и хорошо понимать только свой кусок подсистемы. Тестировщик же может понимать не только всю подсистему, которую тестирует, но так же немного и другие подсистемы, которые с ней взаимодействуют. Т.е. он может иметь более широкое понимание, как работает вся система. Следовательно перейти в ПМ-ы в таком случае ему будет проще.
ЗИГ>не согласна... это вы говорите о проекте у которого один тестировщик, — естественно он будет иметь понимание о системе в целом больше, чем разработчик который сидел только над каким-то ее куском... но если брать среднестатистического тестера котоырй тестит одну свою подсистему — то тут они будут равны, тлько разработчик будет еще и знать как оно все работает внутри, и какие есть невидимые связи с другими подсистемами о которых и не подозревает тестер, и которых часто нет в спеках..
ПМ может спросить у программиста про невидимые связи Если связи действительно сложные, то с прогнозированием сроков конечно будут проблемы, по крайней мере вначале. Но а с другой строны, зачем программисту в ПМ-ы? Работа с бумажками, весьма скучная. Если хочется поруководить, то лучше сначала стать руководит. группы (тим лидом), затем сектора, бюро, отдела. Здесь работа с людьми, как правило интереснее.
Здравствуйте, злая и глупая, Вы писали: ЗИГ>я не знаю, может у тестеров есть специальные тулзы для эмуляции одновременонй работы большого количества юзеров — но в реале и правда не видела чтоб тестеры умели или пользовались ими... причем вполне себе все seniorы и leadы. к тому же я сомневаюсь что этот софт сколь либо универсальный — все равно для конкретной задачи скорее всего придется написать своё что=то, с учетом специфики конкретных исходников — а значит это задача для разработчика, а не тестера ЗИГ>да у нас было система автотестинга, но тесты для нее писали разработчики тестер только запускал ее, следил за результатами выполнения и сигнализировал если что-то его не устраивало. ЗИГ>А еще у нас была система которая раз от разу меряла время выполнения неких длительных операций (в своем роде нагрузочное тестирование), — и потом проводилось сравнение по билдам — что где мы улучшили, или где сломали — в плане производительности. Стоит ли говорить, что и эти тесты тоже были написаны разработчиками, потому что тестеры в искходном коде обычно ни в зуб ногой?
У вас разработчики делают работу тестеров. Отсюда и неправильные выводы.
Здравствуйте, oncer, Вы писали:
O>Здравствуйте, fdee, Вы писали:
F>>Если выразиться по другому — у менеджера тестировщика и аналитика вид с птичьего полета Zoom x 100, они видят местность в общем, но не осязают деталей. У программиста наоборот вид с точки зрения суслика Zoom x 1, то есть он хорошо и детально видит свою область и решение проблем видит также с точки зрения этой локальной области. F>>Поэтому нельзя программисту поручать работы по тестированию, аналитике и управлению проектом. Он не сможет одновременно находится на Zoom x 100 и Zoom x1 чтобы качественно выполнять обе роли. F>>Роли тестировщик аналитик и менеджер проектов находятся примерно на одинаковом Zoom и они могут совмещаться , конечно же при наличии соответствующих компетенций.
O>какие-то не убедительныве доводы притянутые за уши. O>вы Тестер ? O>а как же Абстрагирование, Разбиение на Компоненты, Инкапсуляция — все подходы позволяют просто переключаться с Zoom x 1 на Zoom x 100. — Без проблемм.
Вот сейчас вы как раз говорите с точки зрения "человека" он говорит как же так..ведь я вижу яму, траву( Zoomx2 инкапсуляция ), вижу деревья ( Zoomx10 компоненты ).
А "птица" говорит, а я нифига не вижу деревья, я вижу 3 лесопосадки, 2 озера, 4 холма.
Попробуйте кстати потестировать свою программу и потом дайте ее другому человеку далекому от программирования ( пользователю ) сравните результаты вашего тестирование и его. Это будут ответы из разных плоскостей, с разных точек зрения. То что вам будет казаться очень важным, пользователю не обязательно будет важно. В этом и проблема "пользователей и программистов" они по разному воспринимают продукт. Пример Linux vs Windows, Linux воспринимается программистами лучше чем конечными пользователями, но Linux занимает очень малую долю по сравнению с Linux на рынке обычных домохозяек. Не потому что что-то плохое , а что-то очень хорошее , а потому что разные потребности и разное восприятие.
Абстрагирование и разбиение на компоненты это не Zoomx100, для тестировщика и менеджера и аналитика видимыми могут быть дай бог бы компоненты да и то зачастую продукт ими воспринимается как некий монолит с функциональными свойствами и даже детализация на уровне компонент ими может не восприниматься.
Например я пользователь Windows и я практически не воспринимаю его на уровне компонент программиста, для меня конкретная dll-ка ни о чем не говорит. Воспринимать я начинаю на уровне приложения "проводник", "калькулятор", "интернет эксплорер" и т.п.
Здравствуйте, bystander, Вы писали:
B>Здравствуйте, злая и глупая, Вы писали: ЗИГ>>я не знаю, может у тестеров есть специальные тулзы для эмуляции одновременонй работы большого количества юзеров — но в реале и правда не видела чтоб тестеры умели или пользовались ими... причем вполне себе все seniorы и leadы. к тому же я сомневаюсь что этот софт сколь либо универсальный — все равно для конкретной задачи скорее всего придется написать своё что=то, с учетом специфики конкретных исходников — а значит это задача для разработчика, а не тестера ЗИГ>>да у нас было система автотестинга, но тесты для нее писали разработчики тестер только запускал ее, следил за результатами выполнения и сигнализировал если что-то его не устраивало. ЗИГ>>А еще у нас была система которая раз от разу меряла время выполнения неких длительных операций (в своем роде нагрузочное тестирование), — и потом проводилось сравнение по билдам — что где мы улучшили, или где сломали — в плане производительности. Стоит ли говорить, что и эти тесты тоже были написаны разработчиками, потому что тестеры в искходном коде обычно ни в зуб ногой?
B>У вас разработчики делают работу тестеров. Отсюда и неправильные выводы.
да я с самого начала вам об этом толкую. Что разработчики отлично могут выполнять работу тестеров. А наоборот — нифига. Они как видно из опыта и со своей-то не справляются.
а главное я себе плохо представляю тестера который бы писал юниттесы или эту нашу система автотестирования.. это ведь не готовый софт. Там кодить надо было. Если тестер умеет кодить — то какой же это тестер? я считаю это полноценный разработчик уже, просто область применения специфическая — связанная с тестированием... так вот, речь щас не о таких людях. Речь о тестерах которые ничего не кодят а только кликают-кликают-кликают, пишут многословные документы, запускают/настраивают уже кем-то написанный софт и всё.
... F>Абстрагирование и разбиение на компоненты это не Zoomx100, для тестировщика и менеджера и аналитика видимыми могут быть дай бог бы компоненты да и то зачастую продукт ими воспринимается как некий монолит с функциональными свойствами и даже детализация на уровне компонент ими может не восприниматься. F>Например я пользователь Windows и я практически не воспринимаю его на уровне компонент программиста, для меня конкретная dll-ка ни о чем не говорит. Воспринимать я начинаю на уровне приложения "проводник", "калькулятор", "интернет эксплорер" и т.п.
Это восприятие на уровне пользователя. А ПМ-у важно знать разбиение системы на модули и какой программист за какой модуль отвечает. Иначе придется каждый раз при планировании сроков/ресурсов обращаться за помощью к руководит. программистов. Бизнес-аналитик не обязан знать детали, но системному аналитику знать это важно, иначе программистам придется доаналичивать а то и вообще переаналичивать в процессе работы Тестировщику тоже знать желательно, чтобы создавать баг уже на конкретный модуль, на конкретного исполнителя (либо указывать в каком модуле баг). Все эти знания облегчают и ускоряют работу.
21.05.2010 12:26, злая и глупая пишет: > > о тестерах которые ничего не кодят а только кликают-кликают-кликают, > пишут многословные документы, запускают/настраивают уже кем-то > написанный софт и всё.
И даже название этому есть "малпингтестинг". А работников сего труда
называю "малпачками".
Здравствуйте, Demotivated, Вы писали:
D>Девелопер привык смотреть предвзято, смотреть на чужой код со своей колокольни, "я бы сделал по-другому", "что это за говнокод такой", "хочешь сделать что-то хорошо — сделай это сам" и т.п. Неизбежно возникновение отношения в стиле "я начальник — ты дурак"
Имхо программист с опытом перестаёт считать любой чужой код говнокодом. "Я начальник — ты дурак" случается если пм-ом становится неопытный разработчик.
Здравствуйте, sc, Вы писали:
sc>Здравствуйте, fdee, Вы писали:
sc>... F>>Абстрагирование и разбиение на компоненты это не Zoomx100, для тестировщика и менеджера и аналитика видимыми могут быть дай бог бы компоненты да и то зачастую продукт ими воспринимается как некий монолит с функциональными свойствами и даже детализация на уровне компонент ими может не восприниматься. F>>Например я пользователь Windows и я практически не воспринимаю его на уровне компонент программиста, для меня конкретная dll-ка ни о чем не говорит. Воспринимать я начинаю на уровне приложения "проводник", "калькулятор", "интернет эксплорер" и т.п.
sc>Это восприятие на уровне пользователя. А ПМ-у важно знать разбиение системы на модули и какой программист за какой модуль отвечает. Иначе придется каждый раз при планировании сроков/ресурсов обращаться за помощью к руководит. программистов. Бизнес-аналитик не обязан знать детали, но системному аналитику знать это важно, иначе программистам придется доаналичивать а то и вообще переаналичивать в процессе работы Тестировщику тоже знать желательно, чтобы создавать баг уже на конкретный модуль, на конкретного исполнителя (либо указывать в каком модуле баг). Все эти знания облегчают и ускоряют работу.
Да это хорошо когда все всё знают, но это не возможно. Тестировщику проще баг назначить архитектору, а архитектор или ведущий программист намного лучше тестировщика разберется в чьей области произошел косяк и кому конкретно поручить баг.
ПМу разбиение на модули не нужно, он не может погружаться в такие детали, естественно при планировании сроков ресурсов ПМ согласовывает их и собирает со всех участников проекта, отдела тестирования, аналитики и в том числе по разработке он получает сроки от архитектора ( архитектор это в рамках аналогий которые я приводил это человек сидящий на дереве и видящий макушки деревьев ), и сколько модулей должно быть решает архитектор, а не ПМ. А также кто каким модулем занимается ПМ знать может, но это опять же не в его области компетенции, в зависимости от технических особенностей конкретной реализации отвественный разработчик за модуль может поменятся. При нормальном процессе ПМ просто получает от архитектора или ведущего программиста список задач, их трудоемкость и кто из исполнителей их выполняет. Часто также для управления удобнее задачи вешать на ответственного исполнителя, это может быть как человек ответственный за группу программистов, так и отдельная компания. Напимер разработу модуля А вы решили поручить не местым кодером а заказать у сторонней компании, тогда вы просто планируете задачу без детализации кто и как в этой компании ее будет делать. Точно также в местных условиях не всегда нужно знать конкретных исполниетелей особенно в большой компании, достаточно повестить задачу на отдел и спрашивать с отвественного за отдел.
ЗИГ>вот знаете, если отбросить все умные слова, лишнюю воду из ваших слов, — мне все равно продолжает оставаться неясным — что же именно вы все-таки каждый день делаете? видов тестирования много.... — это на словах так, а на деле — человек тупо ходит по сайту (если у нас сайт), и начинает с того чтобы проверить — чтоб функционал весь соответствовал спецификации. ищет нестандартные места которые в спеке не описаны — не упадет ли при этом ничего. потом уже может и бессистемно потыкает куда-нибудь. Так вот, это все я называю кликанием. Объясните пожалуйста, что же еще есть помимо этого.
Работа разработчика сводится к написанию слов при помощи клавиатуры (и это в лучшем случае, а то и мышкой кнопочек натаскать).
Дело в том что правильный тестер должен знать спецификации не хуже (а то и лучше разработчика). Разработчику достаточно знать свой кусок, а тестер должен представлять как взаимодействуют между собой разные подсистемы.
ЗИГ>Причем даже этим эти т.н. QA занимаются из рук вон плохо. я в процессе разработки уже в существующем коде вижу места, где нас, разработчиков, можно подловить, — и иной раз штук по 5 в день благодаря мне тестеры заводят багов, — у них у самих так не получается, потому что они слепо тычутся по ui и внутрь не заглядывают. причем что обычные джуниоры что сениоры тестировщики. Вот вы, работаете с исходным кодом, скажите? И что именно вы делаете помимо того что я уже описала?
То что какие-то тестеры работают плохо ни о чем не говорит. Вот ваши тестеры багов совсем не находят?
а если находят, то какк-же так получается что значительно более компетентный девелопер их пропустил?
ЗИГ>блаблабла. Ну может быть, да — надо выработать систему чтоб поэффективнее проходил процесс кликания. Метрики — это типа если есть хоть один мажорный незакрытый баг, значит билд не качественный и нельзя выпускать в продакшн? Да, спору нет, гениальные метрики. Разработчики бы до таких не додумались. Не поймите мой сарказм превратно — метрика нормальная, только я до сих пор не вижу каких-то недоступных пониманию разработчика вещей, увы.
если провести аналогию с програмированием то "выбор системы по эффективнее" можно сравнить с разработкой архитектуры. Или вы считаете что это тоже ненужная ерунда?
ЗИГ>Ок, расскажите, как именно тестеры что-то автоматизируют без работы с исходным кодом?
ну отвлекаясь от сути дисскуссии скажу вам что таки существует автоматизированное тестирование UI.
там люди пишут код, код это в конечном итоге эмулирует работу пользователя. но относится все это обычно к отделу QA
ЗИГ>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? работа разработчика в разы сложнее!
насчет проще/сложнее ничего не могу сказать, никогда тестером не работал. вы видимо работали и знаете.
Зато вот насчет здравомыслящего человека скажу. в работе разработчика нет ничего такого что "не мог выполнить просто обычный здравомыслящий человек"
Здравствуйте, Vzhyk, Вы писали:
V>21.05.2010 1:45, Marduk пишет: >> >> ЗИГ>и опять красивые слова за которыми ничего нет. >> >> за которыми ничего не видите вы. V>Я тоже не вижу. Так что уже два слепых. V>З.Ы. Боюсь, что если начать нас слепых считать, то зрячими только V>тестеры и останутся.
Здравствуйте, злая и глупая, Вы писали:
ЗИГ>Здравствуйте, Marduk, Вы писали:
M>>>>Конечно видел, знаю. И мерзкую рожу одного из них я вижу каждый день в зеркале. ЗИГ>>>отлично, т.е. сейчас я из первых уст узнаю наконец ваши секреты.. M>>На самом деле мы сейчас сваливаемся в оффтоп. Тема изначально не про это. ЗИГ>меня задели слова о том, что разработчик якобы не сможет выполнять функции тестировщика.
Учитывая трудности понимания самой роли тестировщика, о полновесном выполнении данных функций не может быть и речи.
M>>Просто бытует мнение будто "слесари умеют выполнять работу плотников, а плотники работу слесарей — нет". С этим я не согласен. Это разные виды деятельности. Ничего более. ЗИГ>пусть разные, но разработчик мгновенно освоит работу тестировщика. другой вопрос — понравится ли ему в этом амплуа
А вот с "мгновенно" я не согласен. Во-первых, потому, что для тестирования нужен взгляд на систему извне, в то время, как разработчик видит это изнутри. Во-вторых, детали, на которые обращает внимание разработчик, несколько отличаются от деталей, на которые обращает внимание тестировщик.
M>>А на деле вы видели, как делается нагрузочное тестирование, на основании чего оно делается? Или у вас в компании набирается толпа кликеров и они начинают одновременно работать на одном серваке, а кто-то стоит с секундомером и засекает время работы (видел как-то подобное душераздирающее зрелище)? ЗИГ>я не знаю, может у тестеров есть специальные тулзы для эмуляции одновременонй работы большого количества юзеров — но в реале и правда не видела чтоб тестеры умели или пользовались ими... причем вполне себе все seniorы и leadы.
Похоже вы и тестеров-то не видели в принципе.
ЗИГ>к тому же я сомневаюсь что этот софт сколь либо универсальный — все равно для конкретной задачи скорее всего придется написать своё что=то, с учетом специфики конкретных исходников — а значит это задача для разработчика, а не тестера
Да ну? Обычно софт выполняет задачи общего назначения, типа послать запрос, считать данные и т.п. Для конкретных задач надо только создавать тесты, возможно движок + библиотеку вспомогательных функций. Причем, зачастую может оказаться, что это делается с использованием даже других языков программирования, отличных от используемых для разработки приложения. И на подобные задачи врядли привлекают разработчиков. Разве что если их девать больше некуда. Как правило, для этого есть отдельная группа автоматизаторов.
M>>Как вы представляете себе тестирование сервисов, которые не имеют UI? ЗИГ>юниттесты?
Юнит-тесты, конечно, немного для другого, но в ряде случаев структура тестов и принцип построения схожий.
ЗИГ>>>человек тупо ходит по сайту (если у нас сайт), и начинает с того чтобы проверить — чтоб функционал весь соответствовал спецификации. ищет нестандартные места которые в спеке не описаны — не упадет ли при этом ничего. потом уже может и бессистемно потыкает куда-нибудь. Так вот, это все я называю кликанием. Объясните пожалуйста, что же еще есть помимо этого. M>>Как минимум, есть набор сценариев, по которым это все проверяется. Их надо кому-то разработать, систематизировать. Также распределить, на каком этапе тестирования каждый из них будет задействован. А до этого, надо бы как-то выработать общий подход к тестированию, некую стратегию. ЗИГ>блаблабла. Мне тоже прежде чем садиться кодить надо вначале определить сценарии для работы, план (первым пунктом конечно должно идти 1. Составить план), каждый день эти сценарии актуализировать и не забывать об этом.
Только это другие сценарии. Это сценарии, по которым система будет проверяться на работоспособность. Я вам уже указывал на типы тестирования — вы это пропустили мимо ушей (глаз).
ЗИГ>Ну и конечно каждый день не забывать об общем подходе к разработке, некоей стратегии.
Вы не поняли. Для тестирования её тоже надо выработать. И стратегия тестирования вообще-то отличается от стратегии разработки.
ЗИГ>И каждый день актуализировать и обновлять соответствующие документы. Дофига конечно работы. А главное производит массу впечатления что я делаю что-то серьезное, важное и полезное.
Если вы не заметили, то те же тестовые сценарии, которые по идее должны разрабатывать тестировщики — для тестирования это как бы такие же исходники, только это исходники не разрабатываемой системы, а тестирования.
M>>А до этого и спеки проревьюить надо бы. ЗИГ>О да. Офигеть как сложно и специфично, ведь девелоперы-то читать и вникать в текст не умеют, поэтому этим священнодействием могут заниматься только аналитики и тестеры.
Я вам описал набор активностей тестировщика, причем именно в контексте тестирования, так как прежде чем браться за разработку тестов, нужно хотя бы убедиться, что исходные требования пригодны для использования в качестве основы.
ЗИГ>>>Причем даже этим эти т.н. QA занимаются из рук вон плохо. я в процессе разработки уже в существующем коде вижу места, где нас, разработчиков, можно подловить, — и иной раз штук по 5 в день благодаря мне тестеры заводят багов, — у них у самих так не получается, потому что они слепо тычутся по ui и внутрь не заглядывают. причем что обычные джуниоры что сениоры тестировщики. Вот вы, работаете с исходным кодом, скажите? И что именно вы делаете помимо того что я уже описала? M>>Самое забавное, что ничего из перечисленного вами выше, я не делаю. Зачем? За меня это делают машины. Вот вы как раз зря пропустили планирование, дизайн, реализацию тестирования, а сосредоточились на стадии выполнения. Это как раз самая непродолжительная по времени стадия. ЗИГ>машины за вас это делают.. расскажите как. Или это секрет?
Как как? Нажал на кнопку и машина пошла "отжиматься". Если совсем лень, то и кнопку нажимать не надо. Поставил автосборщик на запуск по расписанию — и всё.
M>>А я уже вижу. Например, я о метриках сказал во множественном числе не просто так. Их много. Так, например, вы указали, что не должно быть ни одного критикал бага. Это что, значит, что пусть приложение кишит тучей мелких багов, но оно пригодно к использованию? С определенного момента — врядли. Далее, баги средней тяжести в единичном количестве еще терпимы, но имеет ли смысл пускать билд в продакшн, если плотность таких багов на компонент системы высока? То есть, должен быть некоторый предел. Ведь, если система не отваливается, но работает отвратительно, за такое никто денег не даст. ЗИГ>вы смеетесь что ли? я привела одну метрику (сама приудмала) только как пример, вы ждали я вам тут накатаю весь список который можно придумать?
Вы и метрику не назвали. А ряд из них надо бы знать, так как они позволяют более-менее четко оценить, на какой стадии сейчас тестирование сейчас, куда двигаться дальше и т.п. Кстати, на вопросе о метриках достаточно много кандидатов на собеседовании плывет.
M>>А как вы сможете определить ,что вы проверили всё, а если не всё, то определить, какую часть и выразить это в численном виде, например в процентном соотношении? Самое главное, как? ЗИГ>ну в процентах от проверенного по спеке? у спеки есть разделы? вот может как-то так
Вот всё "где-то там" и "как-то так" — это для поставленного процесса как-то недостаточно. Вы и разрабатываете "как-то так" и что-то "где-то там"?
M>>Всё это очевидные вещи с того момента, когда о них узнаешь. Но их бы знать надо. Иначе, это то же самое, что программировать, не зная циклов ,операторов ветвления или методов/функций. В принципе, можно, но в ряде задач получится что-то страшное. ЗИГ>очевидные вещи любому разработчику и все о них знают, ибо и сами работают с этими тестерами и этих "премудростей" набраться нетрудно
Только практика показывает, что знать-то знают, а вот с применением косяки. Основная проблема — концентрация на деталях.
M>>>>Затем ,можно посмотреть в сторону автоматизации ряда процессов. А потом полученное решение прикрутить к автосборке. ЗИГ>>>Ок, расскажите, как именно тестеры что-то автоматизируют без работы с исходным кодом? M>>Вы слышали что-то типа "автоматизированное тестирование" и каким оно бывает? Юнит-тесты — это только одно из под-множеств. M>>И в ряде случаев, взаимодействие с системой происходит извне тестируемой системы. Более того, как только работа с тестируемой системой выходит за пределы исходного кода, тут уже работают не девелоперы. И не факт, что это еще уровень UI. ЗИГ>да у нас было система автотестинга, но тесты для нее писали разработчики тестер только запускал ее, следил за результатами выполнения и сигнализировал если что-то его не устраивало. ЗИГ>А еще у нас была система которая раз от разу меряла время выполнения неких длительных операций (в своем роде нагрузочное тестирование), — и потом проводилось сравнение по билдам — что где мы улучшили, или где сломали — в плане производительности. Стоит ли говорить, что и эти тесты тоже были написаны разработчиками, потому что тестеры в искходном коде обычно ни в зуб ногой?
ЗИГ>>>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? M>>Помимо этого еще требуется обычно понимание тех или иных технологий, некоторый уровень знаний тех или иных языков программирования, опыт работы с определенными системами (в частности, для автотестинга, а их полно всяких разных). ЗИГ>требуется,требуется, требуется.. но на деле не применяется. а если применяется — то с тем же успехом работать с этими уже готовыми системами может и разработчик.
Это где не применяется? Вакансии обычно указывают, что должен знать кандидат, не от нечего делать. Наверное, от него ждут и умение этим всем пользоваться.
ЗИГ>а вот свою, с учетом специфики проекта тестер написать уже не сможет.
И разработчик тоже врядли осилит, особенно системы, о которых я говорил.
ЗИГ>>>работа разработчика в разы сложнее! M>>Во сколько раз? И, пожалуйста, методику расчета. ЗИГ>во много ЗИГ>множество функций которые может выполнять девелопер содержит в себе полностью подмножество функций выполняемых тестировщиками, но не наоборот
У разработчика изначально набор функций отличен от тестировщика иначе у вас там с процессами непонятно что творится.
Они делают разную работу. И как показывает практика, у девелоперов с реализацией того или иного решения по тестированию еще дела идут неплохо, а вот с покрытием различными верификациями зачастую проблемы, связанные с отсутствием системности.
Так что, что там у разработчика может быть в разы сложнее?
Здравствуйте, злая и глупая, Вы писали:
ЗИГ>Здравствуйте, bystander, Вы писали:
B>>Здравствуйте, злая и глупая, Вы писали: ЗИГ>>>я не знаю, может у тестеров есть специальные тулзы для эмуляции одновременонй работы большого количества юзеров — но в реале и правда не видела чтоб тестеры умели или пользовались ими... причем вполне себе все seniorы и leadы. к тому же я сомневаюсь что этот софт сколь либо универсальный — все равно для конкретной задачи скорее всего придется написать своё что=то, с учетом специфики конкретных исходников — а значит это задача для разработчика, а не тестера ЗИГ>>>да у нас было система автотестинга, но тесты для нее писали разработчики тестер только запускал ее, следил за результатами выполнения и сигнализировал если что-то его не устраивало. ЗИГ>>>А еще у нас была система которая раз от разу меряла время выполнения неких длительных операций (в своем роде нагрузочное тестирование), — и потом проводилось сравнение по билдам — что где мы улучшили, или где сломали — в плане производительности. Стоит ли говорить, что и эти тесты тоже были написаны разработчиками, потому что тестеры в искходном коде обычно ни в зуб ногой?
B>>У вас разработчики делают работу тестеров. Отсюда и неправильные выводы. ЗИГ>да я с самого начала вам об этом толкую. Что разработчики отлично могут выполнять работу тестеров. А наоборот — нифига. Они как видно из опыта и со своей-то не справляются. ЗИГ>а главное я себе плохо представляю тестера который бы писал юниттесы или эту нашу система автотестирования.. это ведь не готовый софт. Там кодить надо было. Если тестер умеет кодить — то какой же это тестер? я считаю это полноценный разработчик уже, просто область применения специфическая — связанная с тестированием... так вот, речь щас не о таких людях. Речь о тестерах которые ничего не кодят а только кликают-кликают-кликают, пишут многословные документы, запускают/настраивают уже кем-то написанный софт и всё.
Нет уж, если мы говорим о тестерах, то о тех, кто свою роль выполняет в полной мере. А там и чего-то кодить надо бы, и при необходимлсти свою систему сделать, а это помимо этого таких активностей, как постановка процесса тестирования и у превление им.
А то вы описываете кликеров, при этом удивляетесь, как так получается, что тестерам иногда предлагают зарплаты, сопоставимые с девелоперскими. Так что, если сравнивать возможности/способности, то с теми, у кого они есть.
Здравствуйте, злая и глупая, Вы писали:
ЗИГ>а скажите, вы видели хоть одного такого тестера который бы не кликал по кнопкам? чем же они тогда занимаются?
У нас тестировщики перед тем как приступить к тестированию собирают сложные стенды из разнообразного оборудования, в работе с которым нужно проверить ПО. Как самый простой пример оборудования, который нужно настроить и подключить — промышленый электрический счетчик. ЗИГ>А вот что такого сложного делают тестеры помимо кликания чего не сможет девелопер??? ну приведите хоть ктонибудь хоть один пример.
Ну вот разработчики у нас не все смогут подключить, тот же электрический счетчик. Я вот не смогу... ЗИГ>а то у меня сложилось впечатление что ни один тестер не выходит дальше пределов "кликания", но т.к. человека надо продвигать по службе, карьерный рост или хз что — то начинают навешивать ярлыки — Senior software testing engineer ..lead testing ... и соответствующие з/п сравнимые с разработческими.
Если у вас это просто ярлыки, то это плохо. По хорошему это свидетельство того, что человек на деле доказал, что он не дурак.
Тут на самом деле не важно кем человека взяли на работу тестировщиком или программистом, или вообще грузчиком. Это все второстепенное, главное что у человека в голове. Если он дурак, то от того что его взяли программистом он умнее не станет. Будет у человека голова на месте, будут способности к руководству, то у ПМ он будет хорошим, если дорастет.
Про грузчика: на моей предыдущей работе генеральным директором и основателем был мужик, который начинал с грузчика в крупной компании, из грузчика его сделали зав. складом, потом менеджером по логистике, затем начальником отдела по логистике в этом городе, затем он ушел в другую компанию начальником отдела выгоных грузоперевозок уже по всей России, а в итоге основал свою компанию. Если следовать вашей логике, то он должен был так и остаться грузчиком, потому что работа не фига не способствующая уственному развитию.
Главное что в голове, а не то что на бейджике.
21.05.2010 17:39, cvetkov пишет: > > Q>Как вообще можно разрабатывать не врубаясь в предметную область?? > легко. нужна хорошая спека
Ты ошибаешься, она тоже часто не нужна.
Здравствуйте, Qwazar, Вы писали:
Q>Здравствуйте, Demotivated, Вы писали:
D>>Девелопер привык смотреть предвзято, смотреть на чужой код со своей колокольни, "я бы сделал по-другому", "что это за говнокод такой", "хочешь сделать что-то хорошо — сделай это сам" и т.п. Неизбежно возникновение отношения в стиле "я начальник — ты дурак"
Q>Имхо программист с опытом перестаёт считать любой чужой код говнокодом. "Я начальник — ты дурак" случается если пм-ом становится неопытный разработчик.
А Вы представьте себя в роли такого ПМ.
Вот, предположим, вас только что назначили манагером на небольшой проект, в подчинении несколько девелоперов и тестеров.
Первым делом кидаешься управлять девелоперами.
Им давно не повышали ЗП, думают больше о том, как побыстрее свалить домой, о предстоящем собеседовании в другой конторе, и тп, энтузиазма ноль.
А тебя наоборот, повысили в должности, существенная прибавка к зарплате, глаза горят от энтузиазма, да и просто опытнее их.
Видишь, что сам можешь сделать и быстрее и качественнее, чем все твои девелоперы вместе взятые.
Начинаешь их подгонять, пытаться заразить энтузиазмом, никакого толку.
Включаешься сам в разработку, берешь самое важное на себя, остальным демонстративно поручаешь самое несложное и рутинное.
В итоге получили старшего разработчика, а роль ПМ-а придется брать на себя кому-то другому, например самому инициативному из тестеров
Здравствуйте, злая и глупая, Вы писали:
ЗИГ>а скажите, вы видели хоть одного такого тестера который бы не кликал по кнопкам? чем же они тогда занимаются?
Ну в общем все верно.
Девелоперы тоже в общем тоже только по кнопкам кликают и мышой по столу елозят.
На каком-то уровне абстракции вообще все едино
Здравствуйте, fdee, Вы писали:
F>Поэтому нельзя программисту поручать работы по тестированию, аналитике и управлению проектом.
Не совсем так. Нельзя поручать тестировать тот функционал, который он делал. Неосознанно пытаешься тестировать только то, что хорошо сделано и обходить плохое.
Я работал в команде, в которой не было тестировщиков вообще. Программисты сами тестировали чужой функионал. Получалось отлично.
По моим наблюдениям все просто. И причина одна.
В некоторых областях знаний просто некуда развиваться кроме как в "начальники".
Применительно к топику это, например, тестирование софта, системная интеграция. Наверное, еще что-то.
Там горизонтальное развитие сильно ограничено, потому приходится расти вверх.
А программист пока всю хрень изучит, системы там, архитектуры постигнет в глубину — уже им тестер из соседнего отдела будет командовать, который уделил время развитию менеджерских навыков.
Т.к. тестерские навыки развиваются по самое немогу за первые год-два работы.
Что такое программер с годом-двумя опыта, надеюсь, понятно.
В смысле, что точно есть еще куда расти
Здравствуйте, oncer, Вы писали:
O>в последнее время начал слышать подобные утверждения. O>в большинстве случаев со стороны самих тестировщиков.
O>т.к. такие утвержедния регулярно слышу но не считаю их верными вообще, ... а также вижу случаИ когда бывшие тестры действительно менеджерят Девелоперов решил организовать так сказать опрос с мнениями почему утвержедние верно или не верно.
O>P.S. O>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь. O>спасиба.
Здравствуйте, oncer, Вы писали:
O>P.S. O>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь. O>спасиба.
В буквальном смысле ваш вопрос, по существу, абсурден. Так как вы предлагаете сравнивать инженера по качеству и инженер-разработчика. По каким критериям вы будете их сравнивать? По личным качествам? Так это индивидуально и вовсе не привязано к профессии.
Хотя, если вопрос родился, то я, если позволите, перефразирую его так: "Почему, субъективно, в ПМ берут больше из тестеров нежели из программистов?" Ок, я не буду утруждать себя (к сожалению) и доказывать очевидную разницу между первыми и вторыми, т.е. буквально разницу с институтской скамьи: какие люди идут в первые и во вторые. Но разница колоссальная. Я лишь скажу главное- тестеры имеют мотив и они готовы реализовать свою возможность, это осознанный выбор, а программисты не имеют мотива (ну не спрашивайте почему, ну нравится им проектировать и создавать и не рыпаться) и таким образом не реализуют её, они больше ремесленники.
Конечно, в среднем, я не буду брать лентяев, так вот: инженер-разработчик сильно технически развит, чем инженер по качеству. Это очевидно, иначе бы первый поменялся местом со вторым, и поменял бы их местами тот же ПМ.
И естественно, при прочих равных, допустим, управленческих способностях, лидерских качествах итд у этих двух, логичнее выбрать инженера-разработчика. Потому что у инженер-разработчика шире база. А это определяющий критерий, потому что человек способный решить проблему сильно лучше человека определившего проблему. А если учесть, что по роду деятельность более половины будущих ошибок определяются самим же разработчиком, то выбор вообще очевиден. Однако, хаха, выбор в пользу разработчика редко происходит, дело не только в мотивации (как я заметил выше), но и: уровне английского языка (у тестеров он в среднем выше по роду деятельности);
тестеры меньше загружены (это связанно с особенностью современных жизненных циклов ПО и этапов разработки).
, а мы все знаем, что нехватка времени может приводить к(а) это приводит к (б), затем наступает (в) и к увольнениям, а наоборот, избыток свободного времени, заставляет задуматься о планировании карьеры именно(!) в этой компании
Здравствуйте, oncer, Вы писали:
O>Девелоперу разобраться в деталях Тестерской работы — думаю легко (особенно девелоперу доросшему до высоких порзиций — вообще не проблемма). Верно? Верно.
Ох, не хотел бы я, чтобы вы когда-нибудь тестировали мой проект. Пофиг с какой позиции. Потому что хорошее тестирование — это очень и очень непросто.
O>Крутому Тестеру разобраться в деталях Девелоперской работы — не реально. Верно? верно.
Крутой тестер обязан быть крутым девелопером. Если мы говорим реально о крутом тестере, который может создать систему автоматического тестирования для системы, которая дает предсказуемые результаты, обеспечивает высокое тестовое покрытие, а также недорога в поддержке.
O>Думаю знание технологий у девелоперов гооораздо глубже. соответственно Девелопер Гооораздо лучше может оценить риски "гемора определенного рода". O>Для тестеров все что идет глубже UI — черный ящик. Для девелопера — нет.
Здравствуйте, Qwazar, Вы писали:
R>> Тестировщикам чаще приходится врубаться в предметную область, поэтому им проще получить общую картинку Q>Как вообще можно разрабатывать не врубаясь в предметную область??
Практика показывает, что такое бывает и это нормально. Даже в хорошем проекте можно аккуратно разбить функциональность на четко ограниченные контрактами модули, максимально отвязанные от предметной области.
Так что часто (но не всегда, конечно) с суровой окружающей средой первым сталкивается тестировщик.
Здравствуйте, oncer, Вы писали:
O>в последнее время начал слышать подобные утверждения. O>в большинстве случаев со стороны самих тестировщиков.
O>т.к. такие утвержедния регулярно слышу но не считаю их верными вообще, ... а также вижу случаИ когда бывшие тестры действительно менеджерят Девелоперов решил организовать так сказать опрос с мнениями почему утвержедние верно или не верно.
O>P.S. O>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь. O>спасиба.
Я бы сказал осторожней. На моей практике из тестировщиков чаще получаются хорошие ПМы, чем из программистов.
Объясню.
Программисты часто страдают "мелочным менеджментом", они переносят на проект свою оаптимичтичность в сроках.
При этом тестировщики хотя и не разбираются в технических деталях, но зато знают цену оценкам девелоперов, более реалистично оценивают проект в целом, лучше распределяют ресурсы, как это ни странно. И, наконец, работа тестировщика, обычно состоит из прохождения тестов раз за разом без устали и жалоб на программистов. Умение стоически воспринимать окружающую действительность очень полезно для менеджеров.
Из програмистов тоже получаются хорошие менеджеры, но чаще программисты запирают себя в башне из слоновой кости предпочитая общатся с компьютером, а не с людьми.
SE>Программисты часто страдают "мелочным менеджментом", они переносят на проект свою оаптимичтичность в сроках.
Программист всегда называет реалистичные сроки, только потом прибегает кто нибудь из sales и говорит — а можите побыстрее, у меня клиент ждать не будет, а что если такую фичу убрать, а что если так сделать, а что если... Заключат контракт, а потом говорят — нам нужна такая и такая фича, мы это в контракте прописали и в конечном итоге все равно, сроки становятся реальными, что изначально называл программист. Так что "оптимистичность" сроков которые выдает программист — это миф.
Возможно девушка пыталась вам сказать что у них в организации на должности тестеров берут людей которые не дотягивают по уровню на программиста. Т.е если его заставить писать он да что-то может и напишет, но это что-то лучше в проект не включать..
Даже в Microsoft насколько мне известно, людей сначала берут тестерами, а потом уже переводят в программисты.. Поправте меня, если я не прав.
C>Дело в том что правильный тестер должен знать спецификации не хуже (а то и лучше разработчика). Разработчику достаточно знать свой кусок, а тестер должен представлять как взаимодействуют между собой разные подсистемы.
Да в этом я с Вами согласен. У нас даже был человек к которому притаскивали поломаные базы и он их чинил, должность у него была разработчик-тестер.
C>То что какие-то тестеры работают плохо ни о чем не говорит. Вот ваши тестеры багов совсем не находят? C>а если находят, то какк-же так получается что значительно более компетентный девелопер их пропустил?
Суть теста — найти баги (если сильно упростить). Любой человек может совершить ошибку, как опытный так и не опытный. Да и кстати баги могут быть разного вида сложности, может это орфографическая ошибка, а может через 10 лет вылет программы из-за того что файл базы привысил размер 4ГБ и т.п. Т.е ошибку в орфографии может найти любой, а насчет переполнения базы может сказать только знающий..
C>Зато вот насчет здравомыслящего человека скажу. в работе разработчика нет ничего такого что "не мог выполнить просто обычный здравомыслящий человек"
А зачем тогда 5 лет учиться в институте? Зачем тогда вообще созданы институты? Раз каждый здравомыслящий человек может заменить разработчика и т.п? Здесь вы в корне не правы, если бы все было так просто, то не кто не требовал бы опыта работы..
На первой работе у Нас также начальник считал,
что любого можно заменить любым, в итоге щас испытавает недостаток кадров.
Здравствуйте, AC1D, Вы писали:
ACD>Суть теста — найти баги (если сильно упростить).
Это если ооочень упростить. Но лучше так не делать Иначе окажется, что где-то 80-90% тестов (в зависимости от глючности системы) не нужна в принципе.
C>>Зато вот насчет здравомыслящего человека скажу. в работе разработчика нет ничего такого что "не мог выполнить просто обычный здравомыслящий человек"
ACD>А зачем тогда 5 лет учиться в институте? Зачем тогда вообще созданы институты? Раз каждый здравомыслящий человек может заменить разработчика и т.п? Здесь вы в корне не правы, если бы все было так просто, то не кто не требовал бы опыта работы..
А вы посмотрите, чему учат по профильным специальностям. В значительной мере там пичкают математикой и прочими теориями, которые на практике потом мало кто применяет. Уже поднимали подобную тему. В итоге, если убрать этот "балласт", то в работе применяется лишь незначительная часть тех знаний, которая дается в ВУЗе и то потом надо по ходу работы изучать новые технологии, фреймворки, библиотеки и прочее, так как решению всех задач в "тепличных" условиях ВУЗ-а не обучишь. И к тому же, как показывают наблюдения, реально эти доли навыков и умений осваивают люди, которые не ограничивались решениями задач для лабораторок и курсовых, но и дополнительно упражнялись в программировании, разрабатывая свои проекты. А таких хорошо, если 5-я часть от группы.
И опять же, если бы те 5 лет обучения позволяли подготовить полноправного специалиста, тоже мало кто бы требовал опыта работы. Но на деле это выглядит иначе.
ACD>На первой работе у Нас также начальник считал, ACD>что любого можно заменить любым, в итоге щас испытавает недостаток кадров.
Не, одно дело, что кем попало менять не получится (а если получится, то ненадолго). Другое дело, как получить требуемые знания. И ничего сверхъестественного в получении этих знаний нет. Ключевой элемент — голова на плечах.
Здравствуйте, Demotivated, Вы писали:
D>Включаешься сам в разработку, берешь самое важное на себя, остальным демонстративно поручаешь самое несложное и рутинное. D>В итоге получили старшего разработчика, а роль ПМ-а придется брать на себя кому-то другому, например самому инициативному из тестеров
Значит ПМ-ом стоит брать ленивых программистов, но с опытом Таких которым лень брать чужую работу на себя.
M>И опять же, если бы те 5 лет обучения позволяли подготовить полноправного специалиста, тоже мало кто бы требовал опыта работы. Но на деле это выглядит иначе.
Вуз для примера, мало кто решается брать человека без опыта работы. Это я все про то что нет нечего сложного.. Сложное есть. И менять просто так не получиться.
M>Не, одно дело, что кем попало менять не получится (а если получится, то ненадолго). Другое дело, как получить требуемые знания. И ничего сверхъестественного в получении этих знаний нет. Ключевой элемент — голова на плечах.
Ну как кем попало, программист программисту рознь, меняли людями по спецальности, один может — другой нет хотя и старается...
Здравствуйте, AC1D, Вы писали:
ACD>Здравствуйте, Marduk, Вы писали:
M>>И опять же, если бы те 5 лет обучения позволяли подготовить полноправного специалиста, тоже мало кто бы требовал опыта работы. Но на деле это выглядит иначе.
ACD>Вуз для примера, мало кто решается брать человека без опыта работы. Это я все про то что нет нечего сложного.. Сложное есть. И менять просто так не получиться.
Получается, что всё упирается в наличие готовых знаний и подтвержденных навыков для некоторой конкретной должности. В этом случае, просто так заменить человека "здесь и сейчас" на кого-то со знаниями в другой предметной области без потерь не получится. Это да.
Так или иначе время уйдет на дообучение + на приобретение навыков в полном объеме для выполнения текущих задач.
Но если есть такая возможность дообучить человека, то ничего сверхъестественного в программировании нет, что бы мешало в нем разобраться на достаточном для выполнения текущих задач уровне. Аналогично и для других областей. Ключевой блок, который может иметь место — необходимость перестраивать мышление. С этим могут быть проблемы.
Здравствуйте, SE, Вы писали:
SE>Здравствуйте, oncer, Вы писали:
O>>в последнее время начал слышать подобные утверждения. O>>в большинстве случаев со стороны самих тестировщиков.
O>>т.к. такие утвержедния регулярно слышу но не считаю их верными вообще, ... а также вижу случаИ когда бывшие тестры действительно менеджерят Девелоперов решил организовать так сказать опрос с мнениями почему утвержедние верно или не верно.
O>>P.S. O>>если не тяжело примите участие в одноименном голосовании. статистика — полезная вещь. O>>спасиба.
SE>Я бы сказал осторожней. На моей практике из тестировщиков чаще получаются хорошие ПМы, чем из программистов. SE>Объясню. SE>Программисты часто страдают "мелочным менеджментом", они переносят на проект свою оаптимичтичность в сроках. SE>При этом тестировщики хотя и не разбираются в технических деталях, но зато знают цену оценкам девелоперов, более реалистично оценивают проект в целом, лучше распределяют ресурсы, как это ни странно. И, наконец, работа тестировщика, обычно состоит из прохождения тестов раз за разом без устали и жалоб на программистов. Умение стоически воспринимать окружающую действительность очень полезно для менеджеров. SE>Из програмистов тоже получаются хорошие менеджеры, но чаще программисты запирают себя в башне из слоновой кости предпочитая общатся с компьютером, а не с людьми.
стереотипы какие-то из серии "все прогеры — казлы". у них жа баги
точно на тех основаниях могу утверждать, что:
1. QA часто забивают на работу, т.к. она скучная и закрывают непроверенные баги
2. QA часто жалуются, что им приходится преоткрывать баги, хотя они просто не понимают, что это уже другой баг и приходится вечно их тыкать носом
3. QA часто не готовы выполнять проверку одних и тех же багов, потому все время бегают и просят чтобы их закрыли намертво
4. QA часто говорят, что не могут проверить многие вещи, т.к. это вне их компетенции, что тут нужно (ах) программирование
5. QA часто не докличешься — сядет такой за компом, все телефоны выключит и айда себе аську тестить
6. QA ... да ладно вам... вот мы дружим с нашими QA — они наше все. если они нашли баги — это супер и честь им и хвала. Хорошо, что это не пошло в продакшн.
не надо тут нам рассказывать. мы работаем вместе и работы у всех хватает.
Это у вас там какие-то программисты недоделанные.
И Qa тоже небось из первых 5 пунктов. Вряд ли они станут менеджерами. Так и будут в одну кнопку тыкать всю жисть.
А наши qa — наше все
И программировать тоже умеют, но не так, как находить ошибки в нем самом.
Бывало, сам закодит, сам ошибку найдет и сам же исправит
Они и менеджерами и хоть куда.
С программистами им конечно сложно конкурировать, но всякое бывает.
Здравствуйте, s.ts, Вы писали:
ST>Это у вас там какие-то программисты недоделанные.
Это типа такое завуалированное оскорбление?
ST>И Qa тоже небось из первых 5 пунктов. Вряд ли они станут менеджерами. Так и будут в одну кнопку тыкать всю жисть.
Такие долго не протянут Не представляю где такие нужны. Но такие попадаются... время жизни у них правда полгода, не больше. Пока не станет понятно, что ничему кроме тыканья одной кнопки они ничему не научатся.
ST>А наши qa — наше все ST>И программировать тоже умеют, но не так, как находить ошибки в нем самом.
Не поверишь...
ST>Бывало, сам закодит, сам ошибку найдет и сам же исправит
Это как? У вас тестировщики код пишут?!
ST>Они и менеджерами и хоть куда.
Ну вот Вы со мной и согласились, что тестировщики "и менеджерами и хоть куда"
ST>С программистами им конечно сложно конкурировать, но всякое бывает.
Программисты нужны на их месте. Ибо они на нем наиболее эффективны.
Здравствуйте, SE, Вы писали:
SE>Здравствуйте, s.ts, Вы писали:
ST>>Это у вас там какие-то программисты недоделанные.
SE>Это типа такое завуалированное оскорбление?
нука ципочку вывода плиз.
тестер только запускал ее, следил за результатами выполнения и сигнализировал если что-то его не устраивало. 
