Что не так в объявлении или ....???

по рынку з/п нормальная.. нижнаяя планка, далее по результатам гтовы платить выше рыночной, но откликов мало..:(

требуется архитектор/тимлид на интернет проект(Пиринговая сеть).
Обязанности:
разработка архитектуры приложений, создание и управление командой ориентированных на результат программистов,
Требования:
Обязателен опыт программирования на разных языках/платформах, опыт разработки кроссплатформенных приложений на С/С++, разработки архитектуры распределенных, работающих под большой нагрузкой приложений.
Желателен опыт руководства командой разработчиков.
Рассмотрим резюме опытных программистов без опыта управления людьми.
Зарплата от 2000$ до 3000$

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

Соглашусь с KaNoN - очень похожи на других.-

Ребята помогите! Что входит в обязяности QA Analyst? Чем эта позиция отличается от позиции обычного тестировщика. Как с точки зрения карьерной лестницы рассположены (относительно друг друга) эти должности. Заранее всем, спасибо, за любую информацию по теме.

Мы говорим про Quality Assurance или про Software Testing/Software Quality Control? Давайте не путать внедрение и отладку процессов и само тестирование.
QA_Kiev уточните вопрос.

От себя добавлю, что обычный тестировщик НЕ должен заниматься составлением планов тестирования, документацией процессов и метриками.
Это другой объём работ и соответственно другая зарплата.

Согласен.

А в этом случае что? Уже получается что тестер вовсе не тестер, а аналитик? Это я правильно понимаю, что такое бывает.

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

Ох... Я вижу Вам пора писать свои публикации. :-) Это уже напоминает переписку в двух томах.

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

Слава,
спасибо за комменты,

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

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

1. Если долго и нудно - значит плохой начальник.
2. Если Вас это не интересует - значит вы теряете очень много в своей жизни.

Небольшой коммент по фразе:

Страшно представить Ваш основательный коммент.

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

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

На самом деле не так уж и мало - это типично для всех компаний которые не предназначены для производства ПО, а так же его тестирования. Они изначально создавались для тайных целей работодателей (например банально отмывать деньги под видом разработки ПО). Могу Вам в личке привести примеры Киевских компаний, если интересует.

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

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

"подкалываю" - сочтемся.
Вас не удивляет почему, время от времени, люди приходят на этот самый форум с вопросами "как мне сделать то что заведомо не делается" ил "как мне спрогнозировать работы если нету ничего кроме билда?" или просто излить душу. Потому что не спрашивают, а почему так происходит. Потому что просто сидят и делают. А когда поднимают голову, то видят что они уже не по уши в болоте а, пару метров под уровнем поверхности. Иногда в этом винят руководство, хотя САМИ НЕ ЛУЧШЕ, иногда посыпая голову пеплом сидят и работают по 12-14 часов. Зачем? Вы можете ответить? Но главное не это. Главное почему так произошло. Почему берется проект и делается без процессов, с недостатком ресурсов, с урезанным бюджетом. В надежде на идейных работников?
На счет "нетипичен" - иногда жаль... Я не призываю всех увольняться. Если Вы сразу не наладили нормальную работу, потому что Вам не дают это сделать, тогда надо что-то менять. Либо работу либо мировоззрение. Если поменяли второе, тогда никогда не кричите что начальник тупой или жадный.

Если не трудно - поделитесь опытом (я больше чем уверен, что у Вас тоже были такие проекты) - как Вы выходили из таких ситуаций ? Это не "вопрос-подколка". Мне действительно интересно знать - как в условиях кризиса ресурсов (не важно, по каким причинам) можно выйти из подобных ситуаций ?

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

На мой взгляд стоит открыть отдельную тему. В двух словах есть задача и есть реальность. Если они не сопоставимы то надо что-то менять. Это простая трейд-офф модель (модель по согласованию основных параметров). 1. Время, 2. Объем, 3. Ресурсы. Если что-то не вписывается, то ПРЯМО влияет на остальные два параметра. Вот с ними и играйтесь. Нет нужного времени - увеличивайте ресурсы или уменьшайте объем. И на оборот.

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

Зачем вам иметь мануал по которому "может быть" получится?

Я пока не смог определиться в области (как я себе ее сам называю) экстремального тестинга.

По процессам работать легко, особенно если они настроены, а даже если они и не настроены - то столько док-ции, что и идиот сможет создать любой процесс.

Намного сложнее заставить всех понять - что по ним надо работать (в основном - кастомера), и самый высший пилотаж - это суметь работать по любым процессам независимо от всех приколов с ресурсами, руководством, кастомером и т.д., т.е. по принципу "QA must go on"  (только не надо мне говорить про "уволиться" :)) на таких проектах.

И даже не собираюсь Вам говорить про увольнение (хоть и чувствую еще один подкол ).
Нельзя быть независимым от приколов. Надо уметь занамться tailoring (tailor - приспосабливать для определенной цели, в нашем случае подстраивание процесса под нужды и особенности проекта)

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

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

Кстати, Вы говорите про барьер по возрасту снизу или сверху?

Например, по людским ресурсам, в другой статье
http://www.qaexpert....development.htm
написано: "Иначе Вы можете потратить очень много средств на дорогого консультанта, пока будете выяснять что же Вам от него надо. Это Вам обойдется недешево, зато в результате Вы можете нанять не очень дорогого и сравнительно молодого специалиста".
Вот здесь слово молодого можно убрать и уже получится дополнительное решение. Видел как взяли в тестирование человека возрастом за 50 лет.

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

Спасибо Александр. Уже даже за то, что Вы столько написали, за это отдельное спасибо.

Спасибо,
интересная публикация.
В общем - ничего нового, но тут все систематизировано и хорошо представлено. Спасибо.

Единственный коммент по части:

"Сроки на тестирование заведомо недостаточные (безобразное руководство)
Как убедить руководство, что надо больше времени?"

Рад что для Вас тут нет ничего нового...
То как вы поняли "Сроки на тестирование заведомо недостаточные (безобразное руководство)", на самом деле вы описали раздел "Нет возможности добавить ресурсы". + В описании данного случая указывается что если причины есть нормальные, например: пилот и мы получим много проектов если получится, или ребята, это начало стратегического сотрудничества. Тут все понятно. Я же описал ситуацию, когда "А потому что сразу не продумали, или еще хуже, не захотели тратить времени и средств" - это типичная проблема везде, когда берешься не за свое дело, а если, при этом, нет желания его делать, то результаты прогнозируемы и очевидны.

Вот в этой ситуации и приходится выбирать: самый простой вариант (и самый 1-й в списке) пойти и обоснованно доложить руководству - что есть вот такие проблемы и приемлемое качество обеспечно не будет.

Я бы сформулировал иначе. "Требуемое" качество обеспечено не будет. Или вот так, будет покрыто тестами 60% программы. Ну вот где-то так.

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

Основная мысль, красной нитью, если руководитель нормальный, то он прямо скажет о причине такого "ведения" проекта.
Тогда решение о смене компании - не единственный вариант.

В этой ситуации единственное, что может спасти проект в части QA (если не считать случая, когда вообще от него отказаться или уволиться) - это перераспределение ресурсов QA между проектами так, чтобы на таком проблемной проекте оказались "сливки" QA команды, которые обладают огромным опытом и некоторыми "ведическими" знаниями в области тестинга - это может хоть частично компенсировать нехватку времени, отбросить некоторые несущественные формальные процедуры процесса обеспечения качества, максимально минимизировать время на менеджмент тест кейсов, баг трэкинг и максимально сосредоточиться на анализе требований и очень тесной кооперации с девелоперами. Уже один грамотный анализ требований может на во время 1-й недели проекта отсечь порядка 30 % проблемных и бажных мест (проценты взяты из собственного опыта).

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

Может помочь, а может завалить все остальные проекты. Это как вам повезет со "сливками" и наличием других проектов (я уже не говорю про наличие самих "сливок" и их уровень)

И еще вы предлагаете переложить проблему на плечи тестера?

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

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

Про опыт согласен на все 100%... Однако не стоит никогда обещать того, что не можешь сделать. И разговаривать надо на уровне того что можешь предложить, а не того, что хотел бы предложить. Однако, это тема немного из другой плоскости.

а вообще было бы интересно - может кто-то еще поделится опытом - как решать задачи QA в условиях явного недостатка ресурсов (как временных так и людских).

спасибо,
Александр

и Вам спасибо.

...

Кстати, пробовал я тестировать сам ручку, протестировал около 50 ее свойств.

Это много или мало?

В этом случае кандидат должен очень хотеть устроиться к вам на работу.

+1

Смотрите не отбейте желание у человека вообще работать тестировщиком.

Вопрос: а у вас отдел по работе с персоналом есть? Они разговаривают с человеком перед вами?

Хотел бы добавить, что не стоит ждать только от кого-то чего-то... Надо и самой учиться. Главное понять за что боремся... Если серьезное рвение то можно показывать делом. Например посмотреть, можно ли автоматизировать тот участок работы который Вы выполняете. Скорее всего можно. Вот и разберитесь. Опять же, вся ли документация совершенна (скажу по опыту, далеко не всегда), если есть что поправить и где изменить или добавить вперед. Вобщем смотрите, что вы можете сделать своими силами. Если Ваш лид не слепой, он все увидит... А вот когда вы пойете что вы это можете (не обязательно ждать пока Вы все переавтоматизируете или перепишите) сразу прямиком к начальнику... И у вас уже будет тема для разговора...

Мне почему-то кажется, что основа не очень-то меняется. Если мы воспитываем девелопера, то обучить его должны программированию, а не "разработке баз данных в среде Delphi". Основные методологии, алгоримы, подходы изменяются с вполне приемлемой скоростью.

А что входит в понятие "обучить программированию"? Можно раскрыть?

damp или dump?

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

На мой взгляд и не успеет. Даже если лучшие специалисты будут постоянно адаптировать курсы обучения, то риск того что они только этим и будут заниматься велик. А преподавать один курс больше 1-2 лет уже не актуально (это все равно что постоянно бежать за отходящим поездом). Курсы и факультативы помогают частично, скорее точечно (они отсекают тех кто интересуется, а те кому данный курс не интересен, они ни чему не учат). Мне кажется надо кардинальнее решать проблему. Я думаю тут надо больше практической работы давать студентам. Например на 5 курсе вообще освобождать от учебы и направлять на работу (прошу не путать с практикой). Именно на работу, а не за справкой о прохождении преддипломной практики. Можно и по другому, заключать с ВУЗами контракты, что бы студенты после учебы шли в лаборатории и занимались реальными проектами. Тогда есть шансы получить выпускников с хорошей базой... :-)
Я так себе думаю...

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

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

А почему просто не удалить пост? Это же обычный рекламный спам, имхо.

Как мне правильно ответили на такой же вопрос ранее. "А зачем? Пусть все видят как делать нельзя."

Статистика и сравнительный анализ:)

Из опыта знаю, что девушки, всё-таки, более внимательны, усидчивы, постоянны, последовательны, ответственны. Они по жизни придираются ко всему, что "не так", а это - ключевая черта хорошего QA.
Направление QA (а не только тестирование) подходит им больше.

Сильный пол всегда стремится переквалифицироваться в разработчика... Тем более, что в СНГ до сих пор не отошли от понятия "Тестер - тот кто не дорос до разработчика / без мозгов / тупой кликер и т.п." - грустно, конечно...

Добрый день.
Могу согласиться про терпеливость. но про все остальное... :acute
Хотя все зависит от проектов и их сложности. А иногда от руководителя.