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

[Green]

Я подозреваю, что Алексей, как великий комбинатор, опять задал риторический вопрос.

:ph34r:

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

:D

[barancev]

Я подозреваю, что Алексей, как великий комбинатор, опять задал риторический вопрос.

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

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

Конечно, в итоге все скажут, что так и думали с самого начала :)
А на самом-то деле вообще над этим не думали, знай себе искали ошибки, а спроси зачем -- потому что так надо!

[Case]

Ну да ладно, тот кто ответить "так надо" - скорее всего ответит и "могу копать - могу не копать" (это из соседней темы).

[barancev]

А нужна ли вообще деятельность по тестированию, если её цель -- ошибки искать? Кому они нужны?

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

Заказчик не заинтересован в том, чтобы ошибки были найдены во время тестирования. Он заинтересован в том, чтобы в конечном прдукте их было как можно меньше. А как вы этого добьётесь -- дело ваше. Хотите -- сначала делайте, потом ищите и исправляйте. Хотите -- не делайте их вообще, тогда и не надо будет искать и исправлять. Не надо в уста заказчика вкладывать свои проблемы :)

Но вот что мне понравилось в цитируемом фрагменте больше всего, так вот это: "Ошибки нужны для того, чтобы их исправить". :D :D :D

Ведь если деятельность по обеспечению качества эффективно достигает своей цели без тестирования, то зачем его выполнять?

Если достигает (ну к примеру не допускает появления ошибок вовсе), то тестирование сводится к верификации насколько правильно поняли разработчики пользователя (утрировано) - то есть, контроллируем что система делает то что хотел пользователь, всё то что хотел пользователь и ничего кроме того что хотел пользователь.

Вот именно об этом я и говорю, вот это-то и нужно заказчику, а не ошибки -- чтобы всё работало так, как нужно и не делало того, чего не нужно.

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

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

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

[Viktor]

Цель процесса тестирования - снижение риска, связанного с отказом системы в самый неподходящий для продавца продукта момент!!!
Этот риск очень значим для продаж - лучшие идеи, заложенные в некачественном продукте, уйдут в качественные конкурентные! Теряется лицо!
Тестеровщик - ликвидатор риска, очень большой друг менеджера проекта!
Разработчик - враг МП (:)), вносит неопределенность в процесс управления рисками

Алексей, я прав?

[Case]

Сильна многа отвечать не буду - пора выбегать :)

Заказчик не заинтересован в том, чтобы ошибки были найдены во время тестирования.

Заинтересован. По-крайней мере мне наверное везло с заказчиками :) Он её потом продаёт и хочет чтобы ошибок в ней небыло (стремилось к "не было")

[barancev]

Цель процесса тестирования - снижение риска, связанного с отказом системы в самый неподходящий для продавца продукта момент!!!
Этот риск очень значим для продаж - лучшие идеи, заложенные в некачественном продукте, уйдут в качественные конкурентные! Теряется лицо!
Тестеровщик - ликвидатор риска, очень большой друг менеджера проекта!
Разработчик - враг МП (:)), вносит неопределенность в процесс управления рисками

Алексей, я прав?

В целом да, но в частностях... Разработчик -- враг МП?
Хм... Впрочем, в этом что-то есть. :)

Цель процесса тестирования, конечно, не снижение риска. Это цель деятельности, в которую тестирование включено как составная часть. Если, скажем, тестировщик найдёт ошибку, но она не будет исправлена, то риск от этого нисколько не уменьшится -- система упадёт там же и тогда же. Да, управлять рисками станет легче, ибо появляется большая определённость. Именно поэтому тестировщик -- друг МП. А вообще-то у него ещё много друзей :)

Разработчик, конечно, вносит неопределённость, но неопределённость -- это не самое страшное. Риск полного невыполнения проекта, то есть несоздания продукта, у которого вероятность наступления 100% -- вот что появляется, если разработчик не будет делать своё дело. Так что эта неопределённость, которую он вносит, просто цветочки по сравнению с той определённостью, которая наступит иначе :)

[Viktor]

Цель процесса тестирования - снижение риска, связанного с отказом системы в самый неподходящий для продавца продукта момент!!!
Этот риск очень значим для продаж - лучшие идеи, заложенные в некачественном продукте, уйдут в качественные конкурентные! Теряется лицо!
Тестеровщик - ликвидатор риска, очень большой друг менеджера проекта!
Разработчик - враг МП (:)), вносит неопределенность в процесс управления рисками

Алексей, я прав?

В целом да, но в частностях... Разработчик -- враг МП?
Хм... Впрочем, в этом что-то есть. :)

Цель процесса тестирования, конечно, не снижение риска. Это цель деятельности, в которую тестирование включено как составная часть. Если, скажем, тестировщик найдёт ошибку, но она не будет исправлена, то риск от этого нисколько не уменьшится -- система упадёт там же и тогда же. Да, управлять рисками станет легче, ибо появляется большая определённость. Именно поэтому тестировщик -- друг МП. А вообще-то у него ещё много друзей :)

Разработчик, конечно, вносит неопределённость, но неопределённость -- это не самое страшное. Риск полного невыполнения проекта, то есть несоздания продукта, у которого вероятность наступления 100% -- вот что появляется, если разработчик не будет делать своё дело. Так что эта неопределённость, которую он вносит, просто цветочки по сравнению с той определённостью, которая наступит иначе :)

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

Кстати, Алексей, снижение рисков - не это ли тот основополагающий принцип, которым Вы руководствуететесь в своих проектах?

[barancev]

Кстати, Алексей, снижение рисков - не это ли тот основополагающий принцип, которым Вы руководствуететесь в своих проектах?

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

Для простоты пояснения обратимся опять же к RUP (о, великий и могучий!). Посмотрите на описание роли МП (Project Manager) -- там деятельности собраны в несколько групп. Так вот, деятельности, связанные с Product Acceptance и Quality Assurance находятся в той же группе, что и деятельности Risk Management и Problem Resolution. Вот так. Это деятельности взаимосвязанные и одна без другой немногого стоит, один поиск ошибок останется.