Тренинг Рекса Блэка "Risk Based Testing"

В январе я узнал две новости, которые зарядили май двумя события из разряда "must visit". Первая - в Минск снова едет конференция SQA Days! В 2012 году в Минске я впервые побывал на SQA Days-12 и выступил с докладом. Вторая - на конференцию приедут с докладами Рекс Блэк и Пол Джеррард! Но встал вопрос выбора, чей мастер-класс выбрать. И, как в 2008-м, когда я купил черную книгу "Ключевые процессы тестирования" (единственная книга Блэка, переведенная на русский язык), так и спустя 7 лет, я выбрал мастер-класс Risk Based Testing.

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

Конспект не претендует на полный сборник идей и мыслей, прозвучавших на тренинге. Для знакомства с техникой 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. От теории к современной практике"

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

1. Определение Risk Based Testing (далее - RBT)
2. Идентификация рисков, связанных с качеством
3. Сбор и оценка рисков
4. Кейс-стади по RBT
5. Как формализировать или наоборот, увеличить точность RBT
6. Интеграция RBT в жизненный цикл разработки и тестирования

В первой части Рекс Блэк говорил о невозможности полного тестирования (как и Сэм Канер в курсе BBST: Foundations), определениях риска, quality and project risks, 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 (очень маловероятно). Важно, чтобы все участники проекта:

• знали и понимали критерии каждого балла в принятой шкале
• при оценке риска предполагали типовой, а не наихудший сценарий (пример с порезанным пальцем)

 More "risky" features in agile must be delivered first (as early as possible).

Для оценки риска (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!

О джедайском тренинге Макса Дорофеева, пустом инбоксе, списке задач и высоких целях

Прошел ровно месяц после семинара Макса Дорофеева "Джедайская техника пустого инбокса" в Минске, но только сейчас я пишу обещанный отзыв. Лучше поздно, чем никогда :)

Для меня Максим Дорофеев один из лучших докладчиков и тренеров. Почему?

• Мне близки темы личной эффективности, оценки проектов, которыми он занимается
• Доклады Макса содержат свои фишки: авторские рисованные слайды, яркие образы (например, "человек-снежинка"), чувство юмора и прямые формулировки
• Как Макс работает с аудиторией. Вопросы-ответы в зал, практические задания, работа в группах

Доклады Макса со многих конференций есть в свободном доступе - http://cartmendum.livejournal.com/164238.html. Для тестировщиков рекомендую серию докладов  "Обезьянки против роботов" про плюсы и минусы автоматизации.

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

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

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

• "Делать дела не сложно. Сложнее решить, что делать"
• 2 ситуации, когда люди хотят личной эффективности: кончилось время и кончился мозг. В первой помогает тайм-менеджмент, во второй ТМ не поможет, необходимо экономить патронорешения (медленное мышление)
• "Что не записано, то продолбано"
• Идеи записывать необходимо, чтобы освободить "помнилку" и чтобы не тратить время на идею каждый раз, когда она "путешествует из неосознанного в осознанное ("Мышление может запуститься само")
• Полный инбокс - это не список задач. Это может быть список проблем, проектов, заявок на прокрастинацию, узелков на память
• Первый парадокс личной эффективности: Для того, чтобы выправить баланс между работой и личной жизнью, надо не разделять их, а наоборот смешать на сколько это возможно. Все задачи по работе и для себя должны вестись в едином списке задач.
•  Если не знаешь, какой сделать первый шаг - реши, что бы ты сделал за 15 минут. Если не знаешь, что делать, - выдели 15 минут на обдумывание только этой задачи, не отвлекаясь на постороннее.
• 4 шага шаблона естественного планирования: мотиватор (для меня это важно, потому что) + видение результата (визуализация) + организация (например, карта памяти) + самый первый шаг
• Борьба с прокрастинацией, 2 вопроса: каков самый первый шаг и какой минимально приемлемый результат
• Соотнесение своих жизненных целей и задач из списка. Очень полезно смотреть в список задач и отмечать, запланированы ли задачи, которые данную цель продвигают. И в обратную сторону: какую цель помогает достичь данная задача? 

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

• Единый список задач - done
• Еженедельная задача на обзор списка задач (он же "гвоздодер") - done. Я пользуюсь "спусковыми крючками" Татьяны Беловой.
• Сортировка писем во входящих - done в рабочих, todo - в личных 
• Календарь - done
• Система для хранения информации - todo (на тренинге не было)
• Интернет-шабат на сутки - попробовать

Только практика и действия помогут вам стать джедаем. И да прибудет с вами сила! Ставьте высокие цели и их достигайте :)

Тренинг Майкла Болтона "Критическое мышление для тестировщиков". Мой обзор.

На конференции SQA Days-15 в Москве было много классных докладчиков, но приглашение на юбилейную конференцию Майкла Болтона - это вишенка на вкусном торте. Полуторачасовой доклад собрал полную аудиторию: в конце второго дня Майкл дразнил пивом, троллил продукты Майкрософт, но главное - разбирался вместе со слушателями, в чем проблема?

А на следующий день, 20 апреля, Майкл Болтон проводил восьмичасовой тренинг "Критическое мышление для тестировщиков". Анонсы про тренинг были еще за 2 месяца до конференции, участникам SQA Days была скидка 10% на тренинг, но народу собралось непривычно мало: всего 15 человек (в том числе я с коллегами Игорем Бондаренко и Сергеем Остапенковым) приняло участие. Довольно неожиданно, ведь нечасто к нам приезжает звезда по тестированию такого уровня...

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

Мой нижеприведенный конспект не отразит все то множество мыслей и идей, затронутых на тренинге, но поможет вам (и мне) восстановить хронологию событий, как это было, и узнать что-то новое. За более подробной информацией обращайтесь к первоисточнику на последующих тренингах, или почитайте статьи Болтона на его сайте - http://developsense.com/

Слайды Майкла Болтона с конференции Eurostar по данной теме "Critical Thinking for testers" можно взять здесь - http://www.developsense.com/presentations/2012-11-EuroSTAR-CriticalThinkingForTesters.pdf

Начался тренинг с двух простых задачек: про биту и мяч и про Стива-библиотекаря-фермера. Затем мы поупражнялись в переводе с 10-ричной системы в 16-ричную, и заодно проверили наши предположения о том, сколько человек в аудитории знают этот алгоритм и сделали задачу правильно :)

Рефлекс важен, но критичное мышление - это рефлексия.

Что ты видишь - это все, что есть (c) Майкл Болтон ("What you see is all there is")

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

Тестировщик - тот, кто знает, что вещи могут быть разными.

Затем мы решали задачу: есть последовательность, есть программа, которая по введенной последовательности отвечает, удовлетворяет ли введенная последовательность некоторой закономерности или нет. Задача была - обнаружить данную закономерность за наименьшее число тестов. Вначале каждый работал сам, затем мы объединились все вместе (о минимальном количестве тестов речи уже не шло:) ), но даже все вместе мы не смогли полностью, на все 100% описать данную закономерность. И даже после знакомства с исходным кодом программы (буквально 4 строки исходного кода) мы выяснили, что не все нюансы программы были обнаружены.

Алгоритм поиска закономерности - creep and leap.

No experience about the past can logically be projected into the future, because we have no experience OF the future.

Passing tests cannot prove software is good. 

Critical thinking is thinking about thinking with the aim of not getting fooled (c) Michael Bolton.

Затем Майкл говорил о тестировании и проверках (testing-vs-checking) - я публиковал в блоге перевод исходной статьи - http://qastugama.blogspot.com/2013/09/blog-post_6.html И немного о том, что все думают, что делают тестировщики (сравнивают продукт со спецификацией, круги described-actual), и что тестировщики делают на самом деле (круги imagined-described-actual) - вначале мы сами обсуждали данные круги, затем обсуждали свои результаты с Майклом. И на десерт данного блока - задача "сломанный калькулятор": я уронил калькулятор, возможно, он поврежден, как я должен проверить его работоспособность.

Следующая часть - блок про предпосылки, утверждения и выводы. И о том, что делает утверждения более опасными (безосновательными и ведущими к ложным выводам). О помогающих вопросах, чтобы не попасться в ловушки (Huh? Really? So?) - эти вопросы также позволяют восстановить контекст.

It is silly to say “don’t make assumptions.” Instead say “let’s be careful about risky assumptions.”

Book "Perfect Software and Other Illusions About Testing" by J. Weinberg

Следом  - практическая задача-диаграмма с одним ветвлением: A < 70? Если да, то выполняем 1, если нет, то выполняем 2. И вопрос, сколько кейсов. Очевидный ответ 2 неправильный: каждый блок диаграммы может содержать несколько действий, каждое из которых тоже необходимо проверять:

Things that don't appear on diagram are easy to forget.

The feature worked. -> I've not yet seen any failures in the feature.

Далее мы говорили о "безопасном языке" (в тестировании это оценка и использование безопасных формулировок с целью избежания ложной уверенности) и вербальных эвристиках (Unless, And also, Or Not, So far & Not Yet), разбирали статьи с безопасным языком.

The Regression Testing Fantasy “I rerun my old tests to ensure that nothing has broken.”

Books:
Gerome Groopman "How Doctors Think"

Gerd Gigerenzer "Gut Feelings: The Intelligence of the Unconscious"

И на десерт - логические задачи, головоломки, фокусы от Майкла, некоторые нам даже удалось раскусить :) И автографы для желающих и возможность сфотографироваться с самим Майклом Болтоном.

Восемь часов пролетело очень быстро, не хотелось расходиться, да и была еще возможность попить пива с Болтоном второй раз за два дня, но впереди ждали поезд и Минск :) Московские три дня пролетели очень быстро, продуктивно, насыщенно, много знакомств, общения со старыми знакомыми, новые идеи, мысли, пивное афтепати в Гамбринусе, критическое мышление Майкла Болтона... Вобщем, нужно встречаться, хотя бы раз в полгода. До встречи на следующей SQA Days!