..и вообще..нет такого понятия как "младший" тестировщик, есть QA-engineer и Senior QA-engineer ...

Это Вы по своей компании судите? Количество позиций и их название зависят от штатного расписания. В каждой компании оно свое.

Даже в очень крупных организациях вполне нормально среди инженеров работает градация один ведущий инженер - много старших, а просто инженер - должность стажёра. Лично моё мнение тоже заключается в том, что более глубокие иерархии - не более чем выпендрёж или рисование шашечек.

Это Вы по своей компании судите? Количество позиций и их название зависят от штатного расписания. В каждой компании оно свое.

Даже в очень крупных организациях вполне нормально среди инженеров работает градация один ведущий инженер - много старших, а просто инженер - должность стажёра. Лично моё мнение тоже заключается в том, что более глубокие иерархии - не более чем выпендрёж или рисование шашечек.

Для мелких и средних фирм и команд - выпендреж.
Когда в проектной команде будет более - менее приличное число человек, ну скажем 150, такая градация может иметь смысл.

Какая, такая? Я говорил об иерархии в группе инженеров, которая позволяет им работать не отвлекаясь на аппаратную борьбу по крайней мере друг с другом. В крупных проектах, подразумевающих большой объём изысканий, я думаю, всегда проводится декомпозиция скоупа и формирование нужного количества групп. Сколько там звеньев управления над этими группами и каким должностям они соответствуют это уже второй вопрос.

Когда-нибудь Вы столкнетесь с темой мотивации.

Ну а чего тянуть-то? Может быть прямо сейчас и столкнёте? Чтобы я, значит, не прозябал в глупости.

Что ж, давайте попробуем пообщаться здесь.

 

Вы как-будто и не рады такой возможности? :) Или мне показалось?
Я считаю, что если прояснить некоторые моменты, то люди к вам потянутся сильнее. А как они узнают что моменты прояснены, если это сделать в тиши кабинета?

Я, наверное, невнимательно читал -- а что для Вас может быть существенным фактором для смены работы [и перехода в Яндекс], раз Вы уверены (если я Вас правильно понял) в собственной квалификации для этой или подобных вакансий?

 

Я кажется уже выступал на подобную тему в топике про кризис кадров.

Про существенный фактор для смены работы, это проще простого - отсутствие оной по каким-то причинам.

Про переход в компанию Яндекс - сложнее. Меня бы на самом деле ещё на берегу интересовало следующее:
- Почему для выполнения этих работ не привлекаются действующие сотрудники? Она считается непрестижной? Низкооплачиваемой? Не способны её выполнять? Она не считается важной для бизнеса? Созданы административные барьеры для перехода в группу? Ищется разводящий, чтобы на авось трансфертнуть ему ответственность и риски? Это сразу бы позволило оценить своё будущее место в компании не только мне (а ведь от такого позиционирования зависит и успех дела и реальность перспектив, которые Вы обещаете). Может быть ответ также позволил понять как было произведено ценообразование по данной вакансии, и удовлетворил бы многочисленных недовольных. :) Короче, такая декларация возможно позволила бы привлечь трезвомыслящих опытных людей.
- Почему перспективы роста до руководителя второй группы, рисуются перед соиcкателями, а не перед действующими её членами?
- Я прочитал в другом форуме, что на самом деле, те системы, с которыми предполагается работать, вторичны для компании. Может быть стоит акцентировать на этом внимание, и мандраж у многих начинающих пройдёт? Лично я, правда, действительно не считаю себя совсем уж начинающим, так что моё внимание лучше на это не обращать.

Так приходите, пообщаемся -- или вы уже на берегу убеждены, что захотеть не удастся?

 

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

матёрый специалист в нагрузочном тестировании web-приложений

Мне кажется, что справедливо было бы исключить одно из трёх выделенных италиком слов. ...

Ну отчего же ...

... я свои конкурентные преимущества буду отстаивать до конца.

Да, если вы ещё с нами ...

...

(оставлю пока без комментариев многие тезисы выше)

Ну так как там идёт мыслительный процесс?

Да, если вы ещё с нами ...

Тик-так.

... сравнивать тёплое с мягким просто бессмысленно ...

Но зачастую приходится. За деньги-то торгуется и тёплое и мягкое и серо-буро-малиновое. А денежная масса, она не бесконечна. :)

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

Может быть. В этом случае я возможно смогу себе позволить снова посыпать голову пеплом, как уже дважды сделал в этом топике.
Впрочем, я всё равно не верю. :)

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

Сложно что-то противопоставить такой прямолинейности. Желаю удачи.

возьмите ту же Goranka Bjedov

Я смотрел это выступление на видео раньше, и, насколько я помню, там упоминался предыдущий опыт в телекоме. Кроме того, мне показалось, я привёл агрументы в поддержку своего мнения о не особой перспективности специализации в нагрузочном тестировании решений базирующихся на LAMP, если смотреть с точки зрения профессионального роста. У меня есть и ещё, если хотите, я свои конкурентные преимущества буду отстаивать до конца. :)

давайте сформулируем, какую задачу мы с вами решаем.

Лично мне в Вашей вакансии никакие требования не мешают, тем более, что я и не собираюсь на неё подавать.
Мне мешает Ваше заявление, размещённое в открытом доступе, о том что "у вас в группе нагрузочного тестирования" (как позже оказалось, состоящей из одного человека), в головах такие червяки водятся, что обычные специалисты вам не подходят, а нужно обязательно матёрых, но только в вёбе (как будто такие и впрямь бывают). У простого читателя ведь что: может создаться впечатление, что "группа нагрузочного тестирования Яндекса" действительно знает, что она и зачем, и обладает достаточным авторитетом, чтобы судить какие специалисты хорошие, а какие - нет (при этом считая что БД там какая, или монитор транзакций, это так, фигня по сравнению с ихней могучей архитектурой). Мне распространение таких идей наносит потенциальные убытки, вот я и дискредитирую Вас как умею. :) Отзовите свой тезис о том что нагрузка на web это не начальный уровень мастерства и я от Вас тут же отстану.

...

 

По поводу Goranka Bjedov, предлагаю оставить обсуждение. Каждый может вынести из того выступления что сможет в меру своего опыта и испорченности. Лично я убеждать кого-то в своих историцистских гипотезах не намерен, хотя и думаю что стоит обратить внимание на эту деталь тоже.

По поводу архитектурных решений и их перспективности. По счастью в мировом ИТ по-прежнему на переднем краю разработок находятся транзакционные системы (с приличными требованиями к изоляции, надо сказать, которые в свою очередь диктуют объёмные общие области памяти и большое железо) и отчётность по ним. Это не только зарплаты, но и количество и качество усилий, затраченных на создание соответствующих технологий. Вёб-технологии которые обслуживают экономику контекстной рекламы, на мой взгляд, не так интересны с точки зрения нагрузки. Кроме того, они проще, и перейти, при желании, от них в промышленный мир сложнее, чем обратно. Особенно если опыт даже не в LAMP-е, компоненты которого иногда используются в приличных системах, а на самописном сервере приложений.

По поводу профилей на ваших системах. Даже если каждый хит засчитать за транзакцию (что было бы, конечно, читом), то результат получится далеко не впечатляющий даже среди систем работающих в России. Конечно, специфично, что типичный вёб-хит - это скорее выборка небольшого куска информации чем учёт операции, но нужен ли вам тогда действительно специалист по конкурентному нагрузочному тестированию? Может быть назвать эту должность как-то по другому и там уж рассуждать сколько влезет, что на рынке нет специалистов (а откуда им взяться, если вы своих сотрудников до этого уровня не научились поднимать) и т.п.? Лично мне намёки на какую-то особость работы в вёбе и в Яндексе и отсутствие соответствующих кадров, кажутся неумными, т.к. я людей, которые занимаются нагрузочным тестированием профессионально, видел порядка 10 в Москве (и мне даже кажется, что это несколько многовато), не говоря уже о тех, кто мог бы заниматься потенциально.

По поводу Oracle. Я тоже не люблю Oracle DB, но его OLTP-шный генезис общий с профессией которой я занимаюсь. Опять же, я думаю, Вам стоит подумать о том, что если OLTP инфраструктура "не тянет" ваши задачи, то и в бенефитах применения нагрузочного тестирования Вас через некоторое время тоже может постичь разочарование.

По поводу меряния выступающими предметами. Кластеров на сотни узлов я действительно не строил, т.к. они, в моём понимании, нужны именно для поддержки сессий большого количества одновременных пользователей, чего в реальных секторах экономики не наблюдается не только у нас. По всему остальному: количество бизнес-компонент (полдюжины это, кстати, мало, я в каком-то вашем же объявлении читал про codebase в 200 Мб); экстраполяция (пусть даже и неформальная, но зато проверенная на практике); масштабирование БД, я думаю, сравнимых с "социальной сетью" мощности множества сущностей и объёмов - такие задачи поступали, и так или иначе решались. И я там был и всех этих ананасов ел. Всё реально и без необходимости освоения xscript-а, надо только захотеть.

Забавно, но я думал что QA должен заниматся вопросами
связаными с изучением необходимости нагрузочного
тестирования и порядка проведения его, а не непосредственно
нагрузочным тестированием.

Мы все глядим в Наполеоны.

Ну и кто им мешал промоутить зарплату спеца по нагрузочному тестированию в этой вакансии? С какой радости среднестатистический кандидат должен где-то искать какие-то профильные форумы, чтобы найти зарплаты их разработчиков?

Я думаю, это от того что они никогда подходящего им нагрузочного тестировщика не видели (я вот например тоже не видел нагрузочного тестировщика с опытом программежа под posix на С и mysql, они все выросли из шинели продаж hi-end оборудования и соответствующего инфраструктурного софта) и не знают как оценить такого человека. Поэтому, кандидату предлагается назвать свою цену. Любознательный кандидат, может самостоятельно узнать чем они занимаются, догадаться, каково будет его место в штатном расписании и определить, на что он может расчитывать. Остальных оценят по факту появления на горизонте.

Или Вас больше устраивает вариант "моя зарплата минус 20%"?

Нет, наверное, тот, кто всю жизнь спал и видел как бы попасть на работу в яндекс или очень активно ищет работу сейчас, сам все найдет. Но, судя по топикам на нашем форуме, это работодатели сейчас гоняются за работниками, а не наоборот.

Все за всеми гоняются.

Я не понимаю что значит тестирование в продакшн.

Некоторые граждане иногда практикуют в этом направлении тёмной ночью со специальными дейтапулами. Но в данном случае я не говорил, что они _тестируют_ в проде. Насколько я знаю у них нагрузочного тестирования сейчас нет и оно на самом деле не особо им нужно.

Ну значит какие-то самописки используют. Совсем без автоматизации ведь нельзя. Опять же кому-то из потенциальных кандидатов это не важно, а кому то важно.

Тут есть важный моральный аспект. Самописки приносят доход местным работникам, а не воротилам из корпораций. И стоят дешевле.

Я думаю, что все гораздо проще. Смущает, скорее всего, полное отсутствие какого бы то ни было упоминания о компенсационном пакете вообще и об уровне предлагаемой зарплаты в частности. А все эти маршрутизации, сетевые протоколы и прочие технические заморочки это уже все вторично. Как говорится, ежика голой попой (даже очень большой) не напугаешь.

На самом деле зарплаты ихних разработчиков известны и активно промоутятся на профильных форумах. Я думаю, если показать аналогичную компетенцию, то и компенсацию можно тоже потребовать аналогичную. "Аналогичная компетенция", я думаю, может включать в себя С, gdb и нечто, остроумно названное на другом форуме "видеть race conditions прямо в коде".

Меня бы, кстати, еще очень смутило, что вообще не упоминается никакой специализированный тул, связанный с нагрузочным тестированием. Не на коленке же они все свое хозяйство тестируют.

Они его не тестируют на изолированном тестовом стенде, ихняя специфика позволяет смотреть что происходит прямо в проде. Ну а по поводу тулов. Если послушать выступление гирлы из гугла (тут пролетало на этом форуме), то они тоже не используют тулов, т.к. при использовании открытых протоколов это просто не окупается даже в масштабах крупнейшей компании.

Только вот тестирование производительности не заключается только в том чтобы получить показатели производительности при производственной загрузки, причём уже _во время_ эксплуатации. Вот такая вот незадача.

Туманно как-то изъясняетесь. Может быть поделитесь отраслевой статистикой отношения количества найденных нагрузочных дефектов и соответствующих инцидентов в проде, если такая конечно существует и Вы ей обладаете? В подтверждение Вашей приоритезации целей нагрузочного тестирования, так сказать.

Они его не тестируют на изолированном тестовом стенде, ихняя специфика позволяет смотреть что происходит прямо в проде.

Прошу прощения, откуда такая информация? В прошлый раз, когда мы были в гостях у Яндекса этот вопрос обсуждали и информация немного другая.

Да, тут я конечно погорячился с конкретикой. Что они там тестируют и где, этого я конечно не могу знать наверняка. Всё моя глупость. Мысль заключалась в том, что уникальная близость эксплуатации позволяет для работающих продуктов получать с мониторинга те же результаты (причём намного более соответствующие действительности), что даёт нагрузочное тестирование (ну, кроме прогнозных).

матёрый специалист в нагрузочном тестировании web-приложений

Мне кажется, что справедливо было бы исключить одно из трёх выделенных италиком слов. :) "Чистые" массовые вёб-приложения с html-ным передом, с не особо транзакционным задом - это не та задача, на которой можно заматереть в нагрузочном тестировании, ИМХО. Просто хотя бы из-за достаточно популяризованного протокола и понятности предметной области.

В подтверждение Вашей приоритезации целей нагрузочного тестирования, так сказать.

Не надо подменять понятия Я достаточно чётко в противопоставление ваших слов о том, что:

Они его не тестируют на изолированном тестовом стенде, ихняя специфика позволяет смотреть что происходит прямо в проде.

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

Ещё раз повторюсь, я действительно выдал предположение за факт. Извиняюсь.

По поводу целесообразности "посмотреть как оно будет жить в продакшене" это на мой взгляд интересная тема в данном случае. Но ей здесь, наверное, не место, а стартовать свои топики я пока не готов.

А после полугода программиста выгонят что ли?

Ну QTP-шника-то ведь тоже не выгонят.

Хочется выстроить понимание, что все мы работаем не для себя, не для абстрактного идола под названием Качество - мы работаем в IT, мы работаем для бизнеса.

О как.

-------------------------------------------------------------------
Даже если отвлечься от госзаказов, "бизнес" - это всего-лишь одно из средств организации улучшения качества жизни, но никак не самоцель.

А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.

Какие артефакты нужны, названия? Почему их просто нельзя подготовить без предварительного существования процесса? Для функционального регрессионного автоматизированного тестирования.

Сами тесты. Это артефакты, получаемые в процессе. Существование процесса тут обязательно, так как тесты получаются, когда пройдены активности Анализ - Проектирование - Дизайн, которые уже формируют некоторый процесс как плановую, упорядоченную активность. Только после дизайна есть чего автоматизировать.

Т.е. я пришёл, выполнил анализ, проектирование и дизайн (например один вообще, сам, а кто мне может помешать?), это сформировало процесс, который необходим для старта автоматизации. Я удовлетворил необходимому условию наличия процесса для начала автоматизации из первой обсуждаемой статьи (в случае, если я изначально держал в голове именно такой план). Я всё правильно понял?
Просто возникает вопрос, а согласны ли Вы с первой обсуждаемой статьёй? Вот цитаты:
"Для внедрения автоматизации тестирования ПО необходим ... зафиксированный и работающий процесс тестирования"
"Процесс тестирования должен существовать, работать, поддаваться изменениям и анализу, а для этого процесс должен быть зафиксирован письменно и любые процессные изменения должны фиксировать тоже письменно. На процесс, который строится, ставить автоматизацию сверху нельзя – развалим."

Ваш вопрос звучал так

Кстати, я просил сравнить живой и мёртвый процесс с точки зрения пригодности для автоматизации тестирования, в Вы мне говорите, что разница между ними в жёсткости основы. Только я не понял, какой из них полагается более жёстким?

Я указал, что действующий процесс находится ближе к этапу автоматизации, нежели только оформленный на бумаге.

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

Тут вот в голову пришла такая модельная задачка, чтобы вы могли лучше проиллюстрировать свои мысли:
Допустим у меня есть существующий работающий процесс регрессионного тестирования, я хочу внедрить автоматическое нагрузочное. Что из существующего процесса я должен для этого взять, без чего нельзя обойтись?

Только не совсем понял как это к теме "когда и при каких условиях надо внедрять автоматизацию". Я без наезда, просто или я не до конца понял вашу мысль, либо это уже просто ветка ушла в сторону.

Что именно непонятно?

Ошибки в коде бизнес-логики очень дороги, я думаю, любой, кому приходилось их исправлять, согласится, что это сложнее (отнимает больше времени) чем поправить визуалку или разобраться с интерфейсом чужой библиотеки. Это происходит от того, что такие дефекты приходят нелокализованными (если не позаботиться заранее, то непонятно в каком месте кода ошибка или неочевидно сразу как её исправить, зачастую даже когда есть стек-трейс, а его может не быть, просто заведётся сколько-то неправильных проводок), а для их повторения требуется окружение с реалистичными данными и иногда интеллектуальная интуиция. Поскольку они дорогие (в том числе репутационно из-за неопределённости сроков исправления), на них важно концентрироваться в первую очередь. Во многих типах систем (ядро АБС, биллинг) GUI тулы и ручное тестирование через GUI для этого оказалось малоэффективным (моё личное мнение). При обеспечении их качества надо начинать с тестирования компонент, реализующих бизнес-логику, не потому что это сокращает затраты, а потому что это фактически единственный путь добиться результата вообще (для бизнес-систем, например, уверенности, в том, что счёт внутри ведётся правильно в любом случае, а не только, если проводка введена через GUI, и не придётся потом кучу сторнирующих проводок вводить после массовой загрузки).

Т.е. я фактически поддерживаю тезис SALar-а "автоматизированное тестирование это не только и столько тестирование через GUI, но в первую очередь модульное и компонентное тестирование", каковой (тезис), кстати, значительно реже появляется мне на глаза, чем оголтелая реклама методологий, претендующих на универсальность, и патентованных тулов. Лично для себя я его (тезис) обосновываю на основе размышлений над реестрами инцидентов, отсортированных по убыванию цены (тут, надеюсь, есть некая новизна в аргументации). А размышления эти обычно о том, как надо было тестировать, чтобы предотвратить появление таких инцидентов. Конечно, у каждого могут свои классы систем, свои реестры инцидентов и, соответственно, своя точка зрения, но далеко не все пишут об этом статьи с претензией на всеобщность.

Но ведь есть же и белые и серые ящики... Но это уже не вопрос внедрения автоматизации, а вопрос уровня, на который вы ее внедряете.

Ну так речь, как я понимаю, идёт о том, что некоторые тестировщики хотят делать автоматизацию (исключительно потому что это модно, приносит деньги и поглаживание по голове со стороны ISV), но не могут и не хотят делать серые и белые ящики (т.е. в некоторых случаях, когда с этого надо начинать, открыто саботируют качество). И возникает вопрос о том, нужны ли [такие] тестировщики для автоматизированного тестирования. ;)

Добавлю про unit-тестирование на этапе приёмки.

Даже если кому-то нечего делать, потратили кусок времени и покрыли unit-тестами код поставляемой системы - при чём сделал это не поставщик в процессе разработки (ради чего собственно практика и создавалась, на минуточку). Поставили стенд, запустили сборку. Не собирается, unit-ы не проходят. А у поставщика собирается - вот незадача. И система собранная из этого же кода работает.

Я не знаю, для чего уж там создавалась практика (Вы по-моему уже за процессами самой работы не видите), но само модульное тестирование - это тестирование - проверка: работает как надо/не работает. Если другого способа проверить этого нет, или он сложнее, то я буду использовать модульное тестирование. Подумайте сами, тестировались ли программы до того как появились пользовательские интерфейсы? :)