ISTQB_CTFL_Syllabus_2018-RU_3 — копия. Программа обучения Базового уровня Версия 2018 International Software Testing Qualifications Board
 Скачать 1.3 Mb.
|
|
Характеристики продукта включают: Риски, связанные с продуктом Качество базиса тестирования Размер продукта Сложность предметной области продукта Требования к характеристикам качества (например, безопасности, надежности) Требуемый уровень детализации тестовой документации Требования к юридическому и нормативному соответствию Характеристики процесса разработки включают: Стабильность и зрелость организации; Используемую модель разработки Подход к тестированию Используемые инструменты Процесс тестирования Сжатость сроков Характеристики людей включают: Навыки и опыт, особенно в аналогичных проектах и продуктах (например, знание предметной области) Командная сплоченность и лидерство Результаты тестирования включают: Количество и критичность выявленных дефектов Объем требуемых доработок 5.2.6 Методы оценки затрат на тестирование Существует несколько методов, используемых для оценки затрат на адекватное тестирование. Наиболее популярные методы - это: Метод, основанный на метриках - оценка затрат, использующая метрики ранее выполненных проектов или типовые значения Метод экспертной оценки - оценка затрат на основе опыта владельцев задач тестирования или экспертов Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 73 of 94 24 февраля 2019 © International Software Testing Qualifications Board Например, в гибкой разработке диаграммы сгорания являются примерами метода, основанного на метриках: трудозатраты фиксируются и отслеживаются, а затем используются для оценки скорости работы команды и определения объема работы, которую команда может выполнить в следующей итерации. Покер планирования является примером метода, основанного на экспертизе, поскольку члены команды оценивают трудозатраты на основе своего опыта (ISTQB- AT Базовый уровень. Тестировщик в сфере Гибких методологий). В итерационных методологиях примером метода, основанного на метриках, является модель устранения дефектов: сбор информации о количестве дефектов и времени на их исправление дает базис для оценки схожих проектов в будущем. Метод «Дельфи», с другой стороны, является экспертным методом, в котором группа экспертов дает оценки, исходя из своего опыта. (ISTQB-ATM Продвинутый уровень. Тест-менеджер). 5.3 Контроль и мониторинг тестирования Цель мониторинга тестирования заключается в сборе информации и обеспечении обратной связи о состоянии тестирования. Требуемая информация может собираться вручную или автоматически и использоваться для отслеживания прогресса тестирования, оценки выполнения критериев выхода или критериев готовности (в случае гибкой разработки), таких, как обеспечение требуемого покрытия рисков продукта, требований или критериев приемки. Контроль тестирования представляет собой любые корректирующие действия, предпринятые на основании полученной информации или метрик. Действия могут охватывать любую активность тестирования и влиять на любую активность жизненного цикла программного обеспечения. Примеры действий по контролю тестирования: Повторная приоритизация тестов при реализации риска (например, нарушения сроков поставки программного обеспечения) Изменение графика тестирования из-за доступности или недоступности тестовой среды или других ресурсов Повторная проверка выполнения критериев входа или выхода для элемента тестирования, который дорабатывался 5.3.1 Контроль и мониторинг тестирования Метрики могут собираться во время и по завершении тестирования, чтобы оценить: Прогресс относительно запланированного графика и бюджета Текущее качество объекта тестирования Адекватность подхода к тестированию Эффективность активностей тестирования по достижению целей тестирования Типичные метрики тестирования включают: Процент выполненных работ по подготовке тестовых сценариев (или процент разработанных тестовых сценариев) Процент выполненных работ по подготовке тестовой среды Метрики выполнения тестов: количество выполненных/невыполненных тестовых сценариев, количество тестовых условий или сценариев, выполненных успешно/неуспешно Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 74 of 94 24 февраля 2019 © International Software Testing Qualifications Board Информацию о дефектах: плотность дефектов, количество обнаруженных и исправленных дефектов, частоту отказов и результаты подтверждающих тестов Покрытие тестами требований, пользовательских историй, критериев приемки, рисков или кода Информацию о выполнении задач, распределении и использовании ресурсов, трудозатратах Стоимость тестирования, включая сравнение стоимости с выгодой от нахождения следующего дефекта или от выполнения следующего теста 5.3.2 Цели, содержание и аудитория отчетов о тестировании Цель отчетности состоит в обобщении и предоставлении информации по итогам и во время тестирования. Отчет, подготовленный во время тестирования, называется отчетом о ходе тестирования; отчет, подготовленный по итогам, называется итоговым отчетом о тестировании. Во время мониторинга и контроля тестирования руководитель тестирования регулярно публикует для заинтересованных сторон отчеты о ходе тестирования. Помимо разделов, общих для отчета о ходе тестирования и итогового отчета о тестировании, отчет о ходе тестирования может включать: Статус активностей тестирования и прогресс по сравнению с планом тестирования Факторы, препятствующие прогрессу Тестирование, запланированное на следующий отчетный период Качество объекта тестирования Когда критерии выхода выполнены, руководитель тестирования готовит итоговый отчет о тестировании. В этом отчете приводится краткое описание выполненного тестирования (на основе последнего отчета о ходе тестирования и другой информации). Обычно итоговые отчеты и отчеты о ходе тестирования включают: Резюме проведенного тестирования Информацию о том, что произошло во время тестирования Информацию об отклонениях от плана, включая отклонения в расписании, длительности выполнения или затратах Информацию о качестве тестирования и качестве продукта с точки зрения критериев выхода или критериев завершения Информацию о факторах, которые блокировали или продолжают блокировать тестирование Метрики дефектов, тестовых сценариев, покрытия, прогресса тестирования и использования ресурсов (например, как описано в 5.3.1) Информацию об остаточных рисках (см. раздел 5.5) Перечень тестовых артефактов, которые можно повторно использовать Содержимое отчета о тестировании зависит от проекта, корпоративных требований и жизненного цикла разработки программного обеспечения. Например, для сложных, формальных проектов с большим числом заинтересованных лиц может потребоваться более подробная и строгая отчетность. В качестве другого примера: в гибкой разработке отчеты о ходе тестирования могут быть частью панели задач, сводки по дефектам и диаграммы Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 75 of 94 24 февраля 2019 © International Software Testing Qualifications Board сгорания, которые обсуждаются на ежедневных встречах (см. ISTQB AT Базовый уровень. Тестировщик в сфере Гибких методологий). Помимо контекста проекта, при подготовке отчетности нужно учитывать особенности аудитории. Тип и объем информации, включаемые в отчет для технических специалистов или группы тестирования, будут отличаться от информации в отчете для менеджмента. В первом случае может быть важна подробная информация о типах дефектов и тенденциях. В последнем случае может быть уместным отчет более высокого уровня (например, статус дефектов, сгруппированных по приоритету, информация о бюджете и расписании, успешные/неуспешные/непроверенные тестовые условия). Стандарт ИСО (ISO/IEC/IEEE 29119-3) описывает два типа отчетов о тестировании: отчет о ходе тестирования и отчет о завершении тестирования (называемый в этом документе итоговым отчетом) и содержит структуру и примеры оформления отчетов каждого типа. 5.4 Управление конфигурацией Целью управления конфигурацией является обеспечение и поддержка целостности компонента или системы, тестового обеспечения и их взаимосвязей между собой на протяжении жизненного цикла проекта и продукта. Для поддержки тестирования управление конфигурацией может потребовать выполнения следующих условий: Все элементы тестирования однозначно идентифицированы, связаны между собой, находятся под версионным контролем, все изменения в них отслеживаются Все элементы тестового обеспечения однозначно идентифицированы, связаны между собой и с версиями элементов тестирования, находятся под версионным контролем, все изменения отслеживаются, обеспечивая трассируемость на протяжении всего процесса тестирования Все документы и программные элементы идентифицированы и однозначно указаны в тестовой документации Инфраструктура и процедуры управления конфигурацией должны быть подготовлены и выполнены на этапе планирования тестирования. 5.5 Риски и тестирование 5.5.1 Определение риска Риск подразумевает наступление некоторого негативного события в будущем. Уровень риска можно определить через вероятность события и серьезность последствий. 5.5.2 Риски проекта и продукта Риск продукта – это возможное несоответствие некоторого артефакта (спецификации, компонента, системы или теста и т.д.) потребностям пользователей и заинтересованных сторон. Когда риски продукта связаны с конкретными характеристиками качества (функциональной пригодностью, надежностью, производительностью, практичностью, безопасностью, совместимостью, сопровождаемостью и переносимостью), их также называют рисками качества. Примеры рисков продукта: Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 76 of 94 24 февраля 2019 © International Software Testing Qualifications Board Программное обеспечение не выполняет функции, указанные в спецификации Программное обеспечение не выполняет функции, ожидаемые пользователями, клиентами и/или заинтересованными сторонами Системная архитектура не поддерживает нефункциональные требования Вычисления выполняются неверно в каких-то ситуациях Неверная реализация в коде структуры управления циклом Неадекватное время отклика высоконагруженной системы Отзывы пользователей о продукте показывают, что их ожидания не оправдались Риски проекта связаны с событиями, препятствующими достижению целей проекта. Примеры рисков проекта: Проектные проблемы: o Задержки поставки, выполнения задач, выполнения критериев выхода или критериев готовности o Неточные оценки, перераспределение средств на проекты с более высоким приоритетом или общие сокращения затрат по всей организации могут привести к неадекватному финансированию o Поздние изменения могут привести к существенным доработкам Организационные проблемы: o Недостаток навыков, обучения или численности персонала o Проблемы с персоналом могут вызвать конфликты и серьезные трудности o Пользователи, бизнес-пользователи или эксперты предметной области могут быть заняты другими работами Политические проблемы: o Тестировщики не могут адекватно сообщать о своих потребностях и/или результатах тестирования o Разработчики и/или тестировщики не могут отслеживать информацию, полученную при тестировании и рецензировании (не стремясь улучшить методы разработки и тестирования) o Может быть неправильное отношение или ожидания от тестирования (недооценивается важность обнаружения дефектов во время тестирования и т.д.) Технические проблемы: o Требования могут быть определены недостаточно хорошо o Требования могут быть невыполнимыми в текущих условиях o Тестовая среда может быть не готова вовремя Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 77 of 94 24 февраля 2019 © International Software Testing Qualifications Board o Преобразование данных, планирование миграции и их инструментальная поддержка могут быть не готовы вовремя o Слабые стороны процесса разработки могут влиять на согласованность или качество артефактов проекта, таких как дизайн, код, конфигурация, тестовые данные и тестовые сценарии o Проблемы управления дефектами могут привести к накоплению дефектов и росту технического долга Проблемы с поставщиками: o Третья сторона может не предоставить необходимый продукт или услугу, или обанкротиться o Контрактные проблемы могут вызвать серьезные трудности для проекта Проектные риски могут влиять как на разработку, так и на тестирование. В некоторых случаях руководители проектов несут ответственность за управление всеми проектными рисками; руководители тестирования обычно отвечают за управление рисками, связанными с тестированием проекта. 5.5.3 Тестирование, основанное на рисках, и качество продукта Риски используются для распределения усилий во время тестирования. Они используются для принятия решения о том, где и когда начинать тестирование, и для выявления областей, требующих большего внимания. Тестирование используется с целью снижения вероятности возникновения неблагоприятного события и снижения последствий при наступлении этого события. Тестирование используется как деятельность по снижению риска и для обеспечения обратной связи, как по выявленным рискам, так и по остаточным (нерешенным) рискам. Тестирование, основанное на рисках, обеспечивает возможность заранее снизить уровень риска продукта. Оно включает анализ рисков продукта (идентификацию рисков, оценку вероятности и последствий от их наступления). Полученная информация используется для планирования тестирования, разработки, подготовки и выполнения тестовых сценариев, а также для мониторинга и контроля тестирования. Ранний анализ рисков продукта способствует успеху проекта. В рамках подхода, основанного на рисках, результаты анализа рисков продукта могут быть использованы для: Выбора методов тестирования Выбора уровней и типов тестирования, которые необходимо выполнить (например, тестирования безопасности, тестирования доступности) Определения объема тестирования Приоритезации тестирования с целью найти критические дефекты как можно раньше Выявления каких-либо дополнительных мер, помимо тестирования, которые могут снизить риски (например, обучения менее опытных проектировщиков) Тестирование, основанное на рисках, опирается на коллективные знания заинтересованных сторон проекта и выполнение ими анализа рисков продукта. Чтобы минимизировать вероятность неуспеха продукта, активности по управлению рисками обеспечивают дисциплинированный подход к: Анализу (и повторной оценке на регулярной основе) того, что может пойти не так (рисков) Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 78 of 94 24 февраля 2019 © International Software Testing Qualifications Board Определению, какие риски важны для дальнейшей работы Выполнению действий по снижению этих рисков Разработке планов действий в чрезвычайных ситуациях, если риски станут реальными событиями Кроме того, тестирование может выявить новые риски, помочь определить, какие риски следует смягчить, и снизить неопределенность в отношении рисков. 5.6 Управление дефектами Поскольку одной из целей тестирования является обнаружение дефектов, необходимо регистрировать дефекты, обнаруженные во время тестирования. Способ регистрации дефектов может варьироваться в зависимости от контекста, тестируемого компонента или системы, уровня тестирования и модели жизненного цикла. Любые выявленные дефекты должны быть изучены и отслеживаться от момента обнаружения и классификации до принятия решения по ним (например, исправления дефектов и успешного подтверждающего тестирования решения, отсрочки до следующего релиза, трактовки как постоянного ограничения продукта и т. д.). Чтобы управлять дефектами до принятия решения по ним, в организации должен существовать процесс управления дефектами, который включает в себя жизненный цикл и правила классификации дефектов. Этот процесс должен быть согласован со всеми, кто участвует в управлении дефектами, включая проектировщиков, разработчиков, тестировщиков и владельцев продуктов. В некоторых организациях регистрация и отслеживание дефектов могут быть очень слабо формализованными. Во время процесса управления дефектами некоторые из отчетов могут содержать описания ложных срабатываний, а не фактических сбоев из-за дефектов. Например, тест мог пройти неуспешно при сбое сетевого соединения или таймауте. Такое поведение не является следствием дефекта объекта тестирования, но аномалией, которую необходимо исследовать. Тестировщики должны попытаться свести к минимуму количество ложных срабатываний, принимаемых за дефекты. Дефекты могут быть обнаружены во время кодирования, статического анализа, рецензирования, динамического тестирования или эксплуатации программного продукта. Дефекты могут сообщать о проблемах в коде или эксплуатируемых системах, в документации любого типа, включая требования, пользовательские истории и критерии приемки, документацию разработки, документацию тестирования, руководства пользователя или руководства по установке. Чтобы иметь продуктивный и эффективный процесс управления дефектами, организации могут определять стандартный набор атрибутов, правила классификации и жизненный цикл дефектов. Типичные отчеты о дефектах имеют следующие цели: Предоставлять разработчикам и другим сторонам информацию о произошедших негативных событиях, чтобы они могли определить побочные эффекты, изолировать проблему с минимальными затратами на воспроизведение и исправить потенциальные дефекты по мере необходимости, или решать проблемы другими способами Обеспечить руководителей тестирования инструментами отслеживания качества продукта и влияния на тестирование (например, если сообщается о большом количестве дефектов, то тестировщики будут вынуждены тратить много времени на отчетность по найденным дефектам вместо того, чтобы запускать тесты; следовательно, нужно больше подтверждающего тестирования) Предоставить идеи для совершенствования процессов тестирования и разработки Сообщение о дефекте, созданное во время динамического тестирования, обычно включает: Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 79 of 94 24 февраля 2019 © International Software Testing Qualifications Board Идентификатор дефекта Заголовок и краткое описание найденного дефекта Дату сообщения о дефекте, информацию об авторе сообщения Идентификацию элемента тестирования (проверяемого элемента конфигурации) и среды Фазу жизненного цикла разработки, в которой обнаружен дефект Описание дефекта, достаточное для его воспроизведения и принятия решения, включая системные журналы, скриншоты, дампы базы данных или записи (если они созданы во время выполнения теста) Ожидаемые и фактические результаты Область или степень влияния дефекта на интересы заинтересованной стороны (критичность) Срочность/приоритет для исправления Статус дефекта (например, открыт, отложен, дубликат, ожидает исправления, ожидает проверки, повторно открыт, закрыт) Выводы, рекомендации и согласования Глобальные проблемы, например, области, которые будут затронуты исправлением дефекта История изменений, например, последовательность действий членов команды проекта, чтобы изолировать дефект, исправить и подтвердить исправление дефекта Ссылки, включая ссылку на тестовый сценарий, который обнаружил дефект Некоторые из этих деталей могут автоматически включаться и/или настраиваться при использовании инструментов управления дефектами. Например, автоматическое присваивание идентификатора дефекта, назначение и обновление статуса дефекта на протяжении жизненного цикла и т.д. Дефекты, обнаруженные при статическом тестировании, в частности, при рецензировании, как правило, документируются по-другому, например, в примечаниях к протоколу совещания. Пример содержимого сообщения о дефекте можно найти в стандарте ИСО (ISO/IEC/IEEE 29119- 3) (где сообщения о дефектах называются сообщениями об инцидентах). |