Здравствуйте, dmz, Вы писали:

А>>Я думаю баги нужно мерять в количестве а не в часах — так как за час можна ничего и не найти поидее...
dmz>То есть проплачиваете 100 баксов, и вам обязуются найти 10 багов? Проплачиваете 1000 и багов уже 100?
dmz>Ход мысли мне нравится.

Мне больше нравится идея когда клиент платит за поиск уникальных 100 багов к примеру

Здравствуйте, Аноним, Вы писали:

А>Мне больше нравится идея когда клиент платит за поиск уникальных 100 багов к примеру

А что если их там нет столько?

Здравствуйте, Firstborn, Вы писали:

F>Здравствуйте, Аноним, Вы писали:

А>>Мне больше нравится идея когда клиент платит за поиск уникальных 100 багов к примеру

F>А что если их там нет столько?

Баги всегда есть Ну тогда клиент платит только за количество найденных багов

Здравствуйте, Аноним, Вы писали:

А>Баги всегда есть Ну тогда клиент платит только за количество найденных багов

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

Здравствуйте, Firstborn, Вы писали:

F>Здравствуйте, Аноним, Вы писали:

А>>Мне больше нравится идея когда клиент платит за поиск уникальных 100 багов к примеру

F>А что если их там нет столько?

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

Здравствуйте, Firstborn, Вы писали:

F>Здравствуйте, Аноним, Вы писали:

А>>Баги всегда есть Ну тогда клиент платит только за количество найденных багов

F>Неправильный подход. Не видел никого, кто работал бы по подобному принципу, хотя неоднократно участвовал в testing-only проектах. Там всегда платят за потраченный эффорт (человеко-часы), иначе просто невозможно. Краткий ликбез в моём исполнении здесь.

У нас для QA отдела стоит задача для каждого тестера — 10 багов в день минимум... + баги по тест плану... Проблем с этим еще ни у кого не возникало

Здравствуйте, Firstborn, Вы писали:

F>Здравствуйте, Аноним, Вы писали:

А>>Баги всегда есть Ну тогда клиент платит только за количество найденных багов

F>Неправильный подход. Не видел никого, кто работал бы по подобному принципу, хотя неоднократно участвовал в testing-only проектах. Там всегда платят за потраченный эффорт (человеко-часы), иначе просто невозможно. Краткий ликбез в моём исполнении здесь.

Дело в том что если платить по часам то мотивации у тестера хорошо работать нету — он нашел баг за час и все — ему и так заплатят, а так чем больше нашел тем больше заплатят да и никто не спрашивает за скоко времени он их нашел — хоть за пятть минут...

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Firstborn, Вы писали:

F>>Здравствуйте, Аноним, Вы писали:

А>>>Баги всегда есть Ну тогда клиент платит только за количество найденных багов

F>>Неправильный подход. Не видел никого, кто работал бы по подобному принципу, хотя неоднократно участвовал в testing-only проектах. Там всегда платят за потраченный эффорт (человеко-часы), иначе просто невозможно. Краткий ликбез в моём исполнении здесь.

А>Дело в том что если платить по часам то мотивации у тестера хорошо работать нету — он нашел баг за час и все — ему и так заплатят, а так чем больше нашел тем больше заплатят да и никто не спрашивает за скоко времени он их нашел — хоть за пятть минут...

Слушайте, как-то мне начинает надоедать заниматься ликбезом Конечно, работа тестеров может быть организована по-разному. Конечно, есть даже разница, это просто свой QA отдел софтварной компании, или это команда тестеров, услуги которой используются сторонним заказчиком для тестирования его продукта (testing-only проекты). Но обычно всё-так оплата (речь изначально шла только о ней, не о мотивации!) осуществляется по потраченному эффорту, именно так, как предлагает www.gashev.com — это логично, правильно, иначе нельзя! За работу должно быть заплачено, в любом случае, нельзя это завязывать на количество найденных дефектов, просто потому, что это количество даже не есть показатель качества тестирования, не говоря уже об объёме проведённых работ! Показателем качества тестирования может быть, скажем, количество НЕотловленных багов, т.е. post-delivery defects. Так что мотивация организовывается очень просто: для группы тестеров устанавливается цель, скажем, чтобы в testable unit-е (атомарной единице, подлежащей тестированию — например, определённой версии продукта/модуля) не было больше, скажем, 3-х post-delivery defects. Если реально оказывается, что их больше — значит, тестирование было проведено недостаточно качественно и тут уже могут быть претензии к группе, вплоть до снятия премии и т.п. Но на количество найденных багов ничего завязывать нельзя, ни оплату, ни мотивацию, ничего! Это же исключительно побочный продукт.

Здравствуйте, yxiie, Вы писали:

Y>Здравствуйте, Firstborn, Вы писали:

F>>Здравствуйте, Аноним, Вы писали:

А>>>Мне больше нравится идея когда клиент платит за поиск уникальных 100 багов к примеру

F>>А что если их там нет столько?

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

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

Здравствуйте, Аноним, Вы писали:

А>У нас для QA отдела стоит задача для каждого тестера — 10 багов в день минимум... + баги по тест плану... Проблем с этим еще ни у кого не возникало

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

Автор: Firstborn
Дата: 19.05.05

.

Здравствуйте, Firstborn, Вы писали:

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

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

я уверен, WolfHound при любом раскладе баги нашел бы

Здравствуйте, Firstborn, Вы писали:

F>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Firstborn, Вы писали:

F>>>Здравствуйте, Аноним, Вы писали:

А>>>>Баги всегда есть Ну тогда клиент платит только за количество найденных багов

F>>>Неправильный подход. Не видел никого, кто работал бы по подобному принципу, хотя неоднократно участвовал в testing-only проектах. Там всегда платят за потраченный эффорт (человеко-часы), иначе просто невозможно. Краткий ликбез в моём исполнении здесь.

А>>Дело в том что если платить по часам то мотивации у тестера хорошо работать нету — он нашел баг за час и все — ему и так заплатят, а так чем больше нашел тем больше заплатят да и никто не спрашивает за скоко времени он их нашел — хоть за пятть минут...

F>>>Показателем качества тестирования может быть, скажем, количество НЕотловленных багов, т.е. post-delivery defects.

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

Здравствуйте, Аноним, Вы писали:

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

Встраивать контрольные баги — это оригинально А не будет ли это несколько затруднительно? Не проще ли всё же сконцентрироваться на том, ради чего тестинг затеивался? Т.е. на том, сколько неотловленных багов осталось в продукте?

Здравствуйте, Firstborn, Вы писали:

F>Здравствуйте, Аноним, Вы писали:

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

F>Встраивать контрольные баги — это оригинально А не будет ли это несколько затруднительно? Не проще ли всё же сконцентрироваться на том, ради чего тестинг затеивался? Т.е. на том, сколько неотловленных багов осталось в продукте?

Юнит тесты тож затруднительно писать, так что ж теперь их вообще не писать? Так что ради качества ПО можна и такую схему внедрять Главное вести учет всему этому делу

Здравствуйте, Firstborn, Вы писали:

F>Здравствуйте, Аноним, Вы писали:

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

F>Встраивать контрольные баги — это оригинально А не будет ли это несколько затруднительно? Не проще ли всё же сконцентрироваться на том, ради чего тестинг затеивался? Т.е. на том, сколько неотловленных багов осталось в продукте?

Даже можно не контрольные баги встраивать а просто msgbox-ы с кодом контрольного бага в теле этого msgbox, но с возможностью больше не показывать этот msgbox... Как вам идея?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Firstborn, Вы писали:

F>>Здравствуйте, Аноним, Вы писали:

А>>>Баги всегда есть Ну тогда клиент платит только за количество найденных багов

F>>Неправильный подход. Не видел никого, кто работал бы по подобному принципу, хотя неоднократно участвовал в testing-only проектах. Там всегда платят за потраченный эффорт (человеко-часы), иначе просто невозможно. Краткий ликбез в моём исполнении здесь.

А>Дело в том что если платить по часам то мотивации у тестера хорошо работать нету — он нашел баг за час и все — ему и так заплатят, а так чем больше нашел тем больше заплатят да и никто не спрашивает за скоко времени он их нашел — хоть за пятть минут...

В группе тестеров очень хорошо видно кто находит баги а кто кофе пьет.

Здравствуйте, <Аноним>, Вы писали:

А>>>Я думаю баги нужно мерять в количестве а не в часах — так как за час можна ничего и не найти поидее...
А>Мне больше нравится идея когда клиент платит за поиск уникальных 100 багов к примеру

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

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

Здравствуйте, Firstborn, Вы писали:

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

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

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, dmz, Вы писали:

А>>>Я думаю баги нужно мерять в количестве а не в часах — так как за час можна ничего и не найти поидее...
dmz>>То есть проплачиваете 100 баксов, и вам обязуются найти 10 багов? Проплачиваете 1000 и багов уже 100?
dmz>>Ход мысли мне нравится.

А>Мне больше нравится идея когда клиент платит за поиск уникальных 100 багов к примеру

А если это регрессионное тестирование, когда надо убедиться,
что все работает как раньше?

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

Здравствуйте, Аноним, Вы писали:

А>Дело в том что если платить по часам то мотивации у тестера хорошо работать нету — он нашел баг за час и все — ему и так заплатят, а так чем больше нашел тем больше заплатят да и никто не спрашивает за скоко времени он их нашел — хоть за пятть минут...

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