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

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

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

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

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

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

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

m_n>Существует мнение, что уменьшить количество ошибок в ПО можно увеличив объем тестирования. "Наши заказчики жалуются, что ПО содержит много ошибок, поэтому давайте тестировать больше и лучше, чтобы уменьшить количество ошибок в конечном продукте" – примерно так иногда рассуждают менеджеры проектов.

[skipped]

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

Как Вам не стыдно!
Вы вот так вот взяли и описали наш процесс разработки

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

S>Доля правды конечно в этом есть. Но я бы не стал так категорично утверждать, что тестирование никак не влияет на количество ошибок. Зависимость количества ошибок от объема тестирования должна иметь при нулевом количестве тестирования некоторое достаточно большое начальное значение, потом при увеличении объема тестирования количество ошибок должно сильно уменьшаться и асимптотически приближаться к "остаточному" количеству, определяемому как раз процессом разработки и множеством других факторов (например языка программирования).

Дело в том, что тестирование и отладка — это разные виды деятельности, но их рассматривают как один. Разумеется, отладка без тестирования невозможна, а вот тестирование без отладки может существоввать. Тестирование это фактически диагностика, а отладка — ремонт. Различать тестирование и отладку нужно по тому, что они зависят от разных параметров проекта: объем тестирования зависит от сложности (количество строк кода, точек ветвления и т.д.), а объем отладки (в переделе) от качества процесса разработки. Т.е. в схожих по сложности проектах можно ожидать схожее количество тестов, а вот объем отладки будет зависеть от того, как поставлена разработка в проектах. Разумеется что объем отладки зависит и от объема тестирования, а все сказанное относится к случаю достаточного тестирования. В случае недостаточного тестирования объем отладки будет определятся, как Вы и сказали, объемом тестирования.

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

Согласен.

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

m_n>Существует мнение, что уменьшить количество ошибок в ПО можно увеличив объем тестирования. "Наши заказчики жалуются, что ПО содержит много ошибок, поэтому давайте тестировать больше и лучше, чтобы уменьшить количество ошибок в конечном продукте" – примерно так иногда рассуждают менеджеры проектов.

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

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

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

m_n>>Существует мнение, что уменьшить количество ошибок в ПО можно увеличив объем тестирования. "Наши заказчики жалуются, что ПО содержит много ошибок, поэтому давайте тестировать больше и лучше, чтобы уменьшить количество ошибок в конечном продукте" – примерно так иногда рассуждают менеджеры проектов.

LM> Обычно ошибки, найденные на этапе тестирования, исправляют... и они не попадают в конечный продукт.

Не все, но самые критичные ошибки стараются исправлять. Все зависит от временных рамок

LM> Очевидно, что количество ошибок в конечном продукте при этом уменьшается.

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