..и вообще..нет такого понятия как "младший" тестировщик, есть 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, мы работаем для бизнеса.

О как.

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

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

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

Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.

Неужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".

Про то что в первую очередь, а что во вторую я бы поспорил.

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

Unit это вообще не к тестерам

Интересно даже стало. Это отражение нежелания или неспособности?

это holy war, пока никто не возьмётся что-то подсчитать в цифрах

А если качественную оценку поставить на место - перед количественной. Вы же специалист по бизнес-приложениям и работали на системах с пакетной обработкой, понимаете, что просто нажать кнопку старта недостаточно. Неужто в этом случае работа только через GUI - самый оптимальный вариант, если отвлечься от цены. И так ли уж редка эта ситуация? А системы отчётности, через GUI, без парсера отчёта?

Про unit-ы.
Я не хочу зацикливаться на определении unit-а, но книгам тут я верю меньше чем людям, с которыми работал: я видел как девелоперы по разному определяли что есть unit даже в рамках одной проектной команды, видел как каждая функция "заворачивалась" в код вызова или как целый модуль, который читает из базы, обсчитывает (дёргая 2-3! других модуля) и пишет обратно в базу тоже обзывали unit-ом и писали целый пакет тестов (со своим доступом к данным), который на входе даёт ID-шку абонента, а на выходе сам же считывает контрольный ответ из пакета подготовленный руками контрольных наборов данных.

Повторю - это должно делаться разработчиками.

Про тестирование на уровне бизнес-модулей.
Основная или базовая функциональность (то что замыкает бизнес-цикл: закрытие периода, перерасчёты, выставление НН, пени и прочей лабуды) зачастую тестировалась внутренней разработкой. Мы делали свои фреймворки, которые дёргали через удалённые вызовы торчащие методы, заменяя по сути вызовы клиента и интерфейсов в другие системы. Отчёты не парсили (ну его нафиг этот "кристалл"), а собирали из базы по опорным точкам на основе бизнес-правил: банально, чтобы например внутри сети электроенергия не возникала.

Unit-тестами этот слой - я бы назвал это тестированием бизнес логики - не покрывается. Средствами record-playback зачастую тоже в основном из-за сложности проверок получаемого состояния. Либо руками, либо создаваемыми отдельно для тестовых нужд приложениями (фреймворками).

Теперь моя очередь пришла тупить и притворяться пеньком. Это что, была аргументация в пользу утверждения "да, встречаются проекты в которых невыгодно или неэффективно автоматизировать через средства record-playback. Но к вопросу внедрения автоматизации тестирования такие исключения зачастую не относятся"?
Вообще, у меня к этому отрывку замечаний нет, я со всем согласен, но хотел бы обратить Ваше внимание на следующие обстоятельства:
1. Оказывается что в Ваших прошлых проектах кто-то ведь делал часть работы по обеспечению качества продукта ("это должно делаться разработчиками", "зачастую тестировалась внутренней разработкой"). Причём, Вы не умеете определить этот вклад количественно. Вы как-то учитываете это теперь, когда стали "дорогим консалтером" и вроде бы собираетесь нести ответственность за весь спектр? Хочу напомнить, что тестирование и автотестирование - это не самоцель.
2. Вообще говоря, в процитированном отрывке описана автоматизация того, чего не существует. По крайней мере, можно себе представить (лично я могу вспомнить) случаи, когда это справедливо.
3. Рискну предположить что дохлые лошади именно так и получаются - делается ставка на тестирование через GUI, когда критические с точки зрения качества продукта участки кода доступны только синтетически, люди чувствуют что занимаются фуфлом и перестают работать. При том подходе, который вы описали в процитированном отрывке, я могу понять как лошадь может получиться и как - не получиться, но как она может получиться дохлой - нет.
4. Всё что вы описали не обязательно делать в процессе разработки, всё то же самое может понадобиться проделать при приёмочном тестировании (если понадобится, и unit test тоже). Т.е. непонятно, что может объективно помешать этому, кроме слепой веры в то что "так не делается". Разумеется, делать это должны квалифицированние люди - "разработчики".
5. Непонятно также, при чём здесь процессы? Вот представьте самую плохую ситуацию (кошмар KaNoN-а): вы - аутсорсер, приходите к заказчику, вам дают стенд и какие-то доки, можно спрашивать у разработки, и надо автоматизированно протестировать какую-то функциональность (неважно даже, доступна она через GUI или нет). Какие после это Вам ещё нужны процессы чтобы были у этого заказчика? Можно список, в нём плюсиками отметить те, становление которых Вы случайно можете разрушить неверным движением, внедряя автоматизацию, и звёздочкой - такие, что Вы без них откажетесь работать, а будете требовать, чтобы владельцы бизнеса немедленно взяли под свой личный контроль их внедрение.

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