ОРГАНИЗАЦИЯ СЕРТИФИКАЦИОННЫХ ИСПЫТАНИЙ ПРОГРАММНЫХ ПРОДУКТОВ НА СООТВЕТСТВИЕ ТРЕБОВАНИЯМ

ЛЕКЦИЯ 10.2 ОРГАНИЗАЦИЯ СЕРТИФИКАЦИОННЫХ ИСПЫТАНИЙ ПРОГРАММНЫХ ПРОДУКТОВ НА СООТВЕТСТВИЕ ТРЕБОВАНИЯМ

1. Цели, задачи и процессы сертификационных испытаний программных продуктов

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

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

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

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

Основное внимание сосредоточено на стратегии, методах и процессах сертификационных испытаний целостных программных комплексов и их функциональных компонентов, на соответствие заданным и формализованным требованиям – рис. 8.1.

Рис. 8.1

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

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

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

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

·           при допустимых входных данных комплекс программ вырабатывает верный результат, соответствующий требованиям;

·           при недопустимых входных данных комплекс программ отвергает входные данные и выдает соответствующее диагностическое сообщение;

·           независимо от допустимости входных данных программы не зависают и не завершаются аварийно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ и формирование требований к тестам проводится при определении целей, задач и стратегий испытаний, а также инструментов тестирования, которые возможно применять – рис. 8.2.

Рис. 8.2

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

·          что нужно сделать при определении требований к тестам для проверки корректности конкретной версии программного продукта или его функциональных компонентов;

·          как преобразовать архитектуру, системные требования к функциям и характеристикам в сценарии и результаты использования программного продукта, а также в конкретные требования к системе тестов;

·          как провести анализ и формирование документации на ком плекс программ для формулировки и документирования требований к тестам и результатам тестирования.

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

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

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

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

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

Можно выделить следующие, наиболее распространенные виды организации испытаний:

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

·           функциональное тестирование соответствия требованиям –

проверка комплекса программ и/или системы, предъявляемым к ним требованиям, описанным на уровне спецификации функций и харак теристик;

·           системное тестирование охватывает целиком всю систему, обычно фокусируется на нефункциональных и/или динамических требованиях – безопасности, производительности, точности, надеж ности; тестируются интерфейсы к внешним приложениям, аппарат ному обеспечению, операционной и внешней среде;

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

·           приемосдаточное тестирование – испытания программного продукта, проверяется поведение системы на предмет удовлетворения требований заказчика, как с привлечением разработчиков системы, так и без них;

·           установочное тестирование проводится с целью проверки процедур инсталляции программного продукта и/или системы в целевом окружении конкретного применения;

·           тестирование удобства и простоты применения – проверка, насколько легко конечный пользователь может освоить программный продукт, включая не только функциональную составляющую, но и документацию;

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

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

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

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

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

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

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

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

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

Однако следует учитывать, что корректировки программных компонентов в 10 – 30% случаев сами могут содержать ошибки и требуют тщательного тестирования не только тех частей, где внесены
изменения.

Тестирование разработанных компонентов комплекса про грамм необходимо для проверки при корректности внесения изменений в версии программного продукта.

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

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

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

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

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

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

2. Соответствие пространств требований и тестов

к функциям и характеристикам комплексов программ

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

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

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

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

Рис. 8.3

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

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

·           для разработки и проверки программ и интерфейсов взаимодействия программных компонентов разных уровней в комплексе программ;

·           для создания требований к скоординированному комплексу тестов для проверки совокупности компонентов, обеспечивающих взаимную проверку реализации спецификаций требований комплексом программ.

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

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

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

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

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

Испытания на базе верифицированных требований к тестам должно обеспечивать качество комплексов программ. Такие сценарии предназначены для поэтапной проверки внутренней непротиворечивости и полноты реализации требований к функциям и характеристикам качества комплексов программ. Требования к тестам должны проверяться на корректность системных взаимосвязей функциональных компонентов сверху вниз и на внутреннюю корректность взаимодействия между требованиями для компонентов и их пригодности для последующего тестирования и применения (рис. 8.4).

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

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

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

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

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

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

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

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

Оценка покрытия требует учета, в какой степени тесты на целены на пространство требуемых функций и характеристик комплекса программ.

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

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

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

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

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

3. Стратегии и планирование испытаний программных продуктов

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

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

Стратегии испытаний программных продуктов:

-          стратегия испытаний - совокупность методов и решений, способствующих достижению программным продуктом высокого качества;

-       испытания в первую очередь следует проводить для требований с наивысшим приоритетом, которые наиболее важны, либо могут причинить наибольшие неприятности;

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

-         тестирование полезно начинать с функций и конфигураций, с которыми наиболее часто будет иметь дело конечный пользователь или система;

-         приоритет при планировании испытаний целесообразно отдавать:

·         для покрытия критических вариантов использования системы и пользовательских данных;

·         областями повышенного риска наличия дефектов;

·         для покрытия критических пробелов в тестовом покрытии;

·         функциям, наиболее значимым для работы системы, и функциям повышенного риска;

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

Рис. 8.5

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

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

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

Стратегия испытаний функций и характеристик комплекса программ должна содержать последовательные процессы:

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

·           дополнять тестовые данные или условия тестовых сценариев для покрытия критических вариантов использования системы, пользовательских данных или сокращения известных дефектов в программном продукте;

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

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

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

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

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

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

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

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

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

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

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

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

План испытаний должен определять объем работ по испытаниям. Обычно выстраивают структуру работ, в которой на одном уровне определяются категории работ по тестированию, а на другом уровне - подробные описания работ.

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

Должны быть документированы квалификация и навыки сотрудников, необходимых для проведения испытаний.

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

Также необходимо определять и документировать в плане роли и ответственность сотрудников группы испытаний с учетом особенности продукта.

Любая Программа испытаний должна иметь определенные рамки, отражающие ограничения по сотрудникам, по человеко-часам и по графику. В плане тестирования также следует отражать допущения, предварительные условия и риски тестирования.

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

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

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

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

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

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

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

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

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

К ключевым элементам планирования испытаний относится тестирование эксплуатационной и технологической документации.

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

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

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

Тестирование структурного покрытия должно устанавливать, не пропущены ли элементы структуры программы, которые не проверены тестовыми процедурами и покрыли ли тесты всю структуру комплекса про грамм.

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

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

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

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

Испытатели должны составлять планграфик разработки и вы полнения тестовых процедур по шкале времени реализации проек та, как средство определения временных рамок для разработки и выполнения различных тестов (графики Ганта). План-график определяет зависимости между тестами и общие сценарии, которые будут постоянно использоваться при испытаниях.

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

Испытатели должны определить время и ресурсы на эти работы. При подготовке графика:

·          назначаются сотрудники, ответственные за выполнение каждой из работ по испытаниям;

·          следует учитывать последовательность разработки тестов, их взаимозависимость и связь с процессами и компонентами ЖЦ комплекса программ;

·          сокращаются или исключаются возможные конфликты между тестовыми процедурами, которые должны быть документированы;

·          тестовые процедуры могут быть объединены в группы в соответствии с функциями программного продукта;

·          разработка тестовых процедур и их применение должны быть спланированы таким образом, чтобы исключить дублирование работ;

·          в структуре тестовых процедур следует учитывать и документировать их приоритеты и риски.

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

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

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

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

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

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

Оценки затрат на испытания программных продуктов

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

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

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

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

Оценки затрат на испытания программных продуктов:

-                   оценки трудозатрат на испытания и обнаружения дефектов версии программного продукта включают следующие этапы:

·         определение перечня и состава задач испытаний, которые должны быть выполнены;

·         оценка трудозатрат на решение отдельных задач и всего процесса испытаний;

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

·         затраты на обеспечение требований надежности и безопасности функционирования комплекса программ;

·         построение подробного расписания и поэтапного графика решения каждой тестовой задачи;

·         оценка рисков невыполнения графика работ и формулировка планов их снижения

-                   затраты на сопровождение и корректировки дефектов версий рограммных продуктов включают:

·         затраты на тестирование для обнаружения и устранения ошибок и дефектов в каждой версии программного про дукта;

·         оценка затрат на устранение выявленных ошибок при формировании очередной версии;

·         затраты на доработку и совершенствование программ, формирование и испытание новых модернизированных версий;

·         затраты на конфигурационное управление, тиражирование каждой новой версии и ее внедрение в эксплуатируемых и новых системах;

-         затраты на завершающие испытания программного продукта в целом.

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

Получение оценки трудозатрат на выполнение испытаний проекта крупного комплекса программ включает на следующие этапы.

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

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

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

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

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

Оценка рисков невыполнения графика работ и формулировка планов их снижения. Следует оценивать возможные проблемы и риски, которые могут возникнуть при решении задач в запланированные промежутки времени, и предусмотреть средства решения этих проблем. Прежде чем приступать к более подробному анализу перечисленных шагов, важно учитывать, насколько точными могут быть оценки. После того, как все требования будут проанализированы и утверждены, оценка стоимости продукта обычно отличается от окончательной, фактической стоимости примерно в два раза. При этом общие затраты на тестирование на всех этапах разработки могут достигать 30 - 40% от полной трудоемкости создания комплекса про грамм. Из них затраты на испытания критических систем совместно с заказчиком могут составлять до половины этих затрат. Ввиду неточностей, свойственных таким процессам оценки, целесообразен мониторинг и периодическое возвращение к оценке трудозатрат и графика выполнения тестирования, и считать это неотъемлемой частью организации работ по испытаниям.

Затраты на обнаружение и устранение дефектов и ошибок в программе определяются двумя факторами: затратами на обнаружение каждой ошибки и затратами на устранение выявленных ошибок при формировании очередной версии. Чем меньше ошибок в про грамме, тем труднее они обнаруживаются, т.е. тем выше затраты на выявление каждой ошибки. Затраты на устранение ошибок и корректировку программ пропорциональны числу дефектов, выявляемых между очередными версиями программного продукта. Непрерывно требуются затраты для контроля состояния версий комплекса про грамм и обеспечения их сохранности. По опыту работ, широко тира жируемый комплекс программ объемом ~ 10⁵ строк, может требовать при испытаниях непрерывных усилий коллектива в составе десятка и более специалистов для устранения ошибок, корректировок версий и документации.

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

Возрастание относительных затрат всех видов при квалификационном тестировании программного продукта систем реального времени (СРВ) обусловлено высокой трудоемкостью динамической отладки и тестирования в реальном времени. При этом следует учитывать, что абсолютные значения трудоемкости испытаний программ СРВ приблизительно в 5 раз выше, чем программ административных систем (АС). Относительная трудоемкость и длительность при испытаниях различных классов программных продуктов приблизительно одинакова и составляет 8 -10% от совокупных затрат на раз работку. Однако абсолютная трудоемкость для испытаний АС также приблизительно в 5 раз меньше, чем программ СРВ. При этом следует учитывать, что при изменении трудоемкости полной разработки в 5 раз, абсолютная длительность этого процесса сокращается всего в 1,5 - 1,7 раза. В результате полная длительность отладки и испытаний программ АС также приблизительно в полтора раза меньше, чем программы СРВ того же размера.

Затраты на обеспечение требований надежности и безопасности функционирования комплекса программ определяются требуемым их уровнем и сложностью (размером) комплекса про грамм. При наличии особенно высоких требований к безопасности критических программных продуктов эти затраты могут в 2 – 3 раза превышать затраты на решение базовых, функциональных задач. Для типовых административных систем трудоемкость создания программных средств защиты обычно составляет 20 – 40% затрат на решение основных, функциональных задач. В более простых случаях, доля таких затрат может снижаться до 5 – 10%. Затраты на обеспечение высокой надежности близки к затратам на обеспечение безопасности, и, в составе разработки, они могут достигать 2 – 3 кратного увеличения затрат, при требованиях наработки на отказ в десятки тысяч часов. Для минимального обеспечения автоматического рестарта в ординарных системах, затраты составляют порядка 10 – 20%. Одна ко практически, в любых системах должен присутствовать минимум программных компонентов, обеспечивающих надежность и защиту от преднамеренных и случайных угроз.

Затраты на сопровождение и корректировки дефектов вер сий программных продуктов можно считать аддитивными и включающими составляющие (см. рис. 8.6):

·           затраты на тестирование для обнаружения и устранения ошибок и дефектов в каждой версии программного продукта;

·           затраты на доработку и совершенствование программ, фор мирование и испытание новых модернизированных версий;

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

Доля каждой составляющей в общих затратах на сопровождение может значительно изменяться в зависимости от особенностей сферы применения и жизненного цикла конкретного программного продукта. Для долгоживущих (~ 10 лет), многократно тиражируемых (1000 – 100000 экземпляров) комплексов доминирующими обычно являются затраты на модернизацию и доработку версий программного продукта.

Затраты на совершенствование и модернизацию комплексов программ близки по содержанию (но не по величине) к затратам на их первичную разработку. Модернизация обычно производится поэтапно. Для каждой новой версии изменяется (разрабатывается) только некоторая часть от всего объема программного продукта. Экспериментально установлено, что эта часть при вводе очередной версии обычно составляет 10 - 20% от объема всего комплекса.

 Сложность связей компонентов приводит к тому, что удельные затраты на изменяемые программы, при модернизации каждой версии могут быть в 2 - 3 раза больше, чем затраты на создание программ такого же объема при разработке первой версии. Эта величина зависит от того, насколько путем стандартизации архитектуры и интерфейсов, предусматривались перспективы совершенствования комплекса про грамм. Затраты на модернизацию зависят от тиража косвенно, вследствие расширения условий применения конкретного комплекса и увеличения потока запросов пользователей на развитие программ. Так же косвенно влияет тираж на запросы для устранения выявленных ошибок. Для выполнения этих работ иногда используется коллектив специалистов, осуществивших первичную разработку проекта. Такая организация наиболее характерна для уникальных, заказных программных продуктов. В этих случаях первичную разработку и модернизацию трудно разделить. Для широко тиражируемых продуктов, на сопровождение часто выделяется специальный коллектив, не проводивший первичную разработку.

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

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

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

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

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

КОНТРОЛЬНЫЕ ВОПРОСЫ

Раздел 1: Цели, задачи и процессы сертификационных испытаний

1.    Какова основная цель сертификационных испытаний программного продукта?

2.    Почему сложность тестирования функции часто сравнима со сложностью ее разработки?

3.    Что понимается под «покрытием тестами» и «пространством требований»?

4.    На чем фокусируются испытатели небольших компонентов, а на чем — испытатели структуры?

5.    Каковы преимущества повторного использования готовых программных компонентов?

6.    Почему методы тестирования небольших компонентов могут быть неприменимы для сложных продуктов?

7.    Перечислите не менее четырех основных задач сертификационных испытаний.

8.    Какие три общих базовых критерия должны соблюдаться при работе комплекса программ?

9.    Как изменился подход к времени проведения испытаний в жизненном цикле разработки?

10.                       Почему важно участие специалистов по испытаниям на этапе разработки требований?

11.                       Какую долю факторов успеха проекта составляют проблемы управления требованиями?

12.                       Какую роль в предотвращении дефектов играют международные стандарты?

13.                       Какие проблемы решаются при анализе требований к тестам (вопросы "что?" и "как?")?

14.                       На каких уровнях обычно производятся испытания комплекса программ?

15.                       В чем разница между функциональным и системным тестированием?

16.                       Что такое тестирование граничных значений и тесты оценки живучести?

17.                       Дайте определение приемосдаточному и установочному тестированию.

18.                       Что такое тестирование, ориентированное на дефекты?

19.                       Почему важно находить баланс между избыточным и недостаточным тестированием?

20.                       Что такое восходящее тестирование и каков его главный принцип?

21.                       Почему даже небольшие изменения в программе требуют тщательного тестирования?

22.                       Как можно предсказать места в программе, где наиболее вероятно появление новых дефектов?

23.                       Что, помимо покрытия тестами, учитывается при решении о завершении процесса тестирования?

Раздел 2: Соответствие пространств требований и тестов

24.                       Какова основная цель верификации комплекса программ и компонентов?

25.                       Почему верификацию необходимо интегрировать в жизненный цикл как можно раньше?

26.                       Каким образом спецификации тестов способствуют повышению качества требований?

27.                       С какими двумя целями может использоваться верификация спецификаций требований тестов?

28.                       Почему параллельная разработка спецификаций программ и спецификаций тестов эффективна?

29.                       Чем отличаются подходы к описанию функций у программистов и тестировщиков?

30.                       Как взаимные проверки спецификаций требований и тестов помогают выявлять дефекты?

31.                       Почему процесс верификации не гарантирует полную корректность всех требований?

32.                       Каково рекомендуемое соотношение между системными требованиями и требованиями к тестам?

33.                       Что такое матрица отслеживания требований тестами и какую функцию она выполняет?

34.                       Дайте определение «тестовому покрытию».

35.                       Как визуализируется тестовое покрытие с помощью матрицы?

36.                       Что позволяет выявить анализ сильных и слабых связей между тестами и пространством требований?

37.                       Как требования к тестам могут использоваться помимо своего прямого назначения?

38.                       В каких критических системах особенно важно покрытие полной структуры решений?

Раздел 3: Стратегии и планирование испытаний программных продуктов

39.                       Что такое стратегия испытаний?

40.                       Каковы рекомендации по приоритезации требований при тестировании в условиях нехватки ресурсов?

41.                       Почему новым и измененным функциональным возможностям следует уделять первоочередное внимание?

42.                       По какому принципу следует выбирать функции и конфигурации для начала тестирования?

43.                       На какие четыре области следует обращать приоритетное внимание при планировании испытаний?

44.                       Какие последовательные процессы должна включать стратегия испытаний функций и характеристик?

45.                       Что такое исследовательское тестирование и когда оно применяется?

46.                       Какие предварительные шаги должна выполнить группа тестирования перед разработкой требований к тестам?

47.                       Что входит в управление требованиями к тестам?

48.                       Кто должен утверждать план испытаний и что в нем должно быть обязательно отражено?

49.                       Что такое Программа испытаний и как она связана с планом?

50.                       Почему так важна подготовка тестовой среды и что она в себя включает?

51.                       Что такое структура работ (WBS) в контексте планирования испытаний?

52.                       Какие аспекты должны быть отражены в оценке затрат на тестирование?

53.                       Почему важно документировать квалификацию, навыки и роли сотрудников группы испытаний?

54.                       Как определяется наивысший риск при планировании тестирования и зачем это нужно?

55.                       Для чего требования к тестам заносятся в базу данных или матрицу отслеживания?

56.                       Почему важно раннее согласование матрицы отслеживания требований с заказчиком?

57.                       Что включает в себя разработка тестов и почему ее стоит вести параллельно с разработкой кода?

58.                       Что должен определять анализ полноты покрытия тестами?

59.                       Какой процент покрытия тестами требований к функциям и характеристикам считается хорошим?

60.                       Для чего строится план-график (например, график Ганта) выполнения тестовых процедур?

61.                       Как анализ связей между компонентами помогает в планировании тестирования?

62.                       Какие правила необходимо учитывать при подготовке графика тестирования?

63.                       Почему график тестирования должен быть гибким и периодически обновляться?

Раздел 4: Оценки затрат на испытания программных продуктов

64.                       Какой ресурс обычно является основным лимитирующим фактором при тестировании?

65.                       Назовите основные этапы оценки трудозатрат на испытания.

66.                       Как связаны между собой время выполнения задачи и количество исполнителей?

67.                       Какова примерная доля затрат на тестирование от общей трудоемкости создания комплекса программ?

68.                       От каких двух факторов зависят затраты на обнаружение и устранение дефектов?

69.                       Чем объясняется высокая трудоемкость испытаний систем реального времени (СРВ) по сравнению с административными системами (АС)?

70.                       Какие составляющие включают в себя затраты на сопровождение и корректировку дефектов версий?

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

72.                       Как следует распределять финансовую ответственность за устранение дефектов и модификацию функций между разработчиком и заказчиком?

73.                       Какие факторы влияют на затраты на устранение дефектов после передачи продукта в эксплуатацию?

74.                       В каких пределах разработчик обязан удовлетворять требования заказчика по результатам испытаний?

ЗАДАНИЯ

Раздел 1: Цели, задачи и процессы сертификационных испытаний

Задача 1. Ситуация: Компания-разработчик «Альфа» создала сложный модуль анализа данных. Сложность модуля такова, что ни один специалист не может удержать в голове все его взаимосвязи. При модульном тестировании ошибок не найдено, но при интеграции с другими системами начались сбои.

Вопросы:

1.                 Какой фундаментальный принцип, упомянутый в лекции, объясняет, почему ошибки были пропущены на этапе модульного тестирования?

2.                 Какая стратегия тестирования могла бы помочь выявить такие ошибки раньше?

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

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

Вопросы:

1.                 Какой концептуальный недостаток присутствует в требовании заказчика?

2.                 Какой аргумент, основанный на лекции, вы приведете заказчику, чтобы объяснить нецелесообразность полного перебора?

3.                 Что, согласно лекции, помогает найти «нужный баланс» в объеме тестирования?

Задача 3. Ситуация: Проект по разработке новой версии ПО вышел на финальную стадию. Руководство настаивает на сокращении времени на тестирование, чтобы успеть к выставке, аргументируя это тем, что «основные функции и так работают».

Вопросы:

1.                 Какова основная цель испытаний, которую вы можете противопоставить этому решению?

2.                 Какие риски, описанные в лекции, компания несет, приняв такое решение?

3.                 Какой критерий завершения тестирования, кроме сроков, вы можете предложить руководству?

Задача 4. Ситуация: При тестировании комплекса программ выявлено, что при вводе недопустимых данных система не выдает диагностическое сообщение, а обрабатывает их как корректные, что приводит к порче данных.

Вопросы:

1.                 Какое из «общих базовых критериев» работы комплекса программ нарушено?

2.                 К какому виду тестирования (функциональное, на удобство и т.д.) относится проверка данного поведения?

3.                 Предложите тип тестов (например, тесты граничных значений), который бы наиболее эффективно выявил подобные дефекты.

Задача 5. Ситуация: Команда разработки следует старой модели, при которой тестирование начинается только после готовности кода. В результате каждый релиз задерживается из-за большого количества дефектов, найденных на поздних этапах.

Вопросы:

1.                 Какой современный подход к месту испытаний в жизненном цикле не применяется в компании?

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

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

Задача 6. Ситуация: Для ускорения разработки было решено использовать 80% готовых высококачественных компонентов с унифицированными интерфейсами и 20% разработать самостоятельно. При интеграции возникли конфликты.

Вопросы:

1.                 С какими двумя проблемами, описанными в лекции, столкнулась команда при комплексировании?

2.                 Почему технология тестирования самостоятельно разработанных модулей может отличаться от тестирования готовых?

3.                 Какой процесс помогает предотвратить подобные проблемы на этапе проектирования архитектуры?

Задача 7. Ситуация: Тестировщик, полагаясь на интуицию и опыт, нашел критический дефект в месте, не покрытом формальными тест-кейсами.

Вопросы:

1.                 Какой «вид организации испытаний» применил тестировщик?

2.                 Какова сильная и слабая сторона этого подхода с точки зрения лекции?

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

Задача 8. Ситуация: После успешного приемосдаточного тестирования с участием разработчиков, заказчик проводит собственное тестирование и обнаруживает дефекты, мешающие работе в его конкретной среде.

·                      Вопросы:

1.                 Какой вид тестирования, по сути, провел заказчик?

2.                 Какой вид тестирования, упомянутый в лекции, был, вероятно, пропущен и должен был выявить эту проблему?

3.                 Кто должен нести затраты на устранение таких дефектов, согласно принципам, изложенным в разделе о финансировании?

Раздел 2: Соответствие пространств требований и тестов

Задача 9. Ситуация: Спецификация требований к ПО для медицинского оборудования содержит расплывчатые формулировки, например: «система должна реагировать быстро».

Вопросы:

1.                 К какой категории проблем требований (неверные, забытые и т.д.) это относится?

2.                 Как участие специалистов по испытаниям на этапе разработки требований могло бы исправить эту ситуацию?

3.                 Какую конкретную характеристику из нефункциональных требований нужно уточнить и формализовать для создания адекватных тестов?

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

Вопросы:

1.                 Что, согласно лекции, отличает мышление тестировщика от мышления программиста/аналитика, и почему это важно?

2.                 Какой метод повышения качества, основанный на «сопоставлении двух методов» описания, не используется в полной мере?

3.                 Предложите, как можно дополнить процесс разработки тестов, чтобы выявлять более сложные, «вторичные» дефекты.

Задача 11. Ситуация: В крупном проекте обнаружено, что несколько важных системных требований не имеют соответствующих тестовых сценариев.

Вопросы:

1.                 Какой инструмент управления тестированием должен был наглядно продемонстрировать эту проблему?

2.                 Каков был рекомендуемый в лекции минимум требований к тестам на каждое системное требование?

3.                 Что такое «тестовое покрытие» и как его можно оценить в данной ситуации?

Задача 12. Ситуация: Заказчик утверждает, что все требования реализованы, но отказывается подписывать акт сдачи-приемки, так как, по его мнению, тестирование проведено неполно.

Вопросы:

1.                 Какой документ или артефакт мог бы стать объективным доказательством покрытия требований тестами?

2.                 Что, согласно лекции, должна отображать «матрица отслеживания требований тестами»?

3.                 Кто и когда должен утверждать эту матрицу, чтобы избежать подобных конфликтов?

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

Вопросы:

1.                 Какой вид тестового покрытия (помимо покрытия требований) является критически важным в таких системах, согласно лекции?

2.                 Почему для таких систем недостаточно только функционального тестирования?

3.                 Какой метод (структурный, на интуиции и т.д.) необходимо применить для дополнения тестов?

Задача 14. Ситуация: Процесс верификации требований и тестов проводится вручную, что приводит к человеческим ошибкам и пропуску противоречий.

Вопросы:

1.                 Какой недостаток ручного процесса прямо указан в лекции?

2.                 Как параллельная разработка спецификаций требований и спецификаций тестов может служить взаимной проверке их корректности?

3.                 Какие выгоды, кроме повышения качества, дает параллельная разработка?

Задача 15. Ситуация: Анализ «слабых связей» в матрице покрытия тестов и требований показал, что нефункциональные требования к безопасности покрыты недостаточно.

Вопросы:

1.                 Что означают «слабые связи» в данном контексте?

2.                 На какие именно аспекты проекта, согласно лекции, позволяет акцентировать анализ таких связей?

3.                 Какие виды тестирования (системное, приемосдаточное и т.д.) должны быть усилены для исправления ситуации?

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

Вопросы:

1.                 Какой фундаментальный принцип организации испытаний нарушен?

2.                 Какова одна из целей верификации спецификаций тестов, которая не достигается при таком подходе?

3.                 Почему требования к тестам можно рассматривать как «вторую адекватную форму описания» комплекса программ?

Раздел 3: Стратегии и планирование испытаний программных продуктов

Задача 17. Ситуация: Перед выпуском обновления команда имеет ресурсы для тестирования только 60% от всех требований.

Вопросы:

1.                 Какой основной принцип приоритезации требований для тестирования в условиях нехватки ресурсов приведен в лекции?

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

3.                 Какое формальное соглашение с заказчиком целесообразно получить в этой ситуации?

Задача 18. Ситуация: В новую версию ПО добавлена сложная функция «ИИ-аналитик», при этом значительно изменен механизм импорта данных. Ресурсы на регрессионное тестирование ограничены.

Вопросы:

1.                 На тестирование каких двух категорий функций стратегия рекомендует обратить первоочередное внимание?

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

3.                 Что такое «регрессионное тестирование» и почему его объем в данной ситуации может быть большим?

Задача 19. Ситуация: В модуле отчетности, который ранее вызывал проблемы, при новом тестировании снова найдены ошибки. Время на тестирование истекает.

Вопросы:

1.                 Какая рекомендация из лекции прямо советует тестировать компоненты, в которых дефекты наиболее вероятны?

2.                 Какой метод тестирования («исследовательское», «ориентированное на дефекты» и т.д.) здесь наиболее уместен?

3.                 Как следует поступить с этим модулем в плане приоритетов в графике тестирования?

Задача 20. Ситуация: Заказчик настаивает на включении в тестирование редких и экзотических сценариев использования, которые составляют менее 1% от всех операций.

Вопросы:

1.                 Какой принцип выбора конфигураций и функций для начала тестирования противоречит этому требованию?

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

3.                 При каком условии (например, тип системы) тестирование редких сценариев может получить высокий приоритет?

Задача 21. Ситуация: План испытаний не был согласован с заказчиком. В процессе тестирования выяснилось, что заказчик понимает некоторые требования иначе, чем команда.

Вопросы:

1.                 Чей анализ и утверждение плана испытаний является обязательным, согласно лекции?

2.                 Какой ключевой артефакт (например, матрица соответствия) должен быть в плане и согласован для предотвращения таких ситуаций?

3.                 Какие риски проекта реализовались из-за этого недочета?

Задача 22. Ситуация: Тест-менеджер составляет график тестирования в виде диаграммы Ганта, но не учитывает зависимости между тестовыми процедурами.

Вопросы:

1.                 Какой анализ связей между компонентами, описанный в лекции, необходимо провести перед созданием графика?

2.                 Почему необходимо документировать последовательность и взаимозависимость тестовых процедур?

3.                 Какая проблема (например, конфликт процедур) может возникнуть, если проигнорировать эти зависимости?

Задача 23. Ситуация: Заказчик требует провести тестирование в среде, которая не является «зеркальным отражением» будущей продуктивной среды из-за бюджетных ограничений.

Вопросы:

1.                 Какое требование к тестовой среде нарушено?

2.                 Какие риски возникают при тестировании в неадекватной среде?

3.                 Что, согласно лекции, должно быть спланировано для подготовки корректной тестовой среды?

Задача 24. Ситуация: В процессе тестирования постоянно поступают новые и измененные требования. График тестирования постоянно срывается.

Вопросы:

1.                 Какой процесс управления должен отслеживать изменения требований и тестов?

2.                 Что должна делать группа испытателей с графиком в такой динамичной ситуации?

3.                 Какой подход к версионированию плана-графика рекомендован в лекции для управления изменениями?

Задача 25. Ситуация: Автоматизированные тестовые процедуры разрабатываются той же командой, что и код, и дублируют друг друга, увеличивая объем работ по поддержке.

Вопросы:

1.                 Какое правило группирования автоматизированных тестов нарушено?

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

3.                 Как анализ связей между тестовыми сценариями может помочь минимизировать объем работ?

Задача 26. Ситуация: Анализ покрытия тестами требований показал результат в 75%. Руководство требует довести его до 100%.

Вопросы:

1.                 Какой процент покрытия тестами требований к функциям и характеристикам, согласно лекции, считается хорошим?

2.                 Почему стремление к 100% покрытию может быть экономически нецелесообразным?

3.                 Что, помимо процента покрытия, является критически важным для принятия решения о достаточности тестирования?

Задача 27. Ситуация: Специалисты по тестированию привлечены в проект слишком поздно, когда код уже написан. Они не успевают разработать качественные тесты.

Вопросы:

1.                 Какой ключевой принцип организации работ по тестированию был нарушен?

2.                 Почему разработку тестов следует вести параллельно с разработкой кода?

3.                 Какие шаги из процесса планирования испытаний, скорее всего, были пропущены или выполнены некачественно?

Задача 28. Ситуация: В крупном проекте используется «исследовательское тестирование» для проверки областей повышенного риска. Однако его результаты плохо документируются и не воспроизводимы, что затрудняет анализ дефектов и отчетность.

Вопросы:

1.                 Какую ключевую проблему неформального подхода иллюстрирует данная ситуация?

2.                 Как можно интегрировать исследовательское тестирование в регулируемый процесс, сохранив его преимущества?

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

Задача 29. Ситуация: При тестировании выяснилось, что инструмент автоматизации тестов, выбранный в начале проекта, не поддерживает тестирование нового графического интерфейса, который решили использовать разработчики.

Вопросы:

1.                 На каком этапе планирования испытаний должен определяться и оцениваться инструментарий тестирования?

2.                 К каким последствиям для графика и бюджета приводит такая ошибка планирования?

3.                 Какую роль в предотвращении таких ситуаций играет участие тестировщиков в обсуждении архитектуры системы?

Задача 30. Ситуация: План испытаний хорошо проработан, но не включает в себя «тестирование эксплуатационной и технологической документации».

Вопросы:

1.                 Почему тестирование документации является ключевым элементом планирования?

2.                 Что может входить в такое тестирование, согласно контексту лекции (например, простота использования)?

3.                 Какой вид тестирования из Раздела 1 лекции напрямую связан с проверкой документации?

Задача 31. Ситуация: Команда тестирования состоит из молодых специалистов без опыта работы в данной предметной области. План испытаний не включает мероприятий по их обучению.

Вопросы:

1.                 Что, согласно лекции, должен сделать тест-менеджер, оценив разницу между требуемой и реальной квалификацией персонала?

2.                 Какие риски для проекта создает эта ситуация?

3.                 Как эта проблема связана с необходимостью понимания «потребностей заказчика»?

Задача 32. Ситуация: В процессе тестирования выявляется все больше дефектов. Руководство требует от тест-менеджера ответа на вопрос: «Когда мы закончим тестировать и сможем выпустить продукт?»

Вопросы:

1.                 Какие два ключевых фактора, помимо количества найденных дефектов, должны быть рассмотрены при принятии решения о завершении тестирования?

2.                 Поскольку  измерений (например, покрытие тестами) не могут сами по себе определить критерии достаточности?

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

Раздел 4: Оценки затрат на испытания программных продуктов

Задача 33. Ситуация: При оценке трудозатрат на испытания крупного проекта за основу взяли данные предыдущего, небольшого проекта. В результате на тестирование выделено недостаточно ресурсов.

Вопросы:

1.                 На чем должно основываться прогнозирование затрат на испытания, согласно лекции?

2.                 Какой основной лимитирующий ресурс при тестировании был неправильно оценен?

3.                 Назовите первый этап оценки трудозатрат, который, вероятно, был проведен неверно.

Задача 34. Ситуация: Менеджер проекта считает, что удвоение команды тестирования пропорционально сократит время на испытания в два раза.

Вопросы:

1.                 Какова реальная зависимость между количеством исполнителей и временем решения задачи, согласно лекции?

2.                 Какие факторы мешают достичь линейного сокращения времени?

3.                 Почему длительность разработки (и тестирования) при изменении трудоемкости меняется не так значительно?

Задача 35. Ситуация: Заказчик требует снизить стоимость проекта, предлагая урезать бюджет на тестирование с 40% до 15% от общей трудоемкости.

Вопросы:

1.                 Какова примерная доля затрат на тестирование от полной трудоемкости создания комплекса программ, указанная в лекции?

2.                 К каким последствиям для качества продукта приведет такое сокращение?

3.                 Какой аргумент, связывающий затраты на тестирование и вероятность соответствия требованиям, можно привести заказчику?

адача 36. Ситуация: В проекте сложной системы реального времени (СРВ) оценка трудозатрат на тестирование была сделана по аналогии с проектом административной системы (АС) схожего размера.

Вопросы:

1.                 Во сколько раз, согласно лекции, абсолютная трудоемкость испытаний СРВ выше, чем АС?

2.                 Чем обусловлена такая разница в трудоемкости?

3.                 Какой класс программных продуктов имеет большую абсолютную длительность испытаний при одинаковом размере?

Задача 37. Ситуация: Заказчик критического банковского ПО требует повышенного уровня надежности (наработка на отказ десятки тысяч часов) и безопасности.

Вопросы:

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

2.                 Какова минимальная доля затрат на надежность и безопасность даже в некритических системах?

3.                 Почему эти затраты являются необходимыми, а не опциональными?

Задача 38. Ситуация: После сдачи первой версии ПО заказчик требует бесплатно исправить дефект, который, по мнению разработчика, является не ошибкой, а новым требованием.

Вопросы:

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

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

3.                 В каких документах должен быть четко определен порядок квалификации видов изменений?

Задача 39. Ситуация: При модернизации версии ПО изменения затронули 15% кодовой базы. Однако трудозатраты на тестирование этих изменений оказались почти такими же, как на тестирование всей системы при первичной разработке.

Вопросы:

1.                 Какой экспериментально установленный процент изменений обычно вводится в новой версии?

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

3.                 Что на этапе проектирования первой версии позволяет снизить эти затраты в будущем?

Задача 40. Ситуация: Затраты на сопровождение и исправление дефектов в долгоживущем и широко тиражируемом продукте оказались в несколько раз выше, чем затраты на его первичную разработку.

Вопросы:

1.                 Какие три составляющие включают в себя затраты на сопровождение?

2.                 Какая из этих составляющих обычно является доминирующей для таких продуктов?

3.                 Как тираж продукта косвенно влияет на затраты на сопровождение?

Задача 41. Ситуация: При оценке затрат на испытания не были учтены работы по «конфигурационному управлению» тестовыми сценариями и данными.

Вопросы:

1.                 К каким практическим проблемам в процессе тестирования это может привести?

2.                 В какую из составляющих затрат на сопровождение (см. рис. 8.6) входят эти работы?

3.                 Почему контроль целостности тестовой модели (например, базы данных) является важной статьей затрат?

Задача 42. Ситуация: Заказчик хочет использовать продукт в условиях, которые не были оговорены в Техническом задании и контракте (например, при больших нагрузках). При испытаниях в этих условиях продукт работает неудовлетворительно.

Вопросы:

1.                 В каких пределах, согласно лекции, разработчик обязан удовлетворять требования заказчика?

2.                 Как должна квалифицироваться доработка продукта для удовлетворения новых, неоговоренных требований?

3.                 Кто должен финансировать дополнительные испытания после таких доработок?

Задача 43. Ситуация: После передачи ПО в эксплуатацию пользователи начали массово сообщать о дефектах. Затраты поставщика на их анализ и устранение оказались непредсказуемо высокими.

Вопросы:

1.                 Какие факторы, перечисленные в лекции, влияют на затраты на устранение дефектов после передачи продукта?

2.                 Почему априори точно спрогнозировать эти затраты невозможно?

3.                 Какой метод оценки затрат на сопровождение предлагается использовать в лекции?

Задача 44. Ситуация: Для уникального, заказного программного продукта первичную разработку и последующую модернизацию выполняет один и тот же коллектив.

Вопросы:

1.                 Какая проблема управления и финансирования возникает в такой организации работ?

2.                 Чем отличается организация сопровождения для широко тиражируемых продуктов?

3.                 Какую выгоду получает заказчик от работы одного коллектива над разработкой и модернизацией?

Задача 45. Ситуация: При испытаниях выявлен дефект, который проявляется только при определенной, редко встречающейся конфигурации оборудования у 1% пользователей. Исправление требует значительных архитектурных изменений.

Вопросы:

1.                 Как метод оценки рисков может помочь в принятии решения об исправлении такого дефекта?

2.                 Какие критерии приоритезации (значимость для системы, риск) здесь вступают в противоречие?

3.                 Какое согласование с заказчиком необходимо провести перед принятием решения?

Комплексные и Междисциплинарные Задачи

Задача 46.  Ситуация: Проект по разработке медицинского ПО идет по Agile-методологии с частыми релизами. Команда тестирования не успевает проводить полный цикл сертификационных испытаний для каждого инкремента.

Вопросы:

1.                 Как совместить принцип «испытания должны сопутствовать всем этапам жизненного цикла» с итеративной разработкой?

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

3.                 Как должна быть организована «матрица отслеживания требований» в условиях постоянно меняющегося бэклога продукта?

Задача 47. Ситуация: Сторонний аудит выявил, что в компании отсутствует единый процесс обеспечения качества, объединяющий стратегии и измерения эффективности испытаний.

Вопросы:

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

2.                 Какие элементы (люди, инструменты и т.д.) должны быть учтены в этом едином процессе?

3.                 К каким долгосрочным последствиям для бизнеса может привести отсутствие такого процесса?

Задача 48. Ситуация: Заказчик требует провести приемосдаточные испытания на своей площадке, но не предоставляет полноценный доступ к своей тестовой среде, имитирующей рабочую, ссылаясь на соображения безопасности.

Вопросы:

1.                 Какой ключевой принцип подготовки тестовой среды нарушается?

2.                 Какие риски для обеих сторон возникают в этой ситуации?

3.                 Какие компромиссные решения (например, совместное построение среды, использование симуляторов) можно предложить?

Задача 49. Ситуация: В рамках проекта по модернизации унаследованной системы 90% тестов выполняются вручную из-за сложности автоматизации старого кода. Это делает процесс медленным и дорогим.

Вопросы:

1.                 Какой «перспективный метод повышения качества и снижения затрат» не может быть в полной мере применен в данной ситуации?

2.                 Как следует подходить к планированию испытаний и оценке затрат для таких систем?

3.                 На какие наиболее критические функции следует направить ограниченные ресурсы автоматизации в первую очередь?

Задача 50. Ситуация: Разработчик и заказчик спорят о качестве ПО. Разработчик ссылается на успешно пройденные формальные тесты, а заказчик — на плохую производительность и неудобный интерфейс в реальной эксплуатации.

Вопросы:

1.                 Какие виды тестирования (функциональное, системное и т.д.), вероятно, были проведены, а какие — упущены?

2.                 Как отсутствие тестирования «удобства и простоты применения» и нефункциональных требований повлияло на результат?

3.                 Какой артефакт (план испытаний, матрица покрытия) должен был четко определить, какие аспекты качества подлежат проверке и как, чтобы избежать этого спора?