Здравствуйте, 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>Во сколько раз? И, пожалуйста, методику расчета.
во много
множество функций которые может выполнять девелопер содержит в себе полностью подмножество функций выполняемых тестировщиками, но не наоборот
вот отсюда и пляшите