... ЗИГ>да, там будут вот эти вот ваши умные слова про метрики, планы тестирования и прочее — но я не понимаю за что тут платят деньги, я не вижу какой-то очень сложной работы которую бы не мог выполнить просто обычный здравомыслящий человек? работа разработчика в разы сложнее!
Так речь не о сложности, а о ПМ-стве. Так как работа программиста сложнее, то сочетать ее с ПМ-ством сложнее. Особенно это проявляется при разработке сложных систем, где много различных расчетов, алгоритмов. Где нужно понимать какие данные можно давать на вход и какие при этом данные должны быть на выходе. Программист в таких сложных системах может отвечать и хорошо понимать только свой кусок подсистемы. Тестировщик же может понимать не только всю подсистему, которую тестирует, но так же немного и другие подсистемы, которые с ней взаимодействуют. Т.е. он может иметь более широкое понимание, как работает вся система. Следовательно перейти в ПМ-ы в таком случае ему будет проще.
Здравствуйте, 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 ... и соответствующие з/п сравнимые с разработческими.
Если у вас это просто ярлыки, то это плохо. По хорошему это свидетельство того, что человек на деле доказал, что он не дурак.
Тут на самом деле не важно кем человека взяли на работу тестировщиком или программистом, или вообще грузчиком. Это все второстепенное, главное что у человека в голове. Если он дурак, то от того что его взяли программистом он умнее не станет. Будет у человека голова на месте, будут способности к руководству, то у ПМ он будет хорошим, если дорастет.
Про грузчика: на моей предыдущей работе генеральным директором и основателем был мужик, который начинал с грузчика в крупной компании, из грузчика его сделали зав. складом, потом менеджером по логистике, затем начальником отдела по логистике в этом городе, затем он ушел в другую компанию начальником отдела выгоных грузоперевозок уже по всей России, а в итоге основал свою компанию. Если следовать вашей логике, то он должен был так и остаться грузчиком, потому что работа не фига не способствующая уственному развитию.
Главное что в голове, а не то что на бейджике.
тестер только запускал ее, следил за результатами выполнения и сигнализировал если что-то его не устраивало. 
