Прикольно на новой работе. Вот я добавил в софту новую мощную фичу, о которой все давно мечтали и оно наконец сбылось. Погоняли, нашли мелкие глюки, я поправил, в общем, нормальный рабочий процесс. А теперь, когда уже все работает, начальство требует составить план финального тестирования. Ну и че? — Ну я могу написать делайте то, нажмите сюда и т.д. Но какой в этом смысл?! Я объявляю новую фичу, подробно объясняю ее функциональность, а от меня еще требуют какой-то план, как ее тестировать! А я-то откуда знаю, как?! Я уже протестировал сам, прежде чем выдать и я гарантирую что этот план даст true. Я могу описать все шаги, но нафига это все, когда оно и так уже проверено? Задача тестера — поймать программиста. А если от программиста требуют описания того, как его поймать, то это вообще нонсенс. Нафига тогда тестеры нужны?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Прикольно на новой работе. Вот я добавил в софту новую мощную фичу, о которой все давно мечтали и оно наконец сбылось. Погоняли, нашли мелкие глюки, я поправил, в общем, нормальный рабочий процесс. А теперь, когда уже все работает, начальство требует составить план финального тестирования. Ну и че? — Ну я могу написать делайте то, нажмите сюда и т.д. Но какой в этом смысл?! Я объявляю новую фичу, подробно объясняю ее функциональность, а от меня еще требуют какой-то план, как ее тестировать!
Начальство хочет быть уверенным, что кто-то помимо тебя сможет проверить работоспособность этой фичи. И что если кто-то, кроме тебя доработает эту фичу, то он сможет удостовериться, что всё работает как надо. В принципе, желания вполне разумные.
MS>А я-то откуда знаю, как?!
Макс, ты не знаешь о своей фиче ничего.
MS>Я уже протестировал сам, прежде чем выдать и я гарантирую что этот план даст true. Я могу описать все шаги, но нафига это все, когда оно и так уже проверено? Задача тестера — поймать программиста. А если от программиста требуют описания того, как его поймать, то это вообще нонсенс. Нафига тогда тестеры нужны?
А ты спрашивал, что в этом плане хочет видеть начальство? Общие подходы к таким документам есть, но они могут варьировать от организации к организации.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, McSeem2, Вы писали:
ГВ>>Э... Знаешь, есть такой закон Мерфи: "Настоящие программисты не тестируют"? Ловятся если не все, то почти все, и что характерно, все уверены в том, что вот у них-то всё совершенно нормально. В смысле, я не думаю, что ты непременно поймаешься, но уверенность слегка настораживает.
MS>Но я-то как раз тестирую, причем весьма тщательно, прежде чем сабмитить свой код. Это первая заповедь программиста.
Давай, представим на мгновение, что ты... Скажем, решил организов... Нет. О! Достало тебя всё, ты всё бросил и ушёл в запой. Ну вот, наскучило тебе всё, и ушёл ты в запой. Устал, со всеми бывает — месяц побесишься и очухаешься. А твой чудесный, полностью-полностью оттестированный код тут как раз понадобилось слегка доработать. А где доработать — там и проверить.
MS>Бывают лажи, но в основном по мелочи и всяко меньше, чем у Kenny. Он такой типа рутинщик, но часто мне приходится править его глюки, типа банальной проверки на null-ref при down-cast. Он делает очень много, гораздо больше чем я. Но разгребать после него — это иногда кошмар.
Раз ты смог подобрать сопельки за Kenny, то и другие смогут. К Kenny как раз вопросов нет: если кто-то может исправить его код, это автоматом означает, что в его коде можно разобраться.
MS>И вообще, с возрастом приходит такое понимание — не надо "звездить", делай просто и надежно, даже если это противоречит твоей внутренней философии.
Так вот как раз для фирмы "просто и надёжно" — это когда есть куда отправить нового человека что-то почитать (за исключением одного лишь кода), при этом зная, что чтение не займёт много времени и не потребует решения нетривиальных задач. Короче говоря, что постижение наработанного займёт некое предсказуемое время.
Так что трансформация внутренней философии ещё не окончена — теперь она должна охватить не только твоё персональное "хочу-не хочу", а немного осмотреться в окружающем мире.
ГВ>>Кажется, начинаю понимать... Попробуй сыграть по всем правилам: перечисли в том тест-плане полный список параметров, граничнные значения, ожидающиеся характеристики под нагрузкой (если применимо). Это немного out of scope для тест-плана, но всё-таки. Приведи несколько характерных тест-кейзов для примера и ещё — негативные кейзы, то есть такие, где должны вылететь ошибки. Играть, так играть, чего уж там!
MS>Да блин, тестеры это все уже 256 раз знают. Я собственно и приделал этот митер, чтобы посмотреть, а сколько реально времени занимают мои псевдо-каналы. Чисто сам для себя, потому что в задачу тестеров это не входит. Но я искренне хочу, чтобы наша софта работала хорошо. Оказалось, что практически нисколько по сравнению с мониторингом. А директор был очень сильно озабочен этим вопросом. Потому что прежние программеры вызывали некий скрипт на питоне, и он конечно же работал жутко тормозно. А я просто сделал eval абсолютно классического типа имени Дейкстры, вот и все. Shunting Yard — классика. Это заняло пару дней, чтобы подогнать и отшлифовать под задачу. И в работе занимает не более процента всего времени, даже при очень сложных выражениях. Ну и потом прорвало. А давай сделаем логические выражения, а давай добавим IIR фильтры, а вот если еще каутнеры добавить, то вообще будет круто. Ну, добавляю, что мне не сложно. Но и не интересно.
Поэзия, конечно, даже жалко опошлять, но ты не серчай, ежели чего. Значит, ты сейчас сказал, буквально, следующее: "Появилась тулза, которая всем понравилась и на неё на неё начали пошагово накручивать функционал". Тулза перестала быть твоим ювелирным поделием и стала "производственным объектом", к которому подцеплено много людей, много пожеланий и — много надежд. Подозреваю, что твой шеф, не будь дураком, всё это распрекрасно чувствует, и твою тоску от тривиальных доработок — тоже. И отлично понимает, что за этим может последовать. Ну, не понимает, а скажем так, выделяет несколько вариантов развития ситуации, среди которых будет немало негативных. Чего он в конечном итоге боится? Он боится потери контроля, и правильно делает. Kenny шарашит код, как из пулемёта, но в его коде разберётся даже школьник, так что с ним проблем нет и ещё сто лет не будет. А ты весь такой продвинутый, гуру, но уже начинаешь зримо скучать, и кто тебя знает, что у тебя на уме? И получится, что масса народу зависит от одного тебя и твоего настроения.
MS>Ну и возник вопрос — а зачем изобретать колесо? — а вот зачем, чтобы быть независимым. Ну представьте, 30K кода на C# или пожизненная MS>зависимость от какой-то там DLL? А вот поэтому и надо. Софта должна легко запускаться и работать, безо всяких внешних условий. И это инженерам нравится. А если еще какой-то Питон надо инсталлировать, да пошли вы со своим питоном, тем более, что в реал-тайме он ну вообще никак не катит.
Инженеры правы, что тут скажешь?
MS>И вот вопрос приоритета — Kenny классный программер, но он рутинщик и очень молодой. А я как старший товарищь должен за ним следить. А мне этого не хочется, я хочу решать нетривиальные инженерные задачи. Ну и как теперь жить, Дядь Мить?
Не льсти себе, тебе нравится не инженерные задачи решать, а в технических головоломках ковыряться и решать сугубо технические ребусы. Сомнений нет, дело благое, сам люблю, но это только малая часть инженерной работы. Инженер — он ещё и организатор. Те, кто не занимается организацией — по сути, простые слесари. Я не против слесарей, не подумай чего, только не называй их работу инженерной. На старом наречии таких называли левшами. Да, левша может сделать из г..на конфетку, но он — левша. Инженер же сделает так, чтобы левша сам по себе мог появиться (т.е. — поставит ему задачу), да ещё не просто появиться, но и не потерять при этом своего достоинства (сиречь — учтёт человеческий фактор).
Так что, вот тебе нетривиальная инженерная задача: сделать так, чтобы знания о способах тестирования легко могли быть переданы другому человеку. Шикарная задача, если разобраться!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хе-хе, как вариант, её можно представить в виде разработки нормативной документации (тоже часть инженерной работы). Здесь нюанс — обычно такую документацию пишут каким-то скулосводящим канцелярским диалектом. Попробуй написать то же самое, но живым языком, у тебя ж в принципе получается так изъясняться — того гляди, зачитываться ещё будут.
На самом деле, не хватает скорости в каналах связи. Ну просто катастрофически не хватает. Я достиг такого уровня просветления, что мне уже не требуется, чтобы люди меня одобрили. Но хочется, чтобы поняли идею и потом уже решали сами — одобрять или нет, ибо я и сам пока не знаю — имеет это смысл или фигня на постном масле. Но мне надо подкючиться к коллективному разуму и приходится это делать по модему на 300 бод. И приходится тратить очень много бесполезных слов. Мечтаю об интерфейсе, типа втыкакния USB в мозг, чтобы не надо было изобретать образные метафоры. Хотя мне иногда приятно, что меня считают таким техно-клоуном, который делает больше, чем обещает, даже безо всяких бонусов. Но этот клоун позволяет себе резкие высказывания. Которые могут и обидеть, а мне потом стыдно, что не заслужил он таких слов, которые я сказал. И вот надо найти грань, через которую переступать не хорошо. Миха Антонов — мой лучший приятель и яростный враг. И я переступал грань в работе, доходило чуть не до драки. Но мудрый Брендан решил, что ну их нафиг этих Русских, одного хватит, а вдвоем они только собачатся. Как приходят на работу — хоть уши затыкай. Но при этом и сделано было совместно немало. Просто у каждого человека ум устроен по-разному. Причем настолько по-разному, что это непостижимо уму. Для тебя какая-то мысль может быть банальной и очевидной. А для другого — тайна за семью печатями. Например, ну никак не могу понять сущности Z-преобразований. Вот хоть тресни не могу. И эти все полюсы и нули на Z-плоскости мне абсолютно ни о чем не горворят. Я только знаю, что это работает. И я знаю общие принципы, типа чем фильтр резче, тем он тормознее. Ну и много других принципов тоже. Но все-таки, осознать и усвоить это тайное знание полюсов и нулей было бы кайфово.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Например, ну никак не могу понять сущности Z-преобразований. Вот хоть тресни не могу. И эти все полюсы и нули на Z-плоскости мне абсолютно ни о чем не горворят. Я только знаю, что это работает. И я знаю общие принципы, типа чем фильтр резче, тем он тормознее. Ну и много других принципов тоже. Но все-таки, осознать и усвоить это тайное знание полюсов и нулей было бы кайфово.
А с другой стороны, один математик меня сильно удивил. Не тем, что он не мог в уме быстро перевести дюймовые дроби в сантиметры. А тем, что быстро осознал эквивалентность неких преобразований, до осознания которых мне ползти и ползти. И действительно, все оказалось потом очень просто. Вот поэтому я и говорю, что разум каждого человека — уникален, но у нас он просто ободран на наждаке всеобщей приличности до своей наготы, от которой он комплексует. И поэтому бьется в бесполезных судорогах и становится одинаковым, более-менее соответсвующим общему тренду. А разум математиков свободен от людских условностей. Им по..., что они не могут поделить 111 на три. Арнольд был не прав в своих рассуждениях.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Нафига тогда тестеры нужны?
В том числе чтобы тестпланы писать
Нормальное разделение труда.
Так что твое недоумение понятно.
Но тестерам нужно помочь. Дам им спецификации.
Без них они ничего толком не протестируют.
Без явных спецификаций еще можно что-то накодить,
а тестировать без них вообще толком невозможно.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, McSeem2, Вы писали:
MS>>Нафига тогда тестеры нужны?
B>В том числе чтобы тестпланы писать B>Нормальное разделение труда. B>Так что твое недоумение понятно. B>Но тестерам нужно помочь. Дам им спецификации. B>Без них они ничего толком не протестируют. B>Без явных спецификаций еще можно что-то накодить, B>а тестировать без них вообще толком невозможно.
Сначала подумал даже, что стихи...
80% людей оценивают свое мастерство выше среднего...
Здравствуйте, McSeem2, Вы писали:
MS>Прикольно на новой работе. Вот я добавил в софту новую мощную фичу, о которой все давно мечтали и оно наконец сбылось. Погоняли, нашли мелкие глюки, я поправил, в общем, нормальный рабочий процесс. А теперь, когда уже все работает, начальство требует составить план финального тестирования. Ну и че? — Ну я могу написать делайте то, нажмите сюда и т.д. Но какой в этом смысл?! Я объявляю новую фичу, подробно объясняю ее функциональность, а от меня еще требуют какой-то план, как ее тестировать! А я-то откуда знаю, как?! Я уже протестировал сам, прежде чем выдать и я гарантирую что этот план даст true. Я могу описать все шаги, но нафига это все, когда оно и так уже проверено? Задача тестера — поймать программиста. А если от программиста требуют описания того, как его поймать, то это вообще нонсенс. Нафига тогда тестеры нужны?
Ну не знаю... вот бывают такие фичи которые крайне лениво программисту тестировать под всеми возможными нюансами. Время это занимает. Тестеру иногда кажется — а один фиг, все юзеры одинаковые, под любым протестирую. А на самом деле в бэкенде юзеры разные, и разные настройки могут непредсказуемым образом крашнуть систему. это только программист может сказать — что вот эту вещь желательно потестировать под юзерами с разным уровнем прав доступа и т.п.
я например ленюсь такое делать самой, я ж не тестер чтоб как обезьяна целыми днями кликать там. Я основное протестила, свои тесты написала, и дальше полагаюсь на тестировщиков и пишу им арии, которые надо проверить и которые знаю что могут повлиять на результат.
Здравствуйте, McSeem2, Вы писали:
MS>Прикольно на новой работе. Вот я добавил в софту новую мощную фичу, о которой все давно мечтали и оно наконец сбылось. Погоняли, нашли мелкие глюки, я поправил, в общем, нормальный рабочий процесс. А теперь, когда уже все работает, начальство требует составить план финального тестирования. Ну и че? — Ну я могу написать делайте то, нажмите сюда и т.д. Но какой в этом смысл?! Я объявляю новую фичу, подробно объясняю ее функциональность, а от меня еще требуют какой-то план, как ее тестировать! А я-то откуда знаю, как?! Я уже протестировал сам, прежде чем выдать и я гарантирую что этот план даст true. Я могу описать все шаги, но нафига это все, когда оно и так уже проверено? Задача тестера — поймать программиста. А если от программиста требуют описания того, как его поймать, то это вообще нонсенс. Нафига тогда тестеры нужны?
потом код поменяют и его надо будет тестировать опять.
On 11.04.2013 14:17, bastrakov wrote:
> детектирую опыт в индустрии не больше пары лет, и возраст до 27.
Ну, вот только он в америках и зарплаты у вас сравнимы в циферках — у
него правда в баксах в год, у тебя в рублях в месяц.
Я так предполагаю, что у тебя около 100000.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Начальство хочет быть уверенным, что кто-то помимо тебя сможет проверить работоспособность этой фичи. И что если кто-то, кроме тебя доработает эту фичу, то он сможет удостовериться, что всё работает как надо. В принципе, желания вполне разумные.
MS>>А я-то откуда знаю, как?!
ГВ>Макс, ты не знаешь о своей фиче ничего.
Если бы я был в чем-то не уверен, я бы с радостью написал этот план, типа обратите пристальное внимание вот на такие-то условия. А то, что от меня требуют мне напоминает коментарии в коде, типа ~ClassName() // Destructor
Я однажды добавил к такому коменту в реальном коде "yes, Captain Obvious guaranteed!!!". Задача тестера — найти такие условия, при которых фича глючит — и такое случалось, при чем безо всяких тест-планов. Молодцы студенты-тестеры, они мне очень помогли. А если бы был формальный тест-план, ни фига бы не нашлось. Потому что я сам уже это все проделал и проверил.
Еще прикольная история. Приделал я тут CPU Meter. Ну софта реал-тайм, и если будет плохо, данные будут теряться. А этот митер показывает. А там может быть 128 оцифрованных аналоговых каналов в реал-тайме по USB. И нужен реал-тайм мониторинг всмякого-разного. И вот прежние двое прграммеров (да, царство им небесное, они оба погибли в бурных водах горной реки Западной Вижинии год назад. Я не был с ними знаком, но их код останется со мной навеки. Я уже начал различать, что писал один, а что — другой) просто делали то, что от них требуется. В результате получилась такая каша, что ее разгребать и разгребать. И вот я в такой ситуации и меня назначили типа главным. А конторка-то маленькая, вся продукция делается в гараже, где директор хранит свои мотоциклы. Если кому интереесно — marslabs.com
И вот по поводу этого митера разгорелся знатный срач. Ernie (директор) сказал, что это круто, внедряем. На что посыпалось очень много возражений со стороны маректинга, типа кому понравится, что наша софта не эффективна в определенных режимах. Но Ernie всех заткнул одной фразой — Be fair to yourself. И намекнул, что наши клиенты именно за это нас и любят, если допустил лажу — ну так и скажи, любой инженер поймет. Ну, и маркетинг заткнулся. К счастью, во всяких фордах и космических отраслях инженеры таки рулят. Я очень уважаю этого человека. Хотя и ненавижу. Потому что он, блинн, в точности такой же эбонат натрия как и я, только чуть старше.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
ГВ>>Начальство хочет быть уверенным, что кто-то помимо тебя сможет проверить работоспособность этой фичи. И что если кто-то, кроме тебя доработает эту фичу, то он сможет удостовериться, что всё работает как надо. В принципе, желания вполне разумные.
MS>>>А я-то откуда знаю, как?! ГВ>>Макс, ты не знаешь о своей фиче ничего.
MS>Если бы я был в чем-то не уверен, я бы с радостью написал этот план, типа обратите пристальное внимание вот на такие-то условия. А то, что от меня требуют мне напоминает коментарии в коде, типа ~ClassName() // Destructor
Э... Знаешь, есть такой закон Мерфи: "Настоящие программисты не тестируют"? Ловятся если не все, то почти все, и что характерно, все уверены в том, что вот у них-то всё совершенно нормально. В смысле, я не думаю, что ты непременно поймаешься, но уверенность слегка настораживает.
MS>Я однажды добавил к такому коменту в реальном коде "yes, Captain Obvious guaranteed!!!". Задача тестера — найти такие условия, при которых фича глючит — и такое случалось, при чем безо всяких тест-планов. Молодцы студенты-тестеры, они мне очень помогли. А если бы был формальный тест-план, ни фига бы не нашлось. Потому что я сам уже это все проделал и проверил.
Кажется, начинаю понимать... Попробуй сыграть по всем правилам: перечисли в том тест-плане полный список параметров, граничнные значения, ожидающиеся характеристики под нагрузкой (если применимо). Это немного out of scope для тест-плана, но всё-таки. Приведи несколько характерных тест-кейзов для примера и ещё — негативные кейзы, то есть такие, где должны вылететь ошибки. Играть, так играть, чего уж там!
Рыбу тест-плана можешь погуглить, но по сути в нём всё просто: зачем, как, в каких условиях, какие кейзы, что должно быть на выходе, что считается приемлемым результатом тестирования (ну там, краш не чаще, чем раз в 5 минут ).
MS>Еще прикольная история. [...]
Клёвый у тебя директор, Be fair to yourself — ценное качество. За это и натриеэбонатизм с сараем простить можно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, McSeem2, Вы писали:
MS>А если бы был формальный тест-план, ни фига бы не нашлось.
Формальный тест план всего лишь делает явным что и как тестировалось.
Формальность не убивает качество тестирование. Она просто делает его явным.
Альтернатива — народ потратил время, и не в состоянии сказать что они вообще протестировали...
MS>Потому что я сам уже это все проделал и проверил.
Ну тогда тебе надо дать персональный штамп ОТК, как раньше было заводах у некоторых гуру-слесарей
Типа тебе доверяют и дополнительный контроль не нужен
MS>Прикольно на новой работе. Вот я добавил в софту новую мощную фичу,
От фичи зависит. Если требует экспертных знаний, то имеет смысл привлекать разработчиков.
Здравствуйте, bastrakov, Вы писали:
B>Здравствуйте, McSeem2, Вы писали:
MS>>Прикольно на новой работе.
B>детектирую опыт в индустрии не больше пары лет, и возраст до 27. B>припоминаю что-то про музыку... может обратно к гитаре? во
Решил потроллить?
А вообще, забавная ситуация. Мне бы не хотелось, чтобы такие люди как бастраков нанимали меня на работу.
MS>Задача тестера — найти такие условия, при которых фича глючит — и такое случалось, при чем безо всяких тест-планов. Молодцы студенты-тестеры, они мне очень помогли. А если бы был формальный тест-план, ни фига бы не нашлось. Потому что я сам уже это все проделал и проверил.
Задачи тестеров бывают разные. Геннадий вам уже писал про то, что тест-план необходим для регрессионного тестирования, например. Для такого тестирования план очень полезен, так как позволяет не забыть никаких нужных шагов. При внесении изменения можно не протестировать все (не заметить зависимость в коде, забыть про какой-то сценарий работы). Т.е. польза от тест-плана наблюдается не "сейчас", а "потом". А вот свободный поиск — это задача на пользу "сейчас".
Кому писать план — вопрос сложный. Это могут быть аналитики или тестировщики (в этом случае по описанию фичи план составляется), это может быть программист (лучше знает реализацию или вообще не было формальных спецификаций).
Здравствуйте, minorlogic, Вы писали:
M>Нанять пару индусов для такого , а самому полезным заняться
лучше 1-2 выходца из СНГ, личный опыт
1 девушка из СНГ за два года только один дефект с моей точки зрения не был багом (остальные реальные баги)
последнии 3-4 месяца, группа индийских товарищей человек 10-15
я реально задобался закрывать не баги (уже есть заготовка куда только вставляю номер страницы документации где описанно как оно должно работать)
на каком то этапе пришлось закрывать все дефекты, результат
из 37 баг репортов 2 реальные ошибки (я даже не спорил стал фиксить) 35 было закрыто как ошибка тестирования
по факту приходиться перетестировать каждый баг репорт что они генерят, а генерят они просто много так как документацию не читают или у них план каждый дожен загенерить 10 репортов в сутки
Re: When the intern tells me that "the tests are for those who can not program"
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, McSeem2, Вы писали:
MS>>Нафига тогда тестеры нужны?
B>В том числе чтобы тестпланы писать
Вообще-то тестеры пишут тест кейсы ... а вот тест-план должен писать как раз разработчик
Так что я честно проблем тут не вижу, более того похоже что в конторе "правильный" процесс разработки.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Э... Знаешь, есть такой закон Мерфи: "Настоящие программисты не тестируют"? Ловятся если не все, то почти все, и что характерно, все уверены в том, что вот у них-то всё совершенно нормально. В смысле, я не думаю, что ты непременно поймаешься, но уверенность слегка настораживает.
Но я-то как раз тестирую, причем весьма тщательно, прежде чем сабмитить свой код. Это первая заповедь программиста. Бывают лажи, но в основном по мелочи и всяко меньше, чем у Kenny. Он такой типа рутинщик, но часто мне приходится править его глюки, типа банальной проверки на null-ref при down-cast. Он делает очень много, гораздо больше чем я. Но разгребать после него — это иногда кошмар.
И вообще, с возрастом приходит такое понимание — не надо "звездить", делай просто и надежно, даже если это противоречит твоей внутренней философии.
ГВ>Кажется, начинаю понимать... Попробуй сыграть по всем правилам: перечисли в том тест-плане полный список параметров, граничнные значения, ожидающиеся характеристики под нагрузкой (если применимо). Это немного out of scope для тест-плана, но всё-таки. Приведи несколько характерных тест-кейзов для примера и ещё — негативные кейзы, то есть такие, где должны вылететь ошибки. Играть, так играть, чего уж там!
Да блин, тестеры это все уже 256 раз знают. Я собственно и приделал этот митер, чтобы посмотреть, а сколько реально времени занимают мои псевдо-каналы. Чисто сам для себя, потому что в задачу тестеров это не входит. Но я искренне хочу, чтобы наша софта работала хорошо. Оказалось, что практически нисколько по сравнению с мониторингом. А директор был очень сильно озабочен этим вопросом. Потому что прежние программеры вызывали некий скрипт на питоне, и он конечно же работал жутко тормозно. А я просто сделал eval абсолютно классического типа имени Дейкстры, вот и все. Shunting Yard — классика. Это заняло пару дней, чтобы подогнать и отшлифовать под задачу. И в работе занимает не более процента всего времени, даже при очень сложных выражениях. Ну и потом прорвало. А давай сделаем логические выражения, а давай добавим IIR фильтры, а вот если еще каутнеры добавить, то вообще будет круто. Ну, добавляю, что мне не сложно. Но и не интересно.
Ну и возник вопрос — а зачем изобретать колесо? — а вот зачем, чтобы быть независимым. Ну представьте, 30K кода на C# или пожизненная
зависимость от какой-то там DLL? А вот поэтому и надо. Софта должна легко запускаться и работать, безо всяких внешних условий. И это инженерам нравится. А если еще какой-то Питон надо инсталлировать, да пошли вы со своим питоном, тем более, что в реал-тайме он ну вообще никак не катит.
И вот вопрос приоритета — Kenny классный программер, но он рутинщик и очень молодой. А я как старший товарищь должен за ним следить. А мне этого не хочется, я хочу решать нетривиальные инженерные задачи. Ну и как теперь жить, Дядь Мить?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
ГВ>Начальство хочет быть уверенным, что кто-то помимо тебя сможет проверить работоспособность этой фичи. И что если кто-то, кроме тебя доработает эту фичу, то он сможет удостовериться, что всё работает как надо. В принципе, желания вполне разумные.
Не по этой причине а потому что слышали где-то что так надо/круто.
MS>>Нафига тогда тестеры нужны?
B>В том числе чтобы тестпланы писать B>Нормальное разделение труда. B>Так что твое недоумение понятно. B>Но тестерам нужно помочь. Дам им спецификации. B>Без них они ничего толком не протестируют. B>Без явных спецификаций еще можно что-то накодить, B>а тестировать без них вообще толком невозможно.
Наводящий вопрос: а если он сам неправильно задачу понял?
Здравствуйте, Берсерк, Вы писали:
Б>Расскажи лучше что за новая работа
Прикольная. Data acquisition. Ничего космического, 16 бит на канал, просто все очень точно и очень малошумяще. Со временем придется разбираться и в firmware c ихними фильтрами. Думаю улучшить и углубить многополюсными фильтрами Чебышева, Лежандра и прочих Баттервортов. Главное — правильно посчитать полюсы и нули. Да, это все уже сделано много раз, но надо заэмбедить на голом Си в хардварь. Думается мне, что все коэффициенты фильтров надо вычислять на компе и в хардварь слать уже готовые. Но тогда в автономе будет сложно рулить, fc уже так просто не поменяешь. Вот думаем, как быть. Я голосую за компромисное решение, простыми фильтрами можно рулить в чипе, а сложными нельзя. Хотя можно сделать таблицу хоть на мег и интерполировать коэффициенты. Жизнь программера трудна, но интересна. Где я только не работал, в какие канализации только не нырял! И в финансы и в графику и в молекулярную биологию и в вычислительную химию. И везде надо наводить порядок. Мы, програмимисты — ассенизаторы людских знаний. И это должно звучать гордо! Вот кто придумал самое гениальное изобретение — канализацию? Без нее бы все давно потонуло в говнах. Вот так же и программисты выведены этим вашим мирозданием, чтобы за мелкий прайс сделать из большого беспорядка чуть меньший беспорядок. Мы — реально ассенизаторы! Только это понимание доступно не всем, молодые не поймут.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Поэзия, конечно, даже жалко опошлять, но ты не серчай, ежели чего. Значит, ты сейчас сказал, буквально, следующее: "Появилась тулза, которая всем понравилась и на неё на неё начали пошагово накручивать функционал". Тулза перестала быть твоим ювелирным поделием и стала "производственным объектом", к которому подцеплено много людей, много пожеланий и — много надежд. Подозреваю, что твой шеф, не будь дураком, всё это распрекрасно чувствует, и твою тоску от тривиальных доработок — тоже. И отлично понимает, что за этим может последовать. Ну, не понимает, а скажем так, выделяет несколько вариантов развития ситуации, среди которых будет немало негативных. Чего он в конечном итоге боится? Он боится потери контроля, и правильно делает. Kenny шарашит код, как из пулемёта, но в его коде разберётся даже школьник, так что с ним проблем нет и ещё сто лет не будет. А ты весь такой продвинутый, гуру, но уже начинаешь зримо скучать, и кто тебя знает, что у тебя на уме? И получится, что масса народу зависит от одного тебя и твоего настроения.
Ну ты меня уел. Правду-матку режешь. Я именно поэтому и стараюсь делать код проще, так, чтобы даже Kenny легко разобрался. Да, я наигрался с усложнистикой. AGG, потом триангуляция с анти-алиасингом. Хватит, наигрался. Хочется чего-то простого и конкретного. Пользу приносить. Да. Ну и раскапывать код погибших людей. Безо всяких коментов. Некоторые data binding я так и не вкурил, че там происходит — не знаю.
ГВ>Так что, вот тебе нетривиальная инженерная задача: сделать так, чтобы знания о способах тестирования легко могли быть переданы другому человеку. Шикарная задача, если разобраться!
Да, задача хорошая. Но только вот беда — мне ей заниматься не интересно. Люди не по моей части, дайте мне железяки.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
ГВ>>Так что, вот тебе нетривиальная инженерная задача: сделать так, чтобы знания о способах тестирования легко могли быть переданы другому человеку. Шикарная задача, если разобраться!
MS>Да, задача хорошая. Но только вот беда — мне ей заниматься не интересно. Люди не по моей части, дайте мне железяки.
Хе-хе, как вариант, её можно представить в виде разработки нормативной документации (тоже часть инженерной работы). Здесь нюанс — обычно такую документацию пишут каким-то скулосводящим канцелярским диалектом. Попробуй написать то же самое, но живым языком, у тебя ж в принципе получается так изъясняться — того гляди, зачитываться ещё будут.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Vzhyk, Вы писали:
V>On 11.04.2013 14:17, bastrakov wrote:
>> детектирую опыт в индустрии не больше пары лет, и возраст до 27. V>Ну, вот только он в америках и зарплаты у вас сравнимы в циферках — у V>него правда в баксах в год, у тебя в рублях в месяц. V>Я так предполагаю, что у тебя около 100000.
Чем человек больше получает, тем он больше программист?