В январе я узнал две новости, которые зарядили май двумя события из разряда "must visit". Первая - в Минск снова едет конференция SQA Days! В 2012 году в Минске я впервые побывал на SQA Days-12 и выступил с докладом. Вторая - на конференцию приедут с докладами Рекс Блэк и Пол Джеррард! Но встал вопрос выбора, чей мастер-класс выбрать. И, как в 2008-м, когда я купил черную книгу "Ключевые процессы тестирования" (единственная книга Блэка, переведенная на русский язык), так и спустя 7 лет, я выбрал мастер-класс Risk Based Testing.
Тренинг оказался полезным и познавательным. Новички ознакомились с техникой тестирования, основанной на рисках. Продвинутые систематизировали знания по технике, зададут практические вопросы из опыта на своем проекте. Опытные и преподаватели увидели вживую, как преподает Рекс Блэк и почерпнули полезные "фишки" для себя.
Конспект не претендует на полный сборник идей и мыслей, прозвучавших на тренинге. Для знакомства с техникой Risk Based Testing (RBT), дополнительно рекомендую источники:
Риск - вероятность негативного результата (>0% и <100%)
Один человек не может знать все риски, но вместе с командой вы можете выделить большинство рисков. Вывод: не пытайтесь собрать все риски в одиночку.
Как организовать сбор рисков? Рекс Блэк предлагает серию митингов-брейнстормов "1-на-1" с заинтересованными лицами ("технарями" и "бизнесом") продолжительностью 90-120 минут каждый.
Вторая часть тренинга - идентификация рисков. Используйте фреймворки для обнаружения и классификации рисков (по аналогии с фазой тест-дизайна - чит-листы), содержащие список возможных рисков: чек-листы рисков, риски из старого стандарта качества ISO 9126 и нового стандарта ISO 25000 и другие. Пример категорий списка рисков Рекса Блэка - здесь.
Для каждой категории рисков назначается ответственный исполнитель и список тестов, которые отвечают за риск. "Граничный" риск, который попадает в две категории, делится на 2-3 риска так, чтобы каждый выделенный риск попал в отдельную категорию.
Quality risk -> test
Project risk -> manage, not test
В третьей части тренинга мы говорили о сборе и оценке рисков.
Анализ quality risks приводит к трем побочным продуктам, которые нужно собрать: проектные риски (ответственный - менеджер проекта), дефекты во входной документации (ответственный - бизнес-аналитик) и предположения, сущности (issues) и вопросы (ответственный - разработчик).
Каждый риск оценивается по двум параметрам: вероятность (Likelihood) и влияние (Impact). Есть много шкал для оценки параметров, самая распространенная - пятибальная: от 1 (наиболее вероятно) до 5 (очень маловероятно). Важно, чтобы все участники проекта:
Для оценки риска (RPN - risk priority number, номер приоритета риска) вероятность и влияние перемножаются и полученные произведения ранжируются. Риски с наименьшим произведением - самые важные. Для оценки необходимого количества тест-кейсов для каждого риска используется практический метод: от 20 для рисков с RPN = 1-2 до 0 для рисков с RPN = 16-25 (один из примеров, количество тест-кейсов зависит от проекта).
В четвертой части тренинга мы разбирали практический пример оценки рисков на реальном проекте: от анализа quality risks до "выравнивания рисков" (если риски "сваливаются" на начало или конец прямой RPN от 1 до 25).
Пятая часть тренинга рассказывает о возможных оптимизациях стратегии Risk Based Testing: формулы для эстимаций тестирования, таблица приоритетов рисков, failure mode and effect analysis (FMEA).
В шестой части тренинга Рекс Блэк говорил о применении RBT для последовательных и итеративных циклов разработки и для процесса тестирования (рассматривался generic test process, описание которого дается в ISTQB - Planning, Analysis, Design, Implementation, Execution, Evaluating exit criteria and Reporting, Closure).
RBT is ideal for sequential lifecycle.
In iterative lifecycle, you need to prioritize Bug Fix VS feature development.
Для каждой фазы процесса тестирования Рекс Блэк приводил графики и примеры оценки рисков. Например, на фазе дизайна - процент покрытия рисками с течением времени (похожа на диаграмму покрытия тест-кейсами продукта), на фазе выполнения тестов - круговые диаграммы с процентами рисков от наиболее до наименее вероятных, и для каждого процента рисков - круговая диаграмма со статусом тест-кейсов (Passed, Failed, Not Run).
И на десерт - еще одна практическая часть, работа с требованиями "почти реального" проекта. И автографы для желающих и фотография с Рексом Блэком на память.
Тренинг прошел быстро и продуктивно: прошло 8 часов, и за окном светило уже вечернее солнце. А мы, вооружившись методом Risk Based, готовились применить полученные знания на практике и встретиться с Рексом Блэком завтра, уже на первом дне SQA Days. Но это уже другая, не менее интересная история. Продолжение следует. Лета, и оставайтесь с Qastugama!
Тренинг оказался полезным и познавательным. Новички ознакомились с техникой тестирования, основанной на рисках. Продвинутые систематизировали знания по технике, зададут практические вопросы из опыта на своем проекте. Опытные и преподаватели увидели вживую, как преподает Рекс Блэк и почерпнули полезные "фишки" для себя.
Конспект не претендует на полный сборник идей и мыслей, прозвучавших на тренинге. Для знакомства с техникой Risk Based Testing (RBT), дополнительно рекомендую источники:
- вебинары Рекса Блэка "The Most Dangerous Fallacies of Risk-based Testing" и "Agile Risk based Testing A How to Guide"
- серия вебинаров Рекса Блэка "Risk Based Testing Videos (a year-long series)" в цифровой библиотеке на сайте - http://www.rbcs-us.com/software-testing-resources/library/digital-library
- статьи Quality Risk Analysis и A Case Study in Risk Based Testing
- выдержка из книги Рекса Блека о risk-based подходе - Advanced Software Testing Vol.2
- доклад Алены Дашкевич на SQA Days-12 "Risk-based testing management. От теории к современной практике"
- Определение Risk Based Testing (далее - RBT)
- Идентификация рисков, связанных с качеством
- Сбор и оценка рисков
- Кейс-стади по RBT
- Как формализировать или наоборот, увеличить точность RBT
- Интеграция RBT в жизненный цикл разработки и тестирования
Риск - вероятность негативного результата (>0% и <100%)
Один человек не может знать все риски, но вместе с командой вы можете выделить большинство рисков. Вывод: не пытайтесь собрать все риски в одиночку.
Как организовать сбор рисков? Рекс Блэк предлагает серию митингов-брейнстормов "1-на-1" с заинтересованными лицами ("технарями" и "бизнесом") продолжительностью 90-120 минут каждый.
Вторая часть тренинга - идентификация рисков. Используйте фреймворки для обнаружения и классификации рисков (по аналогии с фазой тест-дизайна - чит-листы), содержащие список возможных рисков: чек-листы рисков, риски из старого стандарта качества ISO 9126 и нового стандарта ISO 25000 и другие. Пример категорий списка рисков Рекса Блэка - здесь.
Для каждой категории рисков назначается ответственный исполнитель и список тестов, которые отвечают за риск. "Граничный" риск, который попадает в две категории, делится на 2-3 риска так, чтобы каждый выделенный риск попал в отдельную категорию.
Quality risk -> test
Project risk -> manage, not test
В третьей части тренинга мы говорили о сборе и оценке рисков.
Анализ quality risks приводит к трем побочным продуктам, которые нужно собрать: проектные риски (ответственный - менеджер проекта), дефекты во входной документации (ответственный - бизнес-аналитик) и предположения, сущности (issues) и вопросы (ответственный - разработчик).
Каждый риск оценивается по двум параметрам: вероятность (Likelihood) и влияние (Impact). Есть много шкал для оценки параметров, самая распространенная - пятибальная: от 1 (наиболее вероятно) до 5 (очень маловероятно). Важно, чтобы все участники проекта:
- знали и понимали критерии каждого балла в принятой шкале
- при оценке риска предполагали типовой, а не наихудший сценарий (пример с порезанным пальцем)
Для оценки риска (RPN - risk priority number, номер приоритета риска) вероятность и влияние перемножаются и полученные произведения ранжируются. Риски с наименьшим произведением - самые важные. Для оценки необходимого количества тест-кейсов для каждого риска используется практический метод: от 20 для рисков с RPN = 1-2 до 0 для рисков с RPN = 16-25 (один из примеров, количество тест-кейсов зависит от проекта).
В четвертой части тренинга мы разбирали практический пример оценки рисков на реальном проекте: от анализа quality risks до "выравнивания рисков" (если риски "сваливаются" на начало или конец прямой RPN от 1 до 25).
Пятая часть тренинга рассказывает о возможных оптимизациях стратегии Risk Based Testing: формулы для эстимаций тестирования, таблица приоритетов рисков, failure mode and effect analysis (FMEA).
В шестой части тренинга Рекс Блэк говорил о применении RBT для последовательных и итеративных циклов разработки и для процесса тестирования (рассматривался generic test process, описание которого дается в ISTQB - Planning, Analysis, Design, Implementation, Execution, Evaluating exit criteria and Reporting, Closure).
RBT is ideal for sequential lifecycle.
In iterative lifecycle, you need to prioritize Bug Fix VS feature development.
Для каждой фазы процесса тестирования Рекс Блэк приводил графики и примеры оценки рисков. Например, на фазе дизайна - процент покрытия рисками с течением времени (похожа на диаграмму покрытия тест-кейсами продукта), на фазе выполнения тестов - круговые диаграммы с процентами рисков от наиболее до наименее вероятных, и для каждого процента рисков - круговая диаграмма со статусом тест-кейсов (Passed, Failed, Not Run).
И на десерт - еще одна практическая часть, работа с требованиями "почти реального" проекта. И автографы для желающих и фотография с Рексом Блэком на память.
Тренинг прошел быстро и продуктивно: прошло 8 часов, и за окном светило уже вечернее солнце. А мы, вооружившись методом Risk Based, готовились применить полученные знания на практике и встретиться с Рексом Блэком завтра, уже на первом дне SQA Days. Но это уже другая, не менее интересная история. Продолжение следует. Лета, и оставайтесь с Qastugama!
