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

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

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

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

Сформулируйте описание преимуществ каждого требования пригодности к тестированию, на которое требуется обратить внимание. Ознакомьтесь с документацией, статьями и исследованиями, поддерживающими значимость требования пригодности к тестированию. Кроме того, рекомендуется привести статистику возврата инвестиций (ROI). Обдумайте преимущества с учетом интересов группы разработки; какую ценную информацию можно предоставить им в случае выполнения этого требования? Каким образом с его помощью вы сможете проще или более эффективно предоставлять группе разработки своевременные, точные, подробные и полезные отзывы в каждом цикле компоновки? Получит ли группа разработки вместе с этим требованием новые функции, которые они смогут применять в ходе выполнения собственных задач тестирования или диагностики программного обеспечения? В случае конфликта с потребностями заказчика рекомендуется найти способ показать, что выполнение требования пригодности к тестированию обеспечит дополнительные возможности для поддержки потребностей заказчика в последующих циклах компоновки.

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

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

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

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

Кроме того, на данном этапе следует тщательно выбирать время. Как правило, рекомендуется как можно раньше определять наиболее важные вопросы пригодности к тестированию (на этапе уточнения или начальном этапе) и приступать к их продвижению. В большинстве случаев на начальных этапах группа проекта состоит из меньшего числа участников и более доброжелательно воспринимает изменения. Кроме того, если проектирование еще не завершено, требования можно включить в план с минимальными затратами.

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

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

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

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

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

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

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

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

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

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