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

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

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

Есть ли смысл улучшать документирование, подготовку людей или их количество, т.е. насколько затраты на эти действия оправдают полученный в результате эффект?

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

напомнило анекдот: Петька, приборы? -- Пицот! -- Что "пицот"? -- А что "приборы"?
Для анализа нужна более детальная статистика.

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

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

Честно? Это может говорить обо всём и ни о чём конкретно.

Есть ли смысл улучшать документирование, подготовку людей или их количество, т.е. насколько затраты на эти действия оправдают полученный в результате эффект?

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

P.S. Судя по предыдущим Вашим сообщениям, Вы ведь вдумчиво и достаточно критично подходите к решению возникающих проблем. Так что я бы на Вашим месте сильно не волновался - всё получится, враг будет разбит, победа будет за нами (с)

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

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

Это был тест на "вшивость" !? (не нужно зачеркнуть)

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

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

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

стыдно, господа.

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

Спасибо.

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

Тестировщики дали оценку 1:3 (фичи:баги) как нормальную, по времени 100-150% от времени разработки считается нормой, хотя мне кажется, что до 200% смело можно увеличивать даже при хорошо поставленном процессе.

В общем, в целом мысль ясна.

Если Вас интересует вопрос подготовки людей, повышения уровня их квалификации, то можно отправлять сотрудников на обучение, тренинги. Хорошие, качественные тренинги по тестированию ПО проводят тренера, сотрудничающие с порталом Software-Testing.RU. Сейчас у них запущен интересный тренинг для продвинутых тестировщиков "Как искать и находить баги?", очный, двухдневный. Есть и онлайн-формат, который в силу занятости работающего населения, возможно, более удобный, можно научить как начинающих тестировщиков, так и повысить уровень специалистов.

2july.
Вы будете удивлены, но хорошие, качественные тренинги по тестированию также проводят тренера, сотрудничающие с uml2.ru

4-5 багов на новое требование - это очень небольшое число. Должно быть больше. Возможно, не все баги учитываются.

div, это зависит от объема системы и степени допиливания.. У меня сейчас на проекте от 0 до 2 багов на таск, но их всего не более 40-ка (тасков).
Был проект с 3 000 тасков, там багов было около 10 000.

div, это зависит от объема системы и степени допиливания.. У меня сейчас на проекте от 0 до 2 багов на таск, но их всего не более 40-ка (тасков).
Был проект с 3 000 тасков, там багов было около 10 000.

Лёша, а что есть таск, его объем, сложность?

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

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

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

Потому говоря, что обычно на 1 таск до 3 багов, ты реально мало чего говоришь

Как чувствовал, что этим всё закончится
Если вечером дома появлюсь, то постараюсь оценить объем, а главное - сложность реализации функциональности, описанной в постановке.. Ну и уровень разработчиков учесть.
Отсюда и смогу оценить среднее количество багов.