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

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

.
Исследовательские сценарии как метод раскрытия преступления (Часть первая)
21.12.2022 00:00

Автор: Александр Молодцов, Старший специалист по тестированию в ГК Юзтех

Добрый день! Меня зовут Александр, я старший специалист по тестированию в ГК Юзтех. В этой статье я постараюсь кратко рассказать историю создания новых исследовательских сценариев и поделиться с вами опытом их применения.

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

  1. Статья направлена на популяризацию такого  подхода в тестировании как исследовательское тестирование с применением исследовательских сценариев.

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

Исследовательское тестирование

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

Метод использования тестовых сценариев весьма прост:

  • Мы выбираем исследовательский сценарий и изучаем его концепцию.

  • Затем ставим таймер на определённое время. На 20 минут, на час – это не так важно. Главное выделить сессию тестирования.

  • И в итоге проводим тестирование продукта строго по целям сценария, не отклоняясь от выбранной концепции.

В какой-то момент я задался вопросом: насколько популярно применение исследовательского тестирования в повседневной работе обычного тестировщика?

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

  1. Что такое исследовательское тестирование? 

  2. Часто применяете его в своей работе?

Тест-туры

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

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

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





Методика Эдварда Боно

Далее было необходимо найти концепцию реализации задумки того, что необходимо применять в работе. Я решил ознакомиться с различными методами и подходами организации командной интеллектуальной работы. И один из них мне очень понравился – это метод Эдварда Боно «Шесть шляп мышления». В работе команды по созданию какой-то креативной идеи применяется примерка роли для того, чтобы скоординировать работу команды над проектом.

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

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

Детективные истории

Я решил зайти со стороны, наверное, самого распространённого хобби – это чтение. Идея вовлечения главных героев детективных историй – это идея моего брата. Он очень любит художественные произведения данного жанра. И на самом деле, если интерпретировать баг как преступление, то он иногда бывает довольно запутанным и сложным. И его необходимо как-то раскрывать, искать улики. В итоге приятно делиться опытом раскрытия бага с другими тестировщиками, рассказать, что ты нашёл и как локализовал баг. И да, иногда это гораздо интереснее и увлекательнее, чем раскрывать убийство из-за наследства троюродного дядюшки.

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

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

Какие же роли мы с вами будем примерять?

Сценарий 1. Шерлок Холмс — шляпа Охотника на оленей





Это, наверное, самый известный детектив с Бе́йкер-стрит. Всеми известный мистер Шерлок Холмс. Англичанин по происхождению, он своим умом и обаянием мог раскрыть очень странные и на первый взгляд неразрешимые преступления. На каждого сыщика у нас есть краткое досье, и в конце также указан метод, который применял этот герой.

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

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

Для чего был представлен данный подход в тестировании? Цель других детективов – поиск багов без траты времени на их локализацию. Чтобы не отступать от концепции тестирования по исследовательскому туру, мы просто фиксируем наличие проблем и дальше передаём их Шерлоку Холмсу. Его метод довольно эффективный: никогда его не подводил, и, надеюсь, что он не подведёт и нас.

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

Что используем?

Как используем?

Когда применяем?



Дедукцию как метод локализации бага


Выстраиваем логические конструкции для выявления причин появления бага

В случаях возможности построения логической цепочки следствий

После успешного прохождения других исследовательских туров

Сценарий 2. Мисс Марпл — простая соломенная женская шляпка





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

У неё довольно-таки интересный метод: она проводит параллели. Когда происходит какое-то убийство, она вспоминает жителей своей деревни, в своём детстве, юношестве, отрочестве, как происходило какое-то событие и проводит параллель. И в итоге она оказывалась всегда права – чередой умозаключений она находила преступника, либо раскрывала какую-то загадку.

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

Тестирование одних элементов программы такими методами, которые применяли по отношению к другому программному продукту.

Что исследуем?

Как используем?

Когда применяем?


Полностью всю систему или отдельный функциональный модуль приложения

Интерпретируем текущий функционал как тот, что уже тестировали ранее


Если логика работы приложения нам знакома, мы её встречали уже в другой реализации

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

Все мы знаем, я надеюсь, как тестировать интернет-магазин. Также есть некая система хранения документов. Если переложить элементы тестирования интернет-магазина на тестирование системы документооборота, то можно найти интересные механики: каталог хранения документов – это та же полка хранения товара, а сам документ выступает в роли товара на этой полке. Также документ в системе хранения имеет параметры, сопоставимые с характеристиками товаров.

И ещё один пример — тестирование регистрации пользователя в приложении велопроката с использованием пиктограммы. Обычно данный подход тестирования используется в тестировании создания пользователя какой-либо игры. Первое, что делает игрок в играх с социальным взаимодействием в интернете — создаёт логин своей учётной записи. И здесь данный подход был применим. Нормальный человек, конечно, не будет регистрироваться со смайлом в качестве фамилии, так как в дальнейшем ему будет предлагаться услуга на основании публичной оферты, а также он даёт согласие на обработку персональных данных и принимает пользовательское соглашение. К чему же привёл данный баг? В системе администрирования нельзя было сформировать отчёты с пользователем, указавшим в одном из полей пиктограмму.

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

“А дальше что?” — спросите вы, и я вам отвечу: “А продолжение будет уже в следующей части…”. 

Обсудить в форуме