ISTQB_CTFL_Syllabus_2018-RU_3 — копия. Программа обучения Базового уровня Версия 2018 International Software Testing Qualifications Board
 Скачать 1.3 Mb.
|
|
Завершение тестирования Активности по завершению тестирования собирают данные из выполненных активностей тестирования для обобщения опыта, тестового обеспечения и любой другой соответствующей информации. Активности по завершению тестирования происходят на вехах проекта, например, по завершению выпуска релиза программного обеспечения системы, завершению (отмене) проекта тестирования, окончанию итерации проекта с гибкой методологией (например, как часть итогового митинга), завершению уровня тестирования, или завершению сопровождения релиза. Завершение тестирования состоит из следующих основных активностей: Проверка закрытия всех отчетов о дефектах, входящих запросов на изменение или набора задач продукта для любых дефектов, которые остаются не реализованными в конце выполнения тестирования Создание сводного отчета по тестированию для передачи заинтересованным лицам Завершение и архивирование тестового окружения, тестовых данных, инфраструктуры тестирования и другого тестового обеспечения для последующего использования Передача тестового обеспечения команде сопровождения, другим проектным командам, и/или другим заинтересованным лицам, которые могут извлечь выгоду из его использования Анализ полученных уроков для определения изменений, необходимых для будущих итераций, релизов и проектов Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 23 of 94 24 февраля 2019 © International Software Testing Qualifications Board Использование собранной информации для повышения зрелости процесса тестирования 1.4.3 Рабочие продукты тестирования Создание рабочих продуктов тестирования — это часть процесса тестирования. Поскольку существует значительное различие в том, как организации реализовывают процесс тестирования, есть существенные различия и в типах рабочих продуктах, созданных в ходе этого процесса - как эти рабочие продукты организованы и управляются, и в названиях, используемых для этих рабочих продуктов. Эта программа соответствует описанному выше процессу тестирования, а также рабочим продуктам, описанным в этой программе и в Стандартном глоссарии терминов ISTQB. Стандарт ИСО (ISO/IEC/IEEE 29119-3) может также служить руководством для создания рабочих продуктов тестирования. Используя средства управления тестированием и управления дефектами, можно отслеживать и управлять многими рабочими продуктами тестирования, описанными в этом разделе (см. главу 6). Рабочие продукты планирования тестирования Рабочие продукты планирования тестирования – это один или несколько планов тестирования. План тестирования содержит информацию о базисе тестирования, с которым другие рабочие продукты тестирования будут связаны через информацию о трассируемости (см. ниже и раздел 1.4.4), а также критерии выхода (или определение готовности), которые будут использоваться во время мониторинга и контроля тестирования. Планы тестирований описаны в разделе 5.2. Рабочие продукты мониторинга и контроля тестирования Рабочие продукты мониторинга и контроля тестирования – это обычно различные типы отчетов о тестировании, включая отчеты о ходе тестирования (выпускаемые оперативно и/или на регулярной основе) и сводные отчеты о тестировании (выпускаемые на различных этапах завершения). Все отчеты о тестировании должны обеспечить соответствующей аудитории подробные сведения о ходе тестирования на дату отчета, включая обобщение результатов выполнения тестирования после их получения. Рабочие продукты мониторинга и контроля тестирования также должны учитывать интересы управления проектами, такие как завершение задач, распределение и использование ресурсов и трудозатрат. Мониторинг и контроль тестирования, а также рабочие продукты, созданные в ходе этих активностей, более подробно описаны в разделе 5.3 данной программы. Рабочие продукты анализа тестирования Рабочие продукты анализа тестирования состоят из определенных и приоритизированных тестовых условий, каждое из которых в идеале двунаправленно прослеживается до конкретного элемента (элементов) базиса тестирования, который они покрывают. Для исследовательского тестирования анализ тестирования может включать и создание концепций тестирования. Анализ тестирования может также привести к обнаружению и составлению отчетов о дефектах в базисе тестирования. Рабочие продукты проектирования тестов Результатом проектирования тестов являются тестовые сценарии и наборы тестовых сценариев для выполнения тестовых условий, определенных в анализе тестирования. Часто хорошей практикой считается проектирование высокоуровневых тестовых сценариев без конкретных значений для входных данных и ожидаемых результатов. Такие высокоуровневые тестовые сценарии многократно используются для нескольких циклов тестирования с различными конкретными данными, но при этом все еще достаточно документируют область Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 24 of 94 24 февраля 2019 © International Software Testing Qualifications Board применения тестового сценария. В идеале, каждый тестовый сценарий двунаправленно прослеживается к тестовым условиям, которые он покрывает. Проектирование тестов также приводит к разработке и/или установлению необходимых тестовых данных, к проектированию тестового окружения и определению инфраструктуры и инструментов, хотя объем документирования этих результатов может существенно различаться. Тестовые условия, определенные в анализе тестирования, могут быть дополнительно уточнены при проектировании тестов. Рабочие продукты реализации тестов Рабочие продукты реализации тестов включают: Процедуры тестирования и последовательности этих процедур тестирования Наборы тестов Расписания выполнения тестов В идеале после завершения реализации тестов достижение критериев покрытия, установленных в плане тестирования, может быть продемонстрировано посредством двунаправленной трассируемости между процедурами тестирования и конкретными элементами базиса тестирования, с помощью тестовых сценариев и тестовых условий. В некоторых случаях реализация тестов включает создание рабочих продуктов, использующих или используемых инструментами, такими как службы виртуализации и автоматизированные тестовые сценарии. Реализация тестов также может привести к созданию и проверке тестовых данных и тестового окружения. Полнота документирования результатов проверки данных и/или окружения может существенно различаться. Тестовые данные служат для присвоения конкретных значений входным данным и ожидаемым результатам тестовых сценариев. Такие конкретные значения вместе с точными указаниями об использовании конкретных значений превращают высокоуровневые тестовые сценарии в исполняемые низкоуровневые тестовые сценарии. Один и тот же высокоуровневый тестовый сценарий может использовать разные тестовые данные при выполнении в разных релизах объекта тестирования. Конкретные ожидаемые результаты, связанные с конкретными тестовыми данными, определяются с помощью тестового предсказателя. При исследовательском тестировании во время выполнения тестов могут создаваться некоторые рабочие продукты для разработки и реализации тестов, хотя степень документирования исследовательских тестов (и их трассируемость до конкретных элементов базиса тестирования) может существенно различаться. Тестовые условия, определенные в анализе тестирования, могут быть дополнительно уточнены при реализации тестов. Рабочие продукты выполнения тестов Рабочие продукты выполнения тестов включают: Документацию о состоянии отдельных тестовых сценариев или процедур тестирования (например, готов к запуску, пройден, не пройден, блокирован, осознанный пропуск и т. д.) Отчеты о дефектах (см. раздел 5.6) Документацию о том, какие элемент(ы) теста, объект(ы) тестирования, инструменты тестирования, и тестовое обеспечение были задействованы в тестировании Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 25 of 94 24 февраля 2019 © International Software Testing Qualifications Board В идеале, как только выполнение тестов завершено, состояние каждого элемента базиса тестирования можно определить и сообщить через двунаправленную трассируемость к соответствующим процедурам тестирования. Например, можно указать, для каких требований успешно выполнены все запланированные тесты, для каких требований не прошли тесты и/или имеют связанные с ними дефекты, для каких требований запланировали тесты, которые ожидают выполнения. Это позволяет проверить, что критерии покрытия были достигнуты, и позволяет в понятных формулировках сообщать о результатах тестирования заинтересованным лицам. Рабочие продукты завершения тестирования Рабочие продукты завершения тестирования состоят из сводных отчетов тестирования, мероприятий по улучшению последующих проектов или итераций (например, ретроспектива после проекта с гибкой методологией), запросов на изменение или набора задач продукта, и окончательного тестового обеспечения. 1.4.4 Трассируемость между базисом тестирования и рабочими продуктами тестирования Как указано в разделе 1.4.3, рабочие продукты тестирования и названия этих рабочих продуктов существенно различаются. Независимо от этих различий для осуществления эффективного мониторинга и контроля тестирования важно установить и поддерживать трассируемость на протяжении всего процесса тестирования между каждым элементом базиса тестирования и различными рабочими продуктами тестирования, связанных с этим элементом. В дополнение к оценке покрытия тестирования, хорошая трассируемость поддерживает: Анализ влияния изменений Проведение тестирования, поддающееся аудиту Достижение критериев управления ИТ Улучшение понятности отчетов о ходе тестирования и сводных отчетов, включая статус элементов базиса тестирования (например, требования, для которых прошли тесты, требования, для которых тесты провалились, и требования, ожидающие тестирования) Согласование технических аспектов тестирования с заинтересованными лицами в терминах, которые они могут понять Предоставление информации для оценки качества продукции, потенциала процессов и развития проекта в соответствии с бизнес-целями Некоторые инструменты управления тестированием предоставляют модели рабочих продуктов тестирования, которые соответствуют части или всем рабочим продуктам тестирования, изложенных в этом разделе. Некоторые организации создают собственные системы управления для организации рабочих продуктов и обеспечения требуемой трассируемости информации. 1.5 Психология тестирования Люди принимают участие в разработке программного обеспечения, в том числе и тестировании программного обеспечения. Таким образом, психология человека оказывает важное влияние на тестирование программного обеспечения. 1.5.1 Психология человека и тестирование Выявление дефектов во время статического тестирования, такого как рецензирование требований или сессий уточнения пользовательских историй, или выявление отказов во время Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 26 of 94 24 февраля 2019 © International Software Testing Qualifications Board выполнения динамического теста может быть воспринято как критика продукта и его автора. Элемент человеческой психологии, называемый предвзятостью подтверждения, может затруднить принятие информации, которая не совпадает с текущими убеждениями. Например, поскольку разработчики ожидают, что их код будет правильным, у них есть предвзятость подтверждения, которое затрудняет принятие того, что код неправильный. В дополнение к предвзятости подтверждения, другие стереотипы людей могут затруднить понимание или принятие информации, полученной в результате тестирования. Кроме того, общепринятой человеческой чертой является то, что виноват носитель плохих новостей, а информация, полученная в результате тестирования, часто содержит плохие новости. В результате этих психологических факторов некоторые люди могут воспринимать тестирование как разрушительную деятельность, даже если она в значительной степени способствует развитию проекта и качеству продукта (см. разделы 1.1 и 1.2). Чтобы попытаться уменьшить эти восприятия, информацию о дефектах и отказах следует сообщать конструктивным образом. Таким образом, напряженность между тестировщиками и аналитиками, владельцами продуктов, дизайнерами и разработчиками можно уменьшить. Это относится как к статическому, так и к динамическому тестированию. Тестировщики и руководители по тестированию должны иметь хорошие коммуникационные навыки, чтобы иметь возможность эффективно сообщать о дефектах, отказах, результатах тестирования, ходе тестирования, и рисках, а также строить позитивные отношения с коллегами. Следующие примеры хорошо передают способы общения: Начните с сотрудничества, а не сражения. Напомните каждому об общей цели улучшения качества системы. Подчеркните преимущества тестирования. Например, информация о дефектах может помочь авторам улучшить свои рабочие продукты и навыки. Для организации, дефекты, найденные и зафиксированные во время тестирования, сохранят время и деньги и уменьшат общий риск качества продукции. Сообщайте результаты тестирования и другие выводы нейтральным, сфокусированном на фактах, способом, без критики автора. Пишите объективные и фактические отчеты о дефектах и выводах рецензирования. Попытайтесь понять, что другие люди чувствуют, и причины их негативной реакции на информацию. Убедитесь, что другой человек понял, что вы сказали, и наоборот. Характерные цели тестирования обсуждались ранее (см. раздел 1.1). Четкое определение правильного набора целей тестирования имеет важные психологические последствия. Большинство людей склонно корректировать свои планы согласно целям, установленным командой, руководством и другими заинтересованными лицами. Также важно, чтобы тестировщики придерживались этих целей с минимальными личными предубеждениями. 1.5.2 Мышление тестировщика и разработчика Разработчики и тестировщики часто думают по-разному. Основной целью разработчика является проектирование и создание продукта. Как обсуждалось ранее, цели тестирования включают верификацию и валидацию продукта, поиск дефектов до релиза и т. д. Это разные наборы целей, которые требуют разного образа мышления. Объединение этих образов мышления вместе помогает достичь более высокого уровня качества продукции. Образ мышления отражает предположения человека и предпочтительные методы как для принятия решений, так и для решения проблем. Образ мышления тестировщика должен включать любопытство, профессиональный пессимизм, критический взгляд, внимание к деталям и мотивацию хороших и позитивных коммуникаций и отношений. Образ мышления тестировщика имеет тенденцию к развитию по мере приобретения опыта тестировщиком. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 27 of 94 24 февраля 2019 © International Software Testing Qualifications Board Образ мышления разработчика может включать в себя некоторые элементы образа мышления тестировщика, но успешные разработчики чаще заинтересованы в разработке и создании решений, чем в рассмотрении того, что может быть неправильно в этих решениях. Кроме того, подтверждение предвзятости затрудняет поиск ошибок в собственной работе. При правильном образе мышления разработчики могут протестировать свой собственный код. Различные модели жизненного цикла разработки программного обеспечения часто имеют разные способы организации тестировщиков и мероприятий по тестированию. Выполнение некоторых действий независимыми тестировщиками повышает эффективность обнаружения дефектов, что особенно важно для больших, сложных или критически важных для безопасности систем. Независимые тестировщики привносят перспективу, которая отличается от перспективы авторов продукта работы (т.е. бизнес-аналитиков, владельцев продукта, дизайнеров и программистов), поскольку их предубеждения отличаются от авторских. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 28 of 94 24 февраля 2019 © International Software Testing Qualifications Board 2. Тестирование в течение жизненного цикла разработки ПО – 100 мин Ключевые определения приемочное тестирование, альфа-тестирование, бета-тестирование, готовое программное обеспечение, тестирование интеграции компонентов, компонентное тестирование, подтверждающее тестирование, контрактное приемочное тестирование, функциональное тестирование, анализ влияния, интеграционное тестирование, тестирование в период сопровождения, нефункциональное тестирование, эксплуатационное приемочное тестирование, регрессионное тестирование, нормативное приемочное тестирование, каскадная модель разработки ПО, системное интеграционное тестирование, системное тестирование, базис тестирования, тестовый сценарий, тестовое окружение, уровень тестирования, объект тестирования, причина тестирования, тип тестирования, пользовательское приёмочное тестирование, тестирование методом белого ящика Цели обучения для главы «Тестирование в течение жизненного цикла разработки ПО» 2.1. Модели жизненного цикла разработки ПО FL-2.1.1. (К2) Объяснить взаимосвязь между мероприятиями по разработке программного обеспечения и мероприятиями по тестированию в жизненном цикле разработки программного обеспечения. FL-2.1.2. (К1) Определить причины, по которым модели жизненного цикла разработки программного обеспечения должны быть адаптированы к контексту характеристик проекта и продукта. |