Re[7]: "тестировщики - неплохие Проджект Менеджеры девелопер
От: Marduk Великобритания  
Дата: 20.05.10 20:35
Оценка:
Здравствуйте, злая и глупая, Вы писали:

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


M>>>>В корне неверно, если, конечно, под тестером подразумевается не джуниор тестер, которому надо только кликать по кнопкам в соответствии с предписаниями.

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

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

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

ЗИГ>>>чем же они тогда занимаются?

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

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

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

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


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

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

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


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

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


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

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

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

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

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

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

ЗИГ>Ок, расскажите, как именно тестеры что-то автоматизируют без работы с исходным кодом?

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

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


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

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

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

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


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