Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Александр Молодцов
Старший специалист по тестированию в ГК Юзтех
Добрый день! Меня зовут Александр, я старший специалист по тестированию в ГК Юзтех. В этой статье я постараюсь кратко рассказать историю создания новых исследовательских сценариев и поделиться с вами опытом их применения.
Перед началом прочтения сразу обозначу две концепции, которые лежат в основе статьи:
Статья направлена на популяризацию такого подхода в тестировании как исследовательское тестирование с применением исследовательских сценариев.
Баг – это непреднамеренное преступление разработчика, которое он совершает во время своей работы, и нам, тестировщикам, необходимо локализовать этот баг, то есть раскрыть преступление :)
Исследовательское тестирование
В начале вспомним, что такое исследовательское тестирование. Исследовательское тестирование — это подход к тестированию, который основан на одновременном проектировании тест-кейсов, моментальном их выполнении без создания тестовой документации как таковой.
Метод использования тестовых сценариев весьма прост:
Мы выбираем исследовательский сценарий и изучаем его концепцию.
Затем ставим таймер на определённое время. На 20 минут, на час – это не так важно. Главное выделить сессию тестирования.
И в итоге проводим тестирование продукта строго по целям сценария, не отклоняясь от выбранной концепции.
В какой-то момент я задался вопросом: насколько популярно применение исследовательского тестирования в повседневной работе обычного тестировщика?
В ходе своего исследования я уточнял у действующих тестировщиков, для чего по их мнению исследовательское тестирование применяется в работе? Но перед этим задавал два простых, по моему мнению, вопроса:
Что такое исследовательское тестирование?
Часто применяете его в своей работе?
Тест-туры
Самый частый ответ на вопрос, знают ли они про исследовательские сценарии – да, знают тест-туры Джеймса Виттакера. Да, они слышали о них, да, они знают о них, но не применяют в своей работе.
Сам подход основан на том, что Джеймс предлагает примерить роль обычного туриста, а тестируемое программное обеспечение выступает в роли города, по которому турист перемещается со своим туристическим рюкзаком и пытается либо с помощью путеводителя, либо какого-то другого метода, пройтись по всем частям нашего города.
Почему этот подход показался мне неидеальным? Тест-туров на самом деле очень много, и в них очень легко потеряться. Причём не все тест-туры подходят для тестирования моего приложения. Сейчас я нахожусь на проекте, где подход тестирования денежных фич не применить: их там просто нет. Поэтому я подумал и решил создать набор тестовых сценариев, которые будут универсальны для тестирования любого продукта. На самом деле это очень интересно, и это поможет тестировщикам разобраться в применении исследовательского тестирования и показать, что оно является очень эффективным инструментом.
Методика Эдварда Боно
Далее было необходимо найти концепцию реализации задумки того, что необходимо применять в работе. Я решил ознакомиться с различными методами и подходами организации командной интеллектуальной работы. И один из них мне очень понравился – это метод Эдварда Боно «Шесть шляп мышления». В работе команды по созданию какой-то креативной идеи применяется примерка роли для того, чтобы скоординировать работу команды над проектом.
Например, в самом начале каждый член команды (или все сразу) примеряет шляпу одного цвета с выделенной ролью. Пусть это будет синяя шляпа, задачей которой является организация самого процесса интеллектуальной деятельности. Также есть чёрная шляпа, которая направлена на выделение негативных сторон реализации идей с целью предотвращения и минимизации рисков и потерь. Есть красная шляпа, которая оценивает текущую ситуацию с эмоциональной стороны восприятия.
В итоге для установки концепции своего подхода к формированию исследовательских сценариев из данного метода я решил взять принцип выделения роли от примерки той или иной шляпы. Сама цель метода – примерить роль на каждого члена команды в зависимости от цвета шляпы. Любой человек в команде разработки, например, я выступаю тестировщиком – это роль в команде. И чтобы в дальнейшем организовать свою работу при исследовании продукта предлагаю примерить на себя роль. Какую же роль можно примерить?
Детективные истории
Я решил зайти со стороны, наверное, самого распространённого хобби – это чтение. Идея вовлечения главных героев детективных историй – это идея моего брата. Он очень любит художественные произведения данного жанра. И на самом деле, если интерпретировать баг как преступление, то он иногда бывает довольно запутанным и сложным. И его необходимо как-то раскрывать, искать улики. В итоге приятно делиться опытом раскрытия бага с другими тестировщиками, рассказать, что ты нашёл и как локализовал баг. И да, иногда это гораздо интереснее и увлекательнее, чем раскрывать убийство из-за наследства троюродного дядюшки.
Если брать во внимание все эти моменты, то исследовательские сценарии, которые необходимо создать, методика Эдварда Боно с примеркой ролей с помощью шляп разных цветов и детективные истории, в итоге сформировали материал для этой статьи.
В процессе работы при примерке роли детектива мы применяем исследовательский сценарий, на основании которого проводится дальнейшая работа по тестированию нашего программного продукта.
Какие же роли мы с вами будем примерять?
Сценарий 1. Шерлок Холмс — шляпа Охотника на оленей
Это, наверное, самый известный детектив с Бе́йкер-стрит. Всеми известный мистер Шерлок Холмс. Англичанин по происхождению, он своим умом и обаянием мог раскрыть очень странные и на первый взгляд неразрешимые преступления. На каждого сыщика у нас есть краткое досье, и в конце также указан метод, который применял этот герой.
Для данного детектива у нас нет как такового исследовательского сценария, который основывается на его методе. И вот почему: мне кажется, что дедуктивный метод, который применяет Шерлок Холмс в ходе раскрытия преступления, является основой фактической работы любого тестировщика. Да-да, мы с вами расследуем своего рода небольшие преступления ежедневно. С тем или иным успехом, но мы пытаемся распутать порой очень запутанные ситуации.
Когда мы находим какой-то баг, мы пытаемся его локализовать. И процесс локализации идёт от общего к частному. То есть мы находим какую-то проблему и пытаемся найти первопричину её возникновения. В дальнейшем мы выясняем причину появления этой проблемы и заводим задачу в нашу баг-трекинговую систему.
Для чего был представлен данный подход в тестировании? Цель других детективов – поиск багов без траты времени на их локализацию. Чтобы не отступать от концепции тестирования по исследовательскому туру, мы просто фиксируем наличие проблем и дальше передаём их Шерлоку Холмсу. Его метод довольно эффективный: никогда его не подводил, и, надеюсь, что он не подведёт и нас.
Самый распространённый сценарий работы любого тестировщика – локализация бага с помощью дедуктивного метода, от общего к частному.
Что используем? | Как используем? | Когда применяем? |
|
| В случаях возможности построения логической цепочки следствий |
После успешного прохождения других исследовательских туров |
Сценарий 2. Мисс Марпл — простая соломенная женская шляпка
Большую часть свое жизни Мисс Марпл провела в небольшой деревне. Она не считает себя профессиональным детективом. Чаще всего в рассказах она не является главным героем, ведущим расследование, но все следователи прислушиваются к её мнению по вопросам, кто же является убийцей или преступником.
У неё довольно-таки интересный метод: она проводит параллели. Когда происходит какое-то убийство, она вспоминает жителей своей деревни, в своём детстве, юношестве, отрочестве, как происходило какое-то событие и проводит параллель. И в итоге она оказывалась всегда права – чередой умозаключений она находила преступника, либо раскрывала какую-то загадку.
Что же я предлагаю вам сделать? Давайте выберем функционал в нашей системе и попробуем интерпретировать свой опыт при его тестировании. Причём не только опыт тестирования именно такой же системы, и не только опыт тестирования, но и использования.
Тестирование одних элементов программы такими методами, которые применяли по отношению к другому программному продукту.
Что исследуем? | Как используем? | Когда применяем? |
| Интерпретируем текущий функционал как тот, что уже тестировали ранее |
|
Применяем тест-кейс, которые приводили к нахождению багов |
Все мы знаем, я надеюсь, как тестировать интернет-магазин. Также есть некая система хранения документов. Если переложить элементы тестирования интернет-магазина на тестирование системы документооборота, то можно найти интересные механики: каталог хранения документов – это та же полка хранения товара, а сам документ выступает в роли товара на этой полке. Также документ в системе хранения имеет параметры, сопоставимые с характеристиками товаров.
И ещё один пример — тестирование регистрации пользователя в приложении велопроката с использованием пиктограммы. Обычно данный подход тестирования используется в тестировании создания пользователя какой-либо игры. Первое, что делает игрок в играх с социальным взаимодействием в интернете — создаёт логин своей учётной записи. И здесь данный подход был применим. Нормальный человек, конечно, не будет регистрироваться со смайлом в качестве фамилии, так как в дальнейшем ему будет предлагаться услуга на основании публичной оферты, а также он даёт согласие на обработку персональных данных и принимает пользовательское соглашение. К чему же привёл данный баг? В системе администрирования нельзя было сформировать отчёты с пользователем, указавшим в одном из полей пиктограмму.
Проведение параллелей между вашим текущим проектом и вашим опытом помогут вам не потеряться в документации и найти много багов.
“А дальше что?” — спросите вы, и я вам отвечу: “А продолжение будет уже в следующей части…”. Так что следите за обновлениями в блоге нашей компании — ещё будет много чего интересного.
А пока можете оставить обратную связь в комментариях: отвечу на ваши вопросы.
