«крупным компаниям даже просто на конференцию отправлять может быть не выгодно, не говоря уж про докладчиков. Если только они не имеют цели создать позитивный имидж и тем привлечь толпы зеленых новобранцев. То есть цель вообще не связана с теми людьми, которых собственно отправляют на конференцию». Жаль, что эта мысль действительно прочно сидит в головах руководителей таких компаний.
На самом деле тут дело не «в головах руководителей таких компаний». Надо работать в такой компании, чтобы понимать все факторы. Руководитель может просто не знать, что кто-то хочет поехать. Отдел, ответственный за разного рода мероприятия, зачастую состоит из людей которым абсолютно ничего не надо. Сотрудники, которым интересно, боятся той бюрократии, которую надо преодолеть. Но таких не очень много. Большая же часть сотрудников, считает, что им это не надо. У них есть хорошая ЗП и социалка, какие-то задачи и возможность работать на 20-30% от потенциала.
Как раз в этот момент ухожу с дропбокса и ищу замену.
Больше всего удивлен тем, что перестали открываться HTML файлы. Они вроде как объясняют тем, что россияне спамеры.
Если вдруг кто-то знает как обойти, буду благодарен ибо сервис был неплохой.
А с IBM там совсем другое все. И даже можно сказать, что конкртено для этого проекта и этих людей они получат что-то более менее вразумительное. Походу они пытаются предсказать сколько они примерно _найдут_ багов, основываясь на том, сколько они находили раньше.
Хотя дальнейшие выкладки там мне тоже не понятны: В 18 из 20 новых модулей придется внести хотя бы одно исправление, в 3 модуля — не менее десятка. Из старых модулей хотя бы один раз придется исправить 21 модуль, а 8 или 9 модулей — не менее 10 раз.
Вам, как заказчику, никто об этом не скажет. Причин много и основная, что число N никто точно не может высчитать. И еще, что из этого числа никаких выводов сделать нельзя.
А еще, вы как заказчик готовы оплатить паралельное независимое тестирование продукта двумя командами, чтобы использовать приведённый метод?
И еще, на вопрос «Есть ли в программе еще баги?» есть только один правильный ответ — «Да, есть».
Ситуация №1
В процессе разработки нашли 200 багов. По показателям ужас-ужас, нашли менее 50% потенциально присутствующих багов. По факту, основательно протестировали основные вещи. Пользователи почти не находят ошибки в ПО после поставки, хотя там реально могут быть еще 3 сотни ненайденных дефектов.
Ситуация №2
В процессе разработки нашли 450 багов. Отлично, показатель на высоте — найдено 90% потенциально возможных ошибок. Но при тестировании бестолково протестили пару новых ключевых фич в которых 5-6 серьезных дефектов не дают жизни пользователям.
Итого — абсолютно неинтересная это величина. Никчемная. Может поэтому и забили придумывать всякие модели еще в 70-е годы?
Честно говоря я не вижу связи, как предположение о всеобщем количестве ошибок может повлиять на количество фич.
Число N не может превысить какие-либо пределы по двум причинам. Первая — это величина предположительная. Во-вторых, я не вижу никакой метрики, которая могла бы как-то поставить пределы для N.
Поясню на примере: N=300 полохо или хорошо? А N=500?
А теперь представьте, что в процессе разработки находят K багов, чинят М из них. Пусть К=100, М=80. Есть ли мне дело до того, что N=300 или 500? Да никакого абсолютно. Мне вообще его знать не надо. Если К станет 200, а М останется 80 — вот тут стоит задуматься о том месте где вы сейчас находитесь и тенденции движения вглубь этого места.
Молодцы! Хорошую работу сделали.
К сожалению посмотреть не начем, т.к. кроме SVN — все не моё.
Есть вопросы: а зачем баги автоматом запихивать в дефект-трэкер? Уж коли брать пример с Data Driven тестированием — то зачем вообще такие баги записывать в трэкер? И как разруливать (автоматически) ситуации, когда один баг приводит к падению нескольких тестов?
Скажите, а зачем вообще нужно знать число N?
За всё моё время работы в тестировании мне ни разу не понадобилось это знать.
Более того, смотря в любой дефект-трэкер можно увидеть, что из числа найденных багов n, чинится только некоторое кол-во F. И на мой взгляд отношение F/n намного более интересно, чем абстрактная величина N или даже N-n.
PS: в любом случае было бы интересно узнать о других способах, о которых вы упомянули.
Автор — молодец! Это называется конструктивной (отрицательной) обратной связью. В отличие от негативной(тоже отрицательной) обратной связи. Очень правильно подано.
~1 час. 0% брака.
На самом деле тут дело не «в головах руководителей таких компаний». Надо работать в такой компании, чтобы понимать все факторы. Руководитель может просто не знать, что кто-то хочет поехать. Отдел, ответственный за разного рода мероприятия, зачастую состоит из людей которым абсолютно ничего не надо. Сотрудники, которым интересно, боятся той бюрократии, которую надо преодолеть. Но таких не очень много. Большая же часть сотрудников, считает, что им это не надо. У них есть хорошая ЗП и социалка, какие-то задачи и возможность работать на 20-30% от потенциала.
Больше всего удивлен тем, что перестали открываться HTML файлы. Они вроде как объясняют тем, что россияне спамеры.
Если вдруг кто-то знает как обойти, буду благодарен ибо сервис был неплохой.
А с IBM там совсем другое все. И даже можно сказать, что конкртено для этого проекта и этих людей они получат что-то более менее вразумительное. Походу они пытаются предсказать сколько они примерно _найдут_ багов, основываясь на том, сколько они находили раньше.
Хотя дальнейшие выкладки там мне тоже не понятны: В 18 из 20 новых модулей придется внести хотя бы одно исправление, в 3 модуля — не менее десятка. Из старых модулей хотя бы один раз придется исправить 21 модуль, а 8 или 9 модулей — не менее 10 раз.
N1/N == N12/N2
А еще, вы как заказчик готовы оплатить паралельное независимое тестирование продукта двумя командами, чтобы использовать приведённый метод?
И еще, на вопрос «Есть ли в программе еще баги?» есть только один правильный ответ — «Да, есть».
Пусть это абстрактное N=500.
Ситуация №1
В процессе разработки нашли 200 багов. По показателям ужас-ужас, нашли менее 50% потенциально присутствующих багов. По факту, основательно протестировали основные вещи. Пользователи почти не находят ошибки в ПО после поставки, хотя там реально могут быть еще 3 сотни ненайденных дефектов.
Ситуация №2
В процессе разработки нашли 450 багов. Отлично, показатель на высоте — найдено 90% потенциально возможных ошибок. Но при тестировании бестолково протестили пару новых ключевых фич в которых 5-6 серьезных дефектов не дают жизни пользователям.
Итого — абсолютно неинтересная это величина. Никчемная. Может поэтому и забили придумывать всякие модели еще в 70-е годы?
Число N не может превысить какие-либо пределы по двум причинам. Первая — это величина предположительная. Во-вторых, я не вижу никакой метрики, которая могла бы как-то поставить пределы для N.
Поясню на примере: N=300 полохо или хорошо? А N=500?
А теперь представьте, что в процессе разработки находят K багов, чинят М из них. Пусть К=100, М=80. Есть ли мне дело до того, что N=300 или 500? Да никакого абсолютно. Мне вообще его знать не надо. Если К станет 200, а М останется 80 — вот тут стоит задуматься о том месте где вы сейчас находитесь и тенденции движения вглубь этого места.
На всякий случай опять спрошу.
Зачем кому-то нужна эта величина?
К сожалению посмотреть не начем, т.к. кроме SVN — все не моё.
Есть вопросы: а зачем баги автоматом запихивать в дефект-трэкер? Уж коли брать пример с Data Driven тестированием — то зачем вообще такие баги записывать в трэкер? И как разруливать (автоматически) ситуации, когда один баг приводит к падению нескольких тестов?
За всё моё время работы в тестировании мне ни разу не понадобилось это знать.
Более того, смотря в любой дефект-трэкер можно увидеть, что из числа найденных багов n, чинится только некоторое кол-во F. И на мой взгляд отношение F/n намного более интересно, чем абстрактная величина N или даже N-n.
PS: в любом случае было бы интересно узнать о других способах, о которых вы упомянули.