Американский бизнесмен Уоррен Баффетт однажды сказал, что риск возникает по причине того, что вы незнаете, что вы делаете.
Тот же принцип можно применить и к тестированию программного обеспечения. Если вы не знаете, почему и что тестируете, увеличивается вероятность рисков. Для программного продукта риском является появление дефектов, влияющих на качество продукта. В конечном итоге это приводит к потере бизнеса и репутации.
Когда вы знаете о причинах сбоя некоторых функций или модулей продукта, это определяет риск. Таким образом, вы тестируете их в первую очередь для снижения или избежания рисков неисправности таких функций в работе. Весь этот процесс известен как тестирование на основе рисков или RBT (Risk-based testing).
RBT расставляет приоритеты и оптимизирует тестирование участков высокого риска в продукте на раннем этапе. Это будет гарантировать, что они работают должным образом с реальными пользователями. Такой подход будет логичным в гибкой среде, где короткие спринты требуют выборочного тестирования для предотвращения выпуска ПО с серьезными дефектами.
Что такое тестирование на основе рисков?
При тестировании программного обеспечения риск можно определить как непредвиденный сбой в безопасности, функциональности, производительности (угрозу) в производственной среде.
Используя тестирование на основе рисков (RBT), команды выявляют и оценивают эти риски. Затем они выполняют алгоритм тестирования, чтобы гарантировать, что наиболее критические риски проверяются на ранних этапах цикла разработки.
Последовательность действий при тестировании на основе рисков
Ниже приведены шаги, которые характеризуют успешный процесс RBT:
|
Сценарий |
Описание |
|
Сложные приложения |
Расставьте приоритеты в тестировании сложного ПО с множеством компонентов. Сосредоточьте внимание на областях, которые могут привести к сбоям из-за их сложности. |
|
Короткие сроки тестирования |
Используйте RBT для оптимизации усилий по тестированию проектов с жесткими графиками. Уделяйте особое внимание важным функциям в течение ограниченного времени. |
|
Системы высокого риска |
Применяйте RBT к системам с высоким уровнем риска. Это предотвратит существенные финансовые потери или потери данных из-за потенциальных сбоев. |
|
Ограничения бюджетирования |
Используйте RBT для эффективности процессов тестирования в рамках ограниченного бюджета. Так вы максимизируете продуктивность тестов с использованием имеющихся ресурсов. |
|
Соответствия и правила |
RBT обеспечит соблюдения нормативных требований в таких областях, как здравоохранение и финансы. |
|
Исторические данные о дефектах |
Сосредоточьте проверку RBT на модулях с историей повторяющихся дефектов. Уделите этим областям особое внимание в каждом цикле тестирования. |
Шаг 1: Идентификация рисков
Определите потенциальные риски, которые могут негативно повлиять на удобство использования, функциональность, производительность приложения. Используйте исторические данные, информацию из документов с требованиями, отчетов о дефектах, интервью с заинтересованными сторонами. Выполните анализ отзывов для сбора всех потенциальных рисков.
Шаг 2: Анализ рисков
Проанализируйте выявленные риски на первом этапе, чтобы получить более глубокое понимание. Оцените их вероятности и влияния. Для этого проведите обсуждения с заинтересованными сторонами, бизнес-аналитиками, тестировщиками, разработчиками и пользователями. Это двухэтапный процесс, направленный на комплексную оценку рисков.
Анализ риска = Вероятность * Влияние
Где «Вероятность» — это вероятность возникновения риска, а «Влияние» — это серьезность последствий, если они возникнут.
Шаг 3: Приоритизация рисков
Следующим шагом является определение приоритетности рисков на основе анализа. Классифицируйте приоритет как Высокий, Средний или Низкий, в зависимости от его вероятности и влияния. Высокоприоритетный риск имеет большую вероятность возникновения и оказывает огромное влияние на бизнес. Эти риски требуют немедленного внимания, интенсивных усилий по тестированию.
Шаг 4. Планирование и проектирование тестирования
Планируйте и разрабатывайте стратегию тестирования, график и тестовые сценарии на основе приоритетов рисков. Создайте подробный план тестов с указанием ресурсов, инструментов, сроков и типов тестов, таких как производительность, функциональность, безопасность и т. д.
Шаг 5: Выполнение теста
Выполните тестовые сценарии на основе стратегии проверки, начиная с тестов высокого риска. Отслеживайте ход тестирования, регистрируйте дефекты и постоянно переоценивайте риски.
Шаг 6: Переоценка рисков
В случае изменений в объеме проекта или внешних факторах проведите повторную оценку и пересмотрите приоритеты рисков одновременно с процессом тестирования.
Обновите анализ рисков, чтобы учесть изменения по мере их возникновения. Затем используйте эту обновленную информацию для выполнения соответствующих тестовых случаев, чтобы отразить высокоприоритетные риски во время RBT.
Шаг 7: Отчетность и обратная связь
Подготовьте подробный отчет о дефектах, а также отчеты с детальным описанием результатов, статуса снижения рисков и любых оставшихся рисков, которые необходимо устранить. Эта важная информация помогает принимать обоснованные решения о готовности к выпуску и решать, требуется ли дальнейшая оценка рисков.
Шаг 8: Закрытие теста
Оцените общий статус риска в конце цикла тестирования. Одобрение заинтересованными сторонами — это последний шаг к принятию финальной рабочей версии. Программное обеспечение готово к использованию, если уровень остаточного риска является приемлемым.
Пример процесса RBT
Давайте рассмотрим сценарий в контексте разработки программного обеспечения:
1. Определяем риски
Используется статистика, документы с требованиями, отчеты о дефектах, истории пользователей, интервью с заинтересованными сторонами, отзывы пользователей для выявления потенциальных рисков:
Удобство использования: проблемы совместимости браузера во время оформления заказа. Функциональность: ошибки интеграции платежного шлюза. Производительность: уязвимости безопасности в пользовательских данных во время транзакций.
2. Анализируем риски
Команда оценивает вероятность и влияние этих выявленных рисков посредством обсуждений с заинтересованными лицами, разработчиками и тестировщиками.
Вероятность x Влияние. Проблемы с платежным шлюзом имеют высокую вероятность (из-за сложности) и большое влияние (критичное для транзакций).
3. Обозначаем приоритет рисков
На основе анализа риски классифицируются как высокие, средние и низкие. Интеграция платежного шлюза представляет собой значительный риск и поэтому является приоритетной для тестирования.
4. Планируем и разрабатываем тестирование
Команда разрабатывает подробный план тестирования, уделяя особое внимание тестированию платежных шлюзов с использованием различных сценариев. Так обеспечивается безопасность транзакций и совместимость между браузерами.
5. Выполняем тест
Тестирование начинается с высокоприоритетных рисков интеграции платежного шлюза, тщательного мониторинга проблем и регистрации дефектов.
6. Переоцениваем риски
По ходу тестирования команда переоценивает риски. Например, во время текущих тестов изначально предполагалась перегрузка сервера во время пиковой нагрузки. Это расценивалось как потенциальный риск. Однако по ходу тестирования серверы эффективно справляются с нагрузкой. Это требует переоценки, потенциально снижая рейтинг риска перегрузки сервера.
Одновременно команда обнаруживает новый риск: производительность конкретной функции снижается при большой нагрузке пользователей. Это заставляет изменить приоритет для дальнейшего исследования и устранения последствий.
7. Создаем отчетность и обратную связь
Команда создает подробные отчеты о дефектах, статусе снижения рисков и результатах тестирования. Заинтересованные стороны могут использовать эту информацию для принятия обоснованных решений о готовности выпуска.
8. Закрываем тест
Преимущества тестирования на основе рисков
|
Плюсы RBT |
Описание |
Пример |
|
Эффективное использование ресурсов |
RBT оптимизирует трудозатраты, инструменты тестирования, усилия. Уделяет особое внимание областям высокого риска. |
Стартап в сфере электронной коммерции концентрирует тестирование на таких важных модулях, как «Оплата» и «Добавление в корзину», эффективно управляя ресурсами тестирования. |
|
Лучшее качество тестирования |
Расстановка приоритетов критически важных функций повышает общее качество программного обеспечения. |
Приложение для записи к врачу фокусирует усилия RBT на тестировании обработки данных пациентов, обеспечивая безопасные и точные консультации. |
|
Экономия средств при выполнении тестирования вовремя |
Раннее обнаружение дефектов высокого риска позволяет сэкономить значительные средства на более поздних стадиях разработки. |
Приложение для личного банкинга заранее выявляет уязвимости транзакций переводов, предотвращает потенциальные потери и поддерживает деловую репутацию. |
|
Обоснованные бизнес-решения |
RBT предлагает четкое представление о сбоях и готовности модулей высокого риска для принятия обоснованных решений о выпуске. |
Перед выпуском игровое приложение тестируется на кросс-платформенную совместимость с помощью RBT. Обеспечивается беспрепятственное взаимодействие с пользователем на разных платформах. |
|
Улучшенное управление рисками |
Структурированная идентификация и оценка рисков улучшают управление рисками в тестируемом приложении (AUT). |
Сайт онлайн-бронирования железнодорожных билетов выявляет и снижает риски, связанные с ошибками избыточного бронирования и отмены через RBT. |
|
Ориентация на клиента |
Согласовывает усилия по тестированию с потребностями бизнеса и ожиданиями клиентов, улучшая качество обслуживания пользователей. |
Приложение для потоковой передачи фильмов фокусирует усилия RBT на тестировании управления подписками пользователей, повышении доходов и удовлетворенности пользователей. |
|
Адаптивность к изменениям |
RBT быстро адаптируется к меняющимся требованиям в Agile-средах, обеспечивая успешные процессы тестирования. |
Платформа электронного обучения быстро тестирует и интегрирует новые функции, такие как обмен сертификатами в социальных сетях через RBT, в соответствии с требованиями пользователей. |
|
Оптимизированное тестовое покрытие |
Фокус внимания на областях высокого риска позволяет эффективно обеспечить комплексное тестирование при ограниченных ресурсах. |
Усовершенствованное управление рисками |
|
Снижение цены |
Раннее обнаружение серьезных ошибок снижает общие затраты на программное обеспечение и уменьшает проблемы, возникающие после его выпуска. |
Используя RBT, компания-разработчик программного обеспечения тестирует CRM-систему. Значительно сокращается количество исправлений после выпуска, повышается лояльность клиентов и снижаются затраты на исправления после выпуска. |
|
Соблюдение требований |
Помогает регулируемым отраслям соблюдать стандарты соответствия, уделяя приоритетное внимание тестированию в критических областях. |
Во время праздничной распродажи сайт электронной коммерции оптимизирует тестовое покрытие с помощью RBT, тестируя сложные области, имеющие решающее значение для производительности в условиях интенсивного трафика. |
Недостатки тестирования на основе рисков
|
Минусы RBT |
Описание |
Пример |
|
Риск пропуска/отсутствия охвата тестированием |
Фокусировка RBT на модулях с высоким риском может привести к игнорированию тестирования в областях с низким уровнем риска, что повлияет на общее впечатление от приложения. Неправильная оценка рисков в сложных приложениях может поставить под угрозу весь процесс тестирования. |
Для мобильного приложения для обмена сообщениями приоритетом является тщательное тестирование отправки, получения сообщений и вложений. А незначительные проблемы с удобством использования и пользовательским интерфейсом игнорируются. Эта погрешность приводит к неудовлетворительному пользовательскому опыту, несмотря на тщательное тестирование функциональности с помощью RBT. Аналогичным образом, в сложном телекоммуникационном приложении такие компоненты, как обмен сообщениями, системы вызовов и соединения с базами данных, могут создавать проблемы при правильном выявлении и оценке рисков. Это потенциально подрывает эффективность RBT. |
|
Чрезмерная зависимость от человеческого суждения |
RBT часто полагается на обратную связь от конкретных членов команды, на которую могут влиять предубеждения и суждения, ограничивающие эффективность процесса. |
Негативный прошлый опыт разработчика со сторонней интеграцией может привести к переоценке риска без объективного анализа. Это склоняет команду к чрезмерному сосредоточению внимания на снижении предполагаемого риска, потенциально игнорируя другие критические области во время тестирования. |
|
Требует постоянной переоценки |
RBT требует постоянной оценки и выявления рисков, что требует постоянных усилий и ресурсов. |
Для игрового приложения быстро меняющиеся игровые правила, контент и функции требуют постоянной оценки рисков, чтобы оставаться конкурентоспособными, что увеличивает рабочую нагрузку на команду. |
|
Неэффективен для новых приложений |
RBT может не соответствовать определенным типам тестирования, таким как исследовательское тестирование или тестирование удобства использования, которые требуют специального участия человека. |
В случае с новым игровым приложением виртуальной реальности отсутствие исторических данных усложняет оценку рисков и применение RBT. |
|
Неправильный расчет долгосрочных рисков |
RBT может чрезмерно сфокусироваться на непосредственных рисках, игнорируя долгосрочные проблемы масштабируемости и связанные с ними риски. |
Команда приложения для потоковой передачи музыки и видео может сосредоточиться исключительно на текущих лицензионных рисках, упуская из виду долгосрочные соображения, такие как расширение каналов распространения музыки и связанные с этим риски. |
|
Требуются обширные знания и опыт |
Внедрение RBT требует глубоких предметных и технических знаний, которых может не хватать небольшим командам, что создает проблемы при внедрении. |
Стартап, разрабатывающий носимые фитнес-трекеры, может столкнуться с трудностями при внедрении RBT из-за нехватки экспертов, разбирающихся в области здравоохранения и Интернета вещей. |
|
Не универсальное решение |
В определенных сферах может потребоваться участие человека и RBT в таких случаях может быть бессильным.
|
Во время тестирования устройства для чтения электронных книг, где удобство использования и интуитивность являются ключевыми факторами, RBT может оказаться непригодным, поскольку в нем отсутствует специальное участие человека, необходимое для таких типов тестирования. |
|
Отсутствие способности справиться со сложными совместными проектами. |
В сложных проектах, в которых участвуют несколько команд и заинтересованных сторон, согласование одних и тех же рисков для RBT может оказаться сложной задачей. |
При тестировании крупномасштабного проекта ERP заинтересованные стороны могут иметь разные взгляды на риски, что затрудняет достижение согласованности для RBT. |
В конце цикла тестирования команда оценивает общий статус риска. После одобрения всех участников программное обеспечение выпускается для использования клиентами. Это значит, что обеспечивается приемлемый уровень остаточного риска.
Лучшие практики внедрения тестирования на основе рисков в Agile
Работа в гибкой среде требует динамичного, коллективного и универсального подхода. RBT включает быструю, непрерывную разработку и тестирование.
Включение RBT в основы гибкой разработки
Сделайте оценку рисков регулярной практикой на собраниях Agile, таких как планирование спринта, ежедневные стендапы, ретроспективы и т. д. Это помогает согласовать цели спринта с усилиями по тестированию.
Совместное выявление и оценка рисков
Вовлекайте всех членов межфункциональных команд в оценку и идентификацию рисков. Эффективно используйте эти различные точки зрения для определения стратегии расширенного тестирования.
Регулярная переоценка рисков
После каждого спринта переоценивайте риски и цели тестирования с учетом изменений в объеме, среде, новых функциях, отзывах пользователей и т. д. Это помогает сосредоточить внимание на наиболее важных рисках в следующем спринте.
Расставление приоритетов в тестировании на основе рисков
При планировании спринтов в первую очередь сосредоточьтесь на функциях высокого риска. Критические проблемы решаются на ранней стадии, чтобы поддерживать готовность программного обеспечения к поставке после каждого спринта.
TestRail позволяет командам назначать приоритеты и классифицировать тесты на основе уровней риска. Это позволяет лучше планировать и распределять ресурсы в критически важных областях в соответствии с принципами RBT.
Использование метрики рисков в гибких информационных панелях
При визуализации и показе метрик, связанных с проектом , используйте метрики RBT. Они помогают отслеживать закрытие и статус риска. Это повышает наглядность последнего статуса рисков среди всех заинтересованных сторон.
Автоматизация
Используйте автоматизацию, чтобы ускорить общий процесс тестирования и поддерживать стабильное качество тестирования.
Применение инструментов автоматизации тестирования, поддерживающих гибкость, ускорит процесс RBT, предоставит экономически оптимизированные решения и повысит качество. Используйте интеллектуальные генеративные инструменты на базе искусственного интеллекта, такие как testRigor, для автоматизации тестирования.
Интеграция пользовательских историй с рисками
Приведите управление рисками в соответствие с бизнес-требованиями путем интеграции пользовательских историй и критериев принятия с рисками.
Использование рисков в качестве ориентира для вашего CI/CD
Постоянно тестируйте области приложения с высоким уровнем риска, используя риски в качестве дорожной карты для вашего конвейера CI/CD. Это помогает поддерживать качество программного обеспечения и покрытие высокоприоритетных рисков в каждом спринте.
Использование инструмента управления тестовыми примерами
Используя функциональные возможности инструмента управления тестированием, такого как TestRail, команды могут оптимизировать гибкое внедрение RBT. Это позволяет лучше выявлять риски, расставлять приоритеты и проводить комплексное тестирование критических направлений на протяжении всего жизненного цикла разработки.
Функции выполнения тестов TestRail позволяют командам отслеживать запуски тестов и управлять ими. Обеспечивают эффективное выполнение и мониторинг тестов с высоким уровнем риска.
Как измерить эффективность RBT в Agile с помощью показателей
Измерение результата RBT в гибкой среде предполагает использование конкретных показателей. Вот некоторые показатели, которые следует учитывать:
|
Метрика |
Формула |
|
Количество выявленных рисков |
Подсчет выявленных рисков с указанием серьезности и текущего статуса |
|
Количество тестовых случаев, запланированных и выполненных в спринте |
Запланированные тестовые примеры/выполненные тестовые примеры |
|
Количество пройденных и непройденных тестовых случаев в спринте |
Пройденные тестовые случаи / Неудачные тестовые случаи |
|
Отклонение тестовых усилий |
(Запланированные усилия по тестированию – Фактические усилия по тестированию) / Запланированные усилия по тестированию * 100 |
|
Расхождение в графике тестирования |
(Плановый график тестирования – Фактический график тестирования) / Плановый график тестирования * 100 |
|
Диаграмма сгорания задач в спринте для RBT |
Построение графика выполнения тестовой задачи в зависимости от времени во время спринта |
|
Процент выявления риска |
Количество выявленных рисков / Всего потенциальных рисков * 100 |
|
Процент снижения риска |
Количество умеренных рисков / Количество выявленных рисков * 100 |
|
Покрытие рисков |
Количество тестовых случаев, охватывающих риски / общее количество выявленных рисков * 100 |
|
Эффективность обнаружения дефектов |
Количество дефектов, обнаруженных в зонах повышенного риска / Общее количество обнаруженных дефектов * 100 |
|
Процент утечки дефектов |
Количество дефектов, обнаруженных в производстве/ОАТ/Всего найденных дефектов * 100 |
|
Отчет о тестовом покрытии |
Процент выполненных тестовых случаев от общего числа запланированных тестовых случаев. |
|
Отчет о тестировании на основе рисков |
Комплексный отчет с подробным описанием деятельности RBT, охвата и усилий по смягчению последствий. |
|
Стоимость качества (CoQ) |
Стоимость предотвращения + стоимость оценки + стоимость ошибок |
Помните, что выбор метрик должен соответствовать целям проекта, задачам тестирования и специфике разрабатываемого программного обеспечения. Регулярный пересмотр и уточнение этих показателей поможет постоянно совершенствовать процесс RBT в рамках гибкой структуры.
Заключение. Тестирование на основе рисков необходимо для быстрых гибких сред и сред DevOps с жесткими графиками. Динамичная среда требует высококачественной продукции и абсолютного удовлетворения потребностей клиентов. Примите культуру осознания рисков, в которой каждый член команды чувствует ответственность за выявление и снижение рисков. Это стимулирует активное управление рисками и позволяет создавать более надежный продукт.