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

Да у Вас в Москве хватает и приличных работодателей. Нужен только ОДИН :)

Хорошая дискуссия. Поучаствую.
Ответ: нисколько, 0, ни минуты не должны "сидеть на одном месте". Это преступление, халатность и т.д. Представьте себе, человек работает за рабочим местом, руководитель спрашивает (возможно, провокационно, а может и просто не в курсе) "чем занимаешься?". Ответ "сижу" повергнет его в шок! (Если юмора нет, юмор не у всех есть). Новый работодатель не в курсе Вашей бывшей работы, но если, например, мне сказать, что "я просидел 1-25 лет", мой ответ будет простым - "замечательно, пришло время размяться, желаю удачи". "Массажером" уже никак я не буду.
Поэтому встаньте на позиции Вашего работодателя, а у него, на мой взгляд на Ваше сообщение, будут следующие:
Во-первых, подозрения вызывают сроки работы - т.е. на предпоследнем 2 года, на последнем 1, на новом 0,5? :) Это действительно Ваше слабое место. Говорите, что ушли, потому что работа была не в сфере ваших интересов профессионального роста. Что это значит? Предположим Вы хотите работать тестеровщиком это сфера Ваших интересов, а на Вас вдруг навесили обязанности по установке и поддержке эксплуатации продукта. Но Вы должны честно признавать причины, по которым ушли с предыдущих мест. В любом случае хороший работодатель проверит, и, если причина "надоело работать", она поставит на Вас крест.
Во-вторых, возможно, начальнику досмерти самому надоело, ему хочется перспектив, денег и т.д и вдруг Вы!!! Покажите, что Ваша перспектива отличается от его перспективы. Имеется в виду - руководитель ищет управленческого роста, специалист - профессионального.
В-третьих, очередная пафосная тирада в адрес фирмы, действительно бальзам на самолюбие руководства, ну даже если не бальзам, то Вас уже не сбросить со счетов. Узнайте до собеседования о фирме как можно больше.
А вообще на самом деле, главное - это желание работать в этом коллективе над решением данной конкретной проблемы в данной конкретной фирме на определенный (вполне возможно, до пенсии) конкретный срок, при этом обладая требуемыми навыками, вот это хочет услышать работодатель.
И мой Вам (в смысле любому) совет - не работайте там, где ответ - хочу больше денег - воспринимается в штыки. Бывают разные времена у фирм, но если материальный интерес работников идет в разрез с интересами руководства - фирма обречена и работники вместе с ней, в конце концов, в ней соберутся одни неудачники. А от кого в первую очередь избавляются неудачники? Кого они обвинят в своих неудачах (а их будет достаточное количество)? Оно Вам надо?

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

После второй ошибки могут просто душу вытрясти. Потом помогает только аутотренинг :)

Спасибо,
мне понравились "ОСНОВНЫЕ ДОЛЖНОСТНЫЕ ОБЯЗАННОСТИ ПРОГРАММИСТА".

Отличная команда программистов ищет тестера.

А босса и МП уже нашли?

Вообще-то мы не то чтобы подошли, а партизанскими способами осуществили подмену темы -- вместо ответа на простой и понятный вопрос (цитирую Светлану): "что Вам дает уверенность, что ошибок [в выпускаемом продукте] нет вообще?",

Заданы конкретные вопросы. Ответы сложны и требуют рассуждений.

Виктор предлагает нам пафосные высказывания по поводу уверенности в себе, в своей команде и т.п.

Это идет в разрез с чьими-то интересами? Чем же это плохо?

Я бы квалифицировал это как увиливание от ответа :)

Неправда, я написал 7 (!) четких методов. Хотел увильнуть потому как не хотел навязывать системное видение, но не удалось :)

Я бы предложил сразу начать с выращивания роз. Умение тестировать корнями :) уходит в умение наблюдать и анализировать поведения объектов. Наблюдение за живой природой с практическим применением, не это ли лучшая школа тестировщика?

Во всяком случае, мне они 100%-ной уверенности не дают :)

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

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

Вот, Сергей, люди должны развиваться, этого жаждет руководство

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

Очень хотелось бы понять, чем руководствуется начальство, когда поручает решение стратегических вопросов не совсем компетентным людям?

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

:ph34r:

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

Браво, Viktor!
Вы, как истинный партизан, не выдаете тайны ни при каких обстоятельствах!
B)

Но Вы сильно меня заинтриговали и, наверное, не только меня.

Где же Вы работаете и что производите?
Единственное предположение, которое я могу сделать, Вы работаете в компании - системном интеграторе, т.е. Ваша компание скорее не разрабатывает ПО, но адаптирует его к нуждам заказчика и поставлеет в комплексе с "железом".

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

О терминологии говорили в теме "Verification & Validation - что это такое?".

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

Т.е. ранее Вы говорили о доле вероятности.

Все верно, но там я рассматривал частный случай - верификация программного продукта.
Мысль была какая, имеется некая одна высокая оценка качества какого-то артефакта, она снижает вероятность получить некачественный продукт (не программный! комплекс: программа+услуги).
Чем больше внутренних артефактов оценивается, и оценки выше, тем менее вероятность получить некачественный продукт. Если мы начнем оценивать процессы создания, то еще уменьшаем вероятность дефектов. Те рассуждения общие, это работает в общем, ни каких конкретных применений. (Причем, в ходе той дискуссии Анатолий намекал на узость нашего понимания этих процессов, поэтому здесь я просто привел общий термин, без всякой конкретной привязки к какому-либо виду деятельности или процессу)
А конкретная ситуация следующая - во-первых, эти оценки должны быть экспертные, во-вторых, здесь не может быть каких-то промежуточных состояний например "готовность 70%" или "вероятность возникновения ошибки 0,10", артефакт либо готов, либо нет, и в третьих, ответственность - персональная.
И опять же метод оценки топ-менеджментом - не объективен (в любой организации, в нашей точно). Я - сторонник объективных методов, но я не топ-менеджер.
Еще раз повторюсь - это очень затратно по времени и экономически необосновано, однако успешно работает.

А теперь повторю вопрос: что Вам дает уверенность, что ошибок нет вообще?

1. Аутотренинг. (Спасибо, Алексей!)
2. Контроль процессов разработки.
3. Оценка артефактов
4. Тестирование программного продукта (его можно и выше, но пусть тут)
5. Налаженная процедура разрешения проблем.
6. Следование стандартам и методологиям
7. Персональная ответственность перед заказчиком
Вот семь моих субъективных методов повышения уверенности в отсутствии ошибок в условиях моей корпорации. Может что-то пропустил.

Вы упомянули верификацию. Что Вы имели в виду -- динамическую верификацию (в просторечии называемую тестированием) или формальную проверку правильности программы?

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

Вообще-то Вы не должны быть согласны, потому что у Вас нет необходимости оценивать, сколько осталось :)

Удивительно, но я согласен с Вашей позицией, просто в этом отношении мне "повезло" больше :).

Viktor,
допускаю, что между Вами и Вашим топ-мереджером происходит следующий диалог:
ТМ: - Продукт готов?
V: - Готов!
ТМ: - Смотри, головой отвечаешь!
V: - Дык, тык, мык, как всегда!
ТМ: - Тогда запускай!

Конечно, не так поэтично, но общий смысл понятен.

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

Объективные доказательства. Какие? - не скажу, наверняка, скажете, что - это религия.

Как то незаметно дискуссия разделила всех на два лагеря - тех, кто считает найденные ошибки, и тех, кто считает оставшиеся.
;)

Я отношу себя к третьему лагерю -- тех, кто считает и то и другое.
Более точно: считает, сколько найдено, для того, чтобы оценить, сколько ещё осталось.

Согласен

Главный принцип - верификация любого продукта в любой стадии, будь то проектная модель, ТЗ или код программы. Что это значит? Например, если при тестировании, выявилось какое-либо непонимание исходных требований, значит возвращаемся к стадии анализа. Ресурсоемко, затратно по времени, но зато качественно.

А если, не дай Бог, не выявилось? Если пропустили, недосмотрели? Что тогда?

Бывает, что же делать, прыгаем дальше, пока не будет качество.

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

Допустим, Вы уверены, что понимаете все исходные требования. Допустим, тестирование прошло успешно. Что дает Вам уверенность, что ошибок нет?
Без привязки к конкретным условиям.

Верификация

Спасибо за совет.

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

Короче говоря, что хотят, то и делаем :)

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

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

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

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

Не имею ничего против религии, более того, сам религиозен, но Богу -- Богово, а кесарю -- кесарево.

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

Поймите, даже имея объективные доказательства, можно оценивать их субъективно.
Как это получается? Вот у меня есть все объективные доказательства, результаты испытаний, оценки моделей, какие-то результаты аудитов, мнения конечных пользователей, всевозможные матрицы и диаграммы. И я говорю руководству "продукт готов", и более того начинаю верить в это. Это объективно?
Зачем мне для поддержки моей субъективной оценки приводить руководству объективные доказательства? Ему это не нужно. Все уже оценено и измерено техническими специалистами, которые выносят свои субъективные оценки. Какой ему смысл что там есть ошибки? Есть четкое требование - ошибок не должно быть вовсе (здесь довольно утрированная интерпретация).
Теперь можно и наоборот позицию рассмотреть:
Есть пользователи продукта, их два человека. Их мнение что продукт готов, объективно? Смогут ли они нанять третьего для внешнего аудита?.
Основная проблема при создании ПО - неполнота требований, и изменения технологий. Поверьте моему опыту, другие вопросы не так существенны. Даже если у вас студенты пишут программы, это не проблема. Она никогда не возникает перед руководством. Кто мешает менеджеру проекта подключить к нему лучших из лучших? Никто.
Поэтому внутри больших корпораций все четко, все знают что делать. Корпорация не поедет внезапно в другую сторону. Технологии не меняются внезапно. У корпораций есть ресурсы снизить за их счет риски. В корпорации учат людей быть ответственными. Если ты безответственнен, всегда есть возможность подвинуть. В корпорации очень трудно скрыть халатность.
Ну а уж полноту требований в корпорации обсуждать не приходится. Можно выдернуть из процесса любого ключевого пользователя, руководителя любого уровня и добиться от него любого уровня описания требований.

Ну что же, интерес вполне обоснованный и сомнения тоже.
Экспертная оценка, нормальный метод. Мы работаем в команде. Команда профессиональна. Если у кого-то есть сомнения в качестве, продукт не поставляется. Время не имеет значение, ресурсы - тоже. Качество - имеет значение. Работаем, пока все сомнения не устранены.
К Алексею: верю (хотя, я привык сомневаться во всем, как-то я уже это писал, видно к работе это не относится). Вопрос в другом, верит ли мне менеджмент? Не знаю, но если я (или другой ответственный специалист) сказал, что продукт готов, ему этого достаточно (Значит верит?).

Виктор, вопрос именно в том КАК Вы определяете, что ошибок НЕТ? Никакая оценка не даст такой гарантии на 100%.
Что именно устраняет все Ваши сомнения?

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

У любого действия должен быть смысл.
В исходной, непротестированной программе возможно есть ошибки, не спорю. Возможно, есть и другие нерешенные вопросы - дефекты. Но продукт выпущенный нашей командой от них свободен. И в это я должен верить, потому как необоснованные сомнения раздъедают личность. А теперь представьте, что моя уверенность (человека, привыкшего все подвергать сомнению), или правильнее уверенность нашей команды, разве не является объективным доказательством?
Мой совет, любите не ВСЕХ женщин вообще - бесполезно, любите своих женщин, и они ответят Вам взаимностью.

Ну что же, интерес вполне обоснованный и сомнения тоже.
Экспертная оценка, нормальный метод. Мы работаем в команде. Команда профессиональна. Если у кого-то есть сомнения в качестве, продукт не поставляется. Время не имеет значение, ресурсы - тоже. Качество - имеет значение. Работаем, пока все сомнения не устранены.
К Алексею: верю (хотя, я привык сомневаться во всем, как-то я уже это писал, видно к работе это не относится). Вопрос в другом, верит ли мне менеджмент? Не знаю, но если я (или другой ответственный специалист) сказал, что продукт готов, ему этого достаточно (Значит верит?).

Я просто представил себе на минутку, что оставил пару ошибок в программе, и честно заявил об этом руководству. Оно мне памятник воздвигнет нерукотворный.
Или, лучше - я не заметил пары ошибок, но они скорее всего есть. И я об этом честно скажу. Последствия будут ужасны. Кошмар!!!
Пока существует хотя бы минимальная вероятность остаточной ошибки, продукт просто "не готов". Вот такие они - требования внутреннего ПО.

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

Почему Вы думаете, что эта строка должна быть в VP? У Вас не получется легко изменить данные VP.
Но вот если что-то откуда-то прочитать и с чем-то сравнить и результат сравнения провести через VP(если есть такая необходимость), то это вполне прокатит. Хотя результат сравнения можно и сразу запротоколировать.