Сообщений в теме: 40

[DrVal]

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

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


P.S.
Давайте не будем смешивать понятия тестирования и качества.
IMHO тестирование (как вид деятельности) имеет слабое отношение к QA.

[SALar]

Научите, плиз, методам аудита. Или подскажите где можно научиться.

Я учился в основном по этому:
http://www.ozon.ru/c...tail/id/938899/
Плюс естественно консультировался у хорошего спеца.

Ну и плюс еще кое что.

[Boltick]

Я все ждал пока придет Green и расставит точки над i, но видно он занят.

Вам надо понять нужен ли "единый центр управления качеством" или у вас уже есть задача "сделать единый центр управления качеством"? Если задача - а я так понял, что уже есть такая задача - то просите того кто ее ставил что ему нужно, какие проблемы он обирается решать выделяя такой центр. А tit kxit возьмите процесного консалтера и пусть он спросит и распишет как лучше решит вашу проблемку.

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

Кстати, забыл спросить, сколько человек у вас в компании работает?

[Alfa]

Научите, плиз, методам аудита. Или подскажите где можно научиться.

Я учился в основном по этому:
http://www.ozon.ru/c...tail/id/938899/
Плюс естественно консультировался у хорошего спеца.

Ну и плюс еще кое что.

Слово "бухгалтерский" пугает. Это точно имеет отношение к качеству ПО?

[SALar]

Научите, плиз, методам аудита. Или подскажите где можно научиться.

Я учился в основном по этому:
http://www.ozon.ru/c...tail/id/938899/
Плюс естественно консультировался у хорошего спеца.

Ну и плюс еще кое что.

Слово "бухгалтерский" пугает. Это точно имеет отношение к качеству ПО?

ЭТО абсолютно точно имеет отношение к аудиту. Принципы и законы математики и физики не меняются от того в какой сфере они применяются. А основе аудита лежит "теория вероятности". Все остальное можете вывести оттуда. И не читать таких книжек.

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

Угу.

PS. ЭТО работает. Но не факт, что в вашей ситуации. Вам могут просто не дать этого сделать. См. ...

[Case]

Я бы добавил еще один случай, когда требуется выделенный центр тестирования:

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

Кто-то считал для вашей компании стоимость проведения такого орг.изменения и прикидывал экономию или выгоды?

[ghosty]

Я бы добавил еще один случай, когда требуется выделенный центр тестирования:
Руководители проектов вышли из девелопмента без соотв. подготовки и имеют слабое представление о тестировании и качестве ПО.

Так и есть на практике.

Давайте не будем смешивать понятия тестирования и качества.

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

[ghosty]

Кстати, забыл спросить, сколько человек у вас в компании работает?

Человек 300...

[ghosty]

Кто-то считал для вашей компании стоимость проведения такого орг.изменения и прикидывал экономию или выгоды?

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

[DrVal]

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

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

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

Полноценный аудит процессов в организации такого размера займет месяцы и обойдется в сотни тысяч рублей (правда недавно видел какие-то предложения от Люксофт - 4 дня и сосем недорого :-) ).

Кто-то считал для вашей компании стоимость проведения такого орг.изменения и прикидывал экономию или выгоды?

[ghosty]

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

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

[Green]

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


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

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

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

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

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



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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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


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

[yamayka80]

Пытаюсь ответить на вопросы:
1. На мое подразделение перекинули новый инвестиционный проект, роль в котором - чистое тестирование и заключение о возможности внедрения продукта. Суть проекта - перевод существующих продуктов на новую платформу. Под эту лавочку поставлена задача постепенного забора всех тестировщиков под одно крыло. (Вот ее необходимости и не понимаю). Мое видение: для того, чтобы после завершения проекта было понятно, чем же дальше заниматься и как (т.е. типа подразделение не одноразовое).
2. Окончательное решение принимает, соответствено, директор компании.
3. Дословно задача: сформировать единый центр качества. Что, как, зачем, с какой целью - неизвестно. Все это сейчас будет долго и упорно обсуждаться, поэтому и прошу вашей помощи. Причем замечу, что концепции и планы развития необходимо писать именно мне. Поэтому добавлю еще такой момент: не смотря на то, что задачу мне поставили, я чувствую необходимость объяснять свое же собственное существование и развитие.
4. В результате должно получиться минимум: единый центр качества в виде структуры и налаженных процессов, внедрены продукты, активизирована деятельность по аутсорсингу тестирования.

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

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

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

[ghosty]

Спасибо всем большое за оперативные ответы. Сергею отдельное спасибо за красоту и структурированность.

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

[Clauster]

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

Ответственность за качество должна распределяться, нельзя на одного человека все вешать.

[JimR]

Спасибо всем большое за оперативные ответы. Сергею отдельное спасибо за красоту и структурированность.

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

А это зависит от того, как вы встроите свой независимый центр в процессы разработки.

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

[DrVal]

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

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

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

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

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

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

[ghosty]

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

[SALar]

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

[Case]

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