Часть I. Процесс быстрого тестирования. представлены в виде произведения количества исполнителей на затраченное ими время и измеряется в таких единицах как человеко-день или человеко-месяц

представлены в виде произведения количества исполнителей на затраченное ими время и измеряется в таких единицах как человеко-день или человеко-месяц. Существуют различные методы оценки трудозатрат, часть из которых рассматривается далее в разделе.

3. Определение времени, требуемого для решения каждой задачи и длитель­ ности всего жизненного цикла тестирования. Время, необходимое для ре­шения задачи, измеряется в днях, неделях или месяцах. Время, необходимое для выполнения той или иной задачи, зависит от количества исполнителей, но как будет показано ниже, эта зависимость не обязательно линейная. Сум­ марная продолжительность работ по тестированию зависит от продолжи­ тельности решения отдельных задач, однако это не простое суммирование, поскольку некоторые задачи можно решать одновременно с другими.

4. Построение подробного расписания и поэтапного графика каждой тесто­ вой задачи. На основе результатов трех предыдущих этапов можно построитьграфик выполнения работ, возможно, в виде диаграммы Ганта (Gantt), и вы­ числить сумму наиболее важных временных значений.

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

Прежде чем приступить к более подробному анализу перечисленных шагов, важно понять, насколько точными могут быть наши оценки. В самом начале проекта (перед выявлением и изучением требований) очень трудно определить, какой окажется стоимость проекта. Фактическая стоимость проекта становится известной только на завершающей стадии проекта. На начальной стадии проектирования может иметь место как недооценка, так и переоценка фактической стоимости проекта, причем приблизительно в четыре раза. После того, как все требования будут проанализиро­ ваны и начальная фаза планирования завершена, оценка стоимости проекта обычно отличается от окончательной, фактической стоимости проекта примерно в два раза [40]. Точность оценки иллюстрируется графиком, показанным на рис. 3.4.

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

Следующие несколько разделов данной главы дают обзор процесса оценки. Пред­ лагаются альтернативные стратегии выполнения трех основных действий из приве­ денного выше списка, причем вместе со всеми за и против. Более подробно техноло­ гии оценки, особенно те из них, которые относятся к категории алгоритмической оценки, будут рассматриваться в главе 12. Хорошим справочным пособием по оценке является уже ставшая классикой [40]. Кроме того, внимание заслуживает также и от­ носительно недавняя публикация [33], в которой описывается модель оценки СОСОМО II.

Рис. 3.4. Точность оценки. По материалам [40]

Определение задач

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

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

• Составление плана проведения испытаний

• Пересмотр плана проведения испытаний

• Разработка тестовых случаев

• Отладка тестовых случаев

• Проверка исправления дефектов

• Определение тестов и показателей программного продукта и процесса их сбо­ ра и использования