Коллеги!

Приглашаю к сотрудничеству инженера по нагрузочному тестированию. Работа в свободное время.

Требований всего 2:
1. Опыт и навыки разработки тестовых скриптов и проведения тестирования посредством программы нагрузочного тестирования (желательно, бесплатной).
2. Возможность выделения 4 часов ежедневно на работу в течение проекта. Условие обязательное.

Работа периодическая, не регулярная.

Быстрее договоримся, если пришлете резюме.
Изъявлять свое желание на e-mail drQuality [что-то] drQuality [дот] ком.

Детали обсуждаются лично.

Буду рад любым кандидатам.

Ни то и ни другое.
Временно заморожен.
Но разморозка зреет.

А можно его разморозить?
Конкретно сейчас интересует перевод глоссария. Старые ссылки не работают (http://spreadsheets....w...F3yLA&gid=1), а копии глоссария у меня нет.
И именно сейчас она мне понадобилась.
Хорошо бы просто бросить личное сообщение с Excel файлом, если можно.

Хотя наверно есть/будут еще желающие, так что открытая публикация на Google Docs им понадобится.

Сейчас пошел посмотреть и оказалось, что действительно убрали такую фичу в Докс, как расшаривание табличных файлов. Блин! А было так удобно.
Если кому надо, могу выслать полуфабрикат pdf файлов (импорт в экселовский формат почему-то тоже не сработал).

И после проверки можем ГАРАНТИРОВАТЬ - имеются или нет между ними расхождения.

За исключением одного - гарантия отсутствия дефектов в программе. Ну что же, оставим хоть что-то.

Противоречие. Дефекты и есть расхождения.

В чем же здесь противоречие?

Если есть отличие реализации от спецификации, то это оформляется в виде дефекта.

Но в программе кода ВСЕГДА больше, чем того требуется по спецификации. Поэтому даже при полном совпадении реализации и спецификации всегда есть не проверенные места. Следовательно, мы не можем гарантировать отсутствие дефектов. Потому что мы просто не знаем - есть дефекты или нет.

Коллеги,

все дружно встали на защиту автора, поэтому я решил объяснить свою позицию.

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

ОК. Нет проблем.

Что же он предлагает взамен? Он предлагает исследовать программы и информировать о состоянии качества тех, кто принимает решение.

И с этим нет никаких проблем. Все верно.

Кроме одного.

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

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

И так практически по каждому пункту. За исключением одного - гарантия отсутствия дефектов в программе. Ну что же, оставим хоть что-то.

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

Или он будет делать что-то совершенно другое? В статье это не описано.

Резюме:

Если брать лозунг - нет гарантии отсутствия дефектов, то все правильно.
Но когда начинают отбрасывать стандартные методы работы, то стоит 10 раз подумать.

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

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

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

Коллеги,

должен вам признаться, что статья ни о чем.

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

Да пусть он считает себя хоть космонавтом или исследователем глубин космоса в стенах славной организации НАСА, что из этого? Лично мне это не дает никакой полезной информации.

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

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

Лично по мне, вся эта статья - игра в слова и не более.

Слава, ну ты, блин, конспиратор.
Написал бы по русски, для чего тебе это надо и все сразу бы поняли.

Со своей стороны могу скинуть ссылку на сообщество по тайм-менеджменту, которое организовал Глеб Архангельский. Там много всякого материала, статей. Уверен, ты там сможешь найти что-нибудь подходящее.
http://www.improvement.ru

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



Я вам так скажу.

Ну чего вы взъелись на девушку?! Ну, трудновато читать. Да. Есть такое. А что, все тут пишут идеально?

Ну не все фразы и термины однозначны. Так что из этого? Смысл то понятен.

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

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

Ну, теперь тестировщики стали выполнять еще и функции аналитиков. По идее требования должны улучшиться, работа должна улучшиться, продукт должен улучшиться. Ну и что? Это реально произошло? А заказчик это заметил? Есть от него отклик, что теперь стало лучше? Если нет, то и смысла все затевать не было.

И вообще...
У меня кризис среднего возраста и я все вижу в темном свете.

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

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

А вы говорите бабочки...

Вещь стоит ровно столько, сколько готов заплатить за нее покупатель.
Публий Сириус,
римский поэт, I в. до н.э.

Александр Смирнов рассказывал (весна-осень 2008), как он нанимал тестировщиков в Бегун. Не хотят говорит идти. Приходится объяснять. Будешь следить за качеством кода, проводить кодеревью, покрывать код тестами. Когда до людей доходило, что им предлагают очень ответственную и сложную работу - отношение менялось. Ну и зарплату они предлагали $4000. Обычному тестировщику. Не ведущему. Обычному.

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

Коллеги!

Престиж - субстанция нематериальная. Ее зарплатой не измерить. Землекоп на кладбище, например, профессия не престижная. Но попробуйте туда устроиться без серьезной протекции! И кризис им, кстати, не страшен.


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

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

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

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

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

Когда я написал "Цель любой организации - это то, что она дает своим создателям.", то имел ввиду, что очень часто в уставе организации пишут все что угодно, только не цель. Тем не менее цель определить очень легко. Все то, что учредители получают (или стремяться получить) - это и есть цель. Миллион? Значит цель - миллион. Если план развития экономики страны на несколько лет вперед, то с высокой степенью вероятности можно утверждать, что речь идет о министерстве экономического развития и торговли.

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

Слав,

так в чем проблема?
Если тебе эта мысль очеведна, просто выскажи ее.

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

Скажи цель, плз?

Здесь приведены некоторые из возможных целей:
http://software-test...amp;#entry64377

Когда я написал "Цель любой организации - это то, что она дает своим создателям.", то имел ввиду, что очень часто в уставе организации пишут все что угодно, только не цель. Тем не менее цель определить очень легко. Все то, что учредители получают (или стремяться получить) - это и есть цель. Миллион? Значит цель - миллион. Если план развития экономики страны на несколько лет вперед, то с высокой степенью вероятности можно утверждать, что речь идет о министерстве экономического развития и торговли.

Кстати, "приносить миллион в месяц с ростом n% в год" - это не цель, а план. В этом случае целью является повышение благосостояния владельцев компании путем извлечения прибыли посредством предпринимательской деятельности.

Цель любой организации - это то, что она дает своим создателям.
Миссия организации - то, что она привносит в этот мир (что она дает другим).
Главная задача организации - просуществовать до того момента, пока не будет достигнута цель.

Сказал красиво и... никак :) Цель-то в чем, Сергей?
Если цель - приносить деньги, то твое трактование задачи организации рассыпается, так как это не конечная цель "принести миллион", а состояние "приносить миллион в месяц с ростом n% в год".

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

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

Цель любой организации - это то, что она дает своим создателям.
Миссия организации - то, что она привносит в этот мир (что она дает другим).
Главная задача организации - просуществовать до того момента, пока не будет достигнута цель.

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

Следовательно, главная задача менеджмента (не цель!) обеспечить существование организации. Для этого они должны покупать дешевле и продавать дороже. Из полученного дохода покрываются: аренда, зарплата, налоги, реклама и т.п. Оставшиеся средства могут быть направлены на развитие: обучение персонала, ДМС сотрудников, расширение инфраструктуры и т.п. Из того что осталось, после всего, выплачиваются дивиденды собственникам.

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

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

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

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

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

Практический вывод:

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

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

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

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

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

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

Последние два абзаца :)

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

Хотя, возможно будет продолжение

Коллеги,

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

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

Кстати, я выложил запись доклада на веб-ресурс. Его (доклад), можно посмотреть на странице моего блога:
http://www.drquality.ru/?p=22

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

Необходимо различать цели компании, цели владельцев и цели инвесторов.

Организации бывают коммерческие и не коммерческие.

- Целью некоммерческой организации может быть любая альтруистическая цель. Например, спасение амурского тигра, создание вакцины от СПИДА, содействие поступлению в ВУЗ Петечкину Ивану Алексеевичу, 1990 года рождения. Для этого они могут заниматься коммерческой или/и благотворительной деятельностью. Просто все вырученные деньги (за исключением операционных расходов) направляются на достижение заявленных целей.

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

Я описал основные формы организация. Но существует огромная масса их разновидностей.

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

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

Доброго дня суток!

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

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

Есть ли нечто подобное? Зараннее всем благодарен!

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

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

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

Для таких задач есть специальные программы - ПО по управлению требованиями.

Для решения задачи (так как она сформулирована в постановке) можно посмотреть FogBugz. Или приспособить Wiki (но придеться поработать ручками).


"Зри в корень".
Кузьма Прутков.

Коллеги, извините. Отвлекся.
Постараюсь ретроспективно изложить основные мысли по экономике качества ПО и тестирования, в частности.


Посыл 1-й. Единый центр качества повысит удовлетворенность клиента и обеспечит повторные продажи.

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

Действительно ли нужно что-то предпринимать, что бы организовать такой центр?

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

Во всяком случае, в такой постановке задачи.



Посыл 2-й. Служба качества удешевит разработку софта или АС.

Часто, для подтверждения этой мысли показывают диаграмму зависимости роста стоимости от фазы выявления дефекта. Чем позже, тем стоимость дефекта дороже. ВСЕ ПРАВИЛЬНО! Чем позже, тем дороже. Главный вопрос современности - кто за это платит? А платит за это ВСЕГДА клиент.
(В подавляющем большинстве случаев - все риски несет плательщик.)

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

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

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

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


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

Я вижу только один повод - удешевление системы на стадии поддержки. Поясню свою мысль.

Предположим мы продали программу компании и она ей пользуется. При этом она платит нам за поддержку (как правило, за поддержку платят от 5% до 15% от стоимости самой системы). Чтобы осуществлять обновление системы и исправление дефектов нам нужно содержать фактический клон проектной команды. Нужен как минимум один специалист, знающий систему и способный не испортить ее. Так же нужна вся инфраструктура по поддержанию разработческой и тестировочной версии системы. Чем масштабнее (крупнее) программа или система, тем большего внимания она требует. Зачастую необходимо содержать не одного программиста, а целый штат - бизнес-аналитиков, тестировщиков, специалиста по ДБ, да еще менеджера по управлению всем этим кагалом. В результате затраты по поддержке системы не сильно отличаются от затрат по ее созданию.

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


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

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

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

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

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

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

4. Эффект правды.
Когда руководство компании получает отчет от руководителя проекта о состоянии дел в проекте, то оно видит не всегда правдивую картину. Чаще всего представляется желаемое положение дел на проекте. Отчет тестировщика - это снимок реального положения дел. На его основе можно делать вывод об успехах или не успехах проекта.


Может быть есть еще что-то. Просто, пока в голову пришли только выше изложенные аргументы.

Передо мной стоит проблема создания единого центра качества ...

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

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

Привет Да(t)а,

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

Впрочем, может быть, кто-нибудь и знает ответ на Ваш вопрос.

Кстати, а что такое НПА?

сфера систем физической безопасности, разработка программно-аппаратных комплексов для управления такими системами. Если есть гражданство РФ + не было ранее гражданства других стран + супруга гражданка РФ (и то же ранее не была гражданкой других стран) то можем пообщаться

К сожалению, гражданством не вышли. :-)
У меня и у супруги гражданство РБ.

2 Green
Честно говоря не очень понял почему вы полагаете что бэкграунд сисадминов и программиста навредит ПМ-у, а бэкграунд аналитика, архитектора и тестеровщика наоборот поможет.

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

А Вы задумывались, почему на СТО владельца авто не пускают внутрь тех станции во время ремонта его автомашины? Чтобы он не приставал со своими глупыми советами к профессионалу. Но ПМ (который 2-5-10 лет уже активно не программирует) почему-то считает, что он лучше знает как и что нужно делать и лезет своими кривыми руками прямо во внутрь "двигателя".

2 alkozeltzer,

Прежде чем искать специалиста, я обычно готовлю два пункта:
1. расписываю обычный трудовой день данного специалиста;
2. критерии оценки успешности его работы (например, если есть возможность дать премию, то давать или не давать и в каком размере?)

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

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

Что может быть плюсом для соискателей?
- навыки аналитика
- навыки тестировщика
- знание основ построения архитектуры (необходимо уметь говорить и обсуждать эти темы)
- и просто богатый жизненный опыт

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

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

P.S.
Кстати, а что за позиция? В какой сфере?
Я все еще в поисках самого лучшего места работы. Так что могли бы пообщаться.

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

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

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

Леша,
а кто сказал, что тестировщик - это не аналитик?

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

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

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

Кстати, а как на счет личных качеств?:)

Хотел про них написать. Но потом стало лень. Итак много книжек про это написано.

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