risk based testing что это

Тестирование на основе риска

Что такое риск-тестирование?

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

Риски могут быть положительными или отрицательными.

В этом уроке вы узнаете

Когда проводить тестирование на основе рисков

Риск-тестирование может быть реализовано в

Процесс управления рисками

Давайте теперь разберемся с этапами процесса управления рисками

Идентификация риска

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

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

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

Образец структуры структуры риска

Анализ рисков (включает количественный и качественный анализ)

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

Планирование реагирования на риски

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

Владелец риска несет ответственность за определение вариантов снижения вероятности и влияния назначенных рисков.

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

Риск непредвиденных обстоятельств

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

Мониторинг и контроль рисков

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

В таблице ниже приведена информация о

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

Подход, основанный на оценке риска

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

Основанный на оценке риска подход к тестированию системы

Диаграмма ниже дает четкий обзор вышеупомянутого процесса

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

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

Как проводить тестирование на основе рисков: полный процесс

В этом разделе описан процесс тестирования на основе риска

Давайте рассмотрим функциональные требования F1, F2, F3 и нефункциональные требования N1 и N2.

Конкретные цели теста : Перечисленные риски и цели теста специфичны для типов теста.

Процедура разработки процесса тестирования на основе риска

Общие задачи тестирования — эти общие задачи применимы к нескольким проектам и приложениям.

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

Давайте рассмотрим этап тестирования системы

Матрица определения приоритетов и оценки рисков

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

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

Это может быть классифицировано как Частое (A), Вероятное (B), Случайное (C), Удаленное (D), Невероятное (E), Исключенное (F)

Серьезность — это степень воздействия ущерба или потерь, вызванных неопределенным событием. Набирается от 1 до 4 и может быть классифицирован как Катастрофический = 1, Критический = 2, Маргинальный = 3, Незначительный = 4

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

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

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

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

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

Общий контрольный список для тестирования на основе рисков

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

Отчетность и метрики результатов тестирования на основе риска

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

Сводный отчет по тестам, отчет по тестированию

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

Оценка неотъемлемого риска и остаточного риска

Идентификация и анализ рисков также должны включать неотъемлемые риски, остаточные риски, вторичные риски и текущий риск

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

Профилирование рисков и отзывы клиентов

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

Обратная связь с клиентами

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

Преимущества тестирования на основе риска

Преимущества тестирования на основе риска приведены ниже

Резюме:

В программной инженерии тестирование на основе рисков является наиболее эффективным способом управления проектом на основе рисков.

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

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

Источник

Что такое риск-тестирование?

Цель тестирования на основе рисков — сфокусироваться на ключевых функциях и уделить им больше времени.

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

Что такое тестирование на основе рисков?

Тестирование на основе рисков (risk-based testing) — это метод тестирования программного обеспечения, который базируется на вероятности рисков.

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

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

В результате, если пользователь даже и обнаружит дефект, это не помешает ему использовать приложение и не окажет существенного влияния на бизнес.

Риски продукта, проекта и процесса

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

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

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

Стратегия тестирования на основе рисков

В стратегии risk-based testing риск используется в качестве критерия во всех фазах цикла тестирования, включая планирование, проектирование, реализацию, выполнение и отчетность.

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

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

Анализ рисков — первый шаг перед началом любого тестирования на основе рисков.

Преимущества тестирования на основе рисков

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

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

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

Когда использовать тестирование на основе рисков

Риски могут возрасти из-за целого ряда факторов. В частности, из-за неудачного проектирования, плохого тайм-менеджмента и неадекватных ресурсов. Это именно те ситуации, когда следует использовать risk-based testing.

Тестирование на основе рисков в Agile

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

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

Выбор объектов тестирования

Итак, кто должен оценивать риски и как проходит этот процесс? Лучшие кандидаты в оценщики — те, кто хорошо осведомлен о проблемах приложения в целом.

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

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

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

Распространенные ошибки при тестировании на основе рисков

Критически важно начать анализ рисков еще на стадиях планирования и разработки. Это позволяет должным образом проанализировать приложение и разработать эффективный подход к тестированию.

Заключение

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

Источник

Типы тестирования

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

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

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

«Исследовательское тестирование» и «Скриптовое тестирование» – это подходы к тестированию, а «черноящичное» или «белоящичное» – техники тестирования, поэтому их я сюда не включаю.

Типы рисков

Представьте, что вы что-то тестируете. Подумайте о единице тестирования – тест-идее, которая у вас, вероятно, есть. Что движет этой идеей?

Тестируя ПО, мы связываем наши тесты с каким-то типом продуктового риска.

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

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

«XYZ-тестирование» – это тестирование, сконцентрированное на рисках XYZ. Как я уже говорил выше, рассказывая о типах тестирования, тип тестирования – это тестирование, сконцентрированное на определенном типе риска.

Но вот в чем подвох…

Знаете ли вы, что существует более сотни различных типов продуктовых рисков? Некоторые из них мы и не подумаем называть «типами тестирования».

Если бы я попросил вас назвать максимальное количество типов тестирования, вы бы отлично справились, назвав 15-20. Я пробовал просить об этом команды в разных компаниях и внутри тест-сообщества, и обычно люди сходу называют около 15. Однако если бы я попросил вас назвать различные типы продуктовых рисков, то точно знаю, что вы назвали бы больше. Спрашивая о типах продуктовых рисков те же самые группы людей, вспомнивших о 15 типах тестирования, я получал около 50-60 ответов, прежде чем заканчивалось отведенное время. Они бы и больше назвали.

Почему нужно говорить о типах рисков, а не о типах тестирования

Вы немедленно увидите ряд преимуществ, если переключите свои рассуждения с типов тестирования на типы рисков:

Осторожно, ловушки!

У этого подхода есть ряд ловушек, о которых нужно знать.

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

Источник

Risk based testing что это

Что пишут в блогах

2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA

Привет! В блоге появляется мало новостей, потому что все переехало в telegram.

Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)

Онлайн-тренинги

Что пишут в блогах (EN)

Software Testing

Разделы портала

Про инструменты

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

Итак, во-первых: риски и проблемы зачастую сваливаются в одну кучу. Риск, по определению какой-то существующий или развивающийся фактор процесса, который обладает потенциально негативным воздействием на процесс и, как следствие, на его результат. Можно, конечно, дотянуть любую проблему до понятия риска, только зачем? В среднем, обычный тренинг по управлению рисками состоит всего на 20-25% из материалов про сам процесс управления рисками и описания типичных рисков, а в остальные 75% времени тренеры пытаются впихнуть под видом рисков описания процессных проблем под соусом «а ещё у вас может быть вот что…». Повторюсь — зачем?

Итак, разберёмся.

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

Проще говоря, чтобы чётко разграничить риск и проблему: риск это то, что может случиться и привести к негативным последствиям, а проблема, это то, что уже случилось и мешает работать. И риск и проблема мешают или могут мешать работать, но способы работы с рисками и проблемами несколько разные: первые надо пытаться понять, найти и по возможности минимизировать их последствия до того как они «выстрелят», а с проблемами надо работать по факту — чинить или «тушить». Если отделить риски и проблемы, область управления рисками становится намного проще и понятнее.

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

Как работать с рисками

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

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

Что, обычно, вызывает сложности на начальных этапах работы с рисками: собственно начать (внести эти активности в рабочие планы); понять, что работа с рисками не rocket science и что эти активности как и любые другие должны быть спланированы, обеспечены ресурсами (исполнителями), выполнены, а результаты должны быть проанализированы (что «выстрелило», что — нет, с чем мы справились успешно и т.д.).

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

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

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

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

Типичные риски в тестировании ПО

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

Неполная оценка трудозатрат по проекту
Фредерик Брукс, в своей известной книге «Мифический человеко-месяц» отмечал, что именно этот риск является зачастую основной причиной невыполненных вовремя или вовсе провальных проектов.

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

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

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

Неполная оценка трудозатрат по тестированию
Аналогичный предыдущему риск, базирующийся в основном на нарушении принципа «оценку трудозатрат даёт исполнитель», но уже на уровне задач проекта по тестированию.

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

Как бороться: ревью и аудиты, формальные и «на бегу». В этом месте одна голова хорошо, а две — лучше.

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

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

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

Почему планы тестирования и разработки ещё должны быть связаны жестко на уровне единого плана проекта: в зону ответственности менеджера проекта, при фиксированной длительности итерации кроме всего прочего относится управление объёмом (scope) итерации, для чего ему необходимо видеть работы по тестированию. Грубо говоря, в ограниченной по времени итерации задача ПМ-а выбрать такой объём функционала, который команда успеет и сделать и протестировать.

Если менеджеру проекта оценки трудозатрат по тестированию не нужны (см. «клиника»), задача менеджера по тестированию внести свои работы в план проекта и связать их с соотв. задачами по разработке. В такой схеме сдвинуть сроки тестирования крайне сложно — какая-то часть работ по тестированию просто будет наглядно вылазить за deadline в плане или на диаграммах.

Стратегия тестирования отсутствует или непринята группой разработки или заказчиком
Формально не риск, а проблема, которая порождает риск, что стратегия тестирования не будет выполнена в той части задач, где пересекается с задачами разработки или не будет обеспечена ресурсами (зачастую именно проектным временем) и как результат всё равно не выполнена.

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

Увольнение сотрудников
Риск увольнения ключевого или не очень ключевого сотрудника есть всегда.

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

Что делать. Держать «скамейку запасных» не всегда возможно по экономическим причинам. «Кормить лучше» помогает далеко не всегда, а иногда (в случае как раз с не ключевыми товарищами) это ещё и попросту невыгодно. Что тут можно сделать? Самое очевидное, что я вижу, это «договориться с соседями» — просто побеседовать с соседними отделами или проектами (у которых этот риск тоже есть) и договориться, что в случае такого события, они смогут хоть как-то (если это позволит специфика продукта и текущая загруженность) помочь вам людьми. Аналогично, будьте готовы помочь сами. Да-да, спасение утопающих — дело рук самих утопающих.

Остальные проблемы
Изменение даже зафиксированных требований или их приоритетов, зачастую относят к рискам, как к фактору, который повлияет на объём итерации и соотв. приведёт к пересмотру планов и возможно срыву сроков поставки версии. Я бы не называл эту часть проектной работы риском — это реальность, с которой надо работать как с проектным ограничением и стараться не дотягивать даже до состояния проблемы. Действенным путём является как раз ограничение объёмов итерации по срокам, когда любое изменение в требованиях приводит к выталкиванию какого-то другого кусочка работ (и девелопмент и тестирование) в следующую итерацию. Принудительно или административно «заставить» требования не меняться ещё ни у кого не получалось – бизнес меняется, требования меняются и если Заказчик готов платить не только за естественные изменения в требованиях, но и за свои «фантазии» или «неорганизованность» — это надо принять и уметь с этим жить. Способы есть и они работают.

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

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

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

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

Источник