В то время как программисты по всему миру соревнуются в Coding Dojo, аналогичное мероприятие для тестировщиков под названием Testing Dojo еще не завоевало такую широкую популярность. С недавнего времени Testing Dojo стали практиковать в странах СНГ, и тестировщики компании Startup Labs, конечно, не могли остаться в стороне от новых веяний.
Хотя определять Testing Dojo как «соревнование» не совсем верно. Безусловно, соревновательный элемент присутствует, но он скорее придает мероприятию некоторое сходство с игрой и дополнительно мотивирует участников, однако победа не является основной целью участников.
Так что же все-таки такое Testing Dojo? Имеет ли смысл использовать эту практику в работе вашего отдела тестирования?
Что такое Testing Dojo?
Начнем с теоретической части. Testing Dojo – это мероприятие, в ходе которого тестировщики, разбитые на несколько команд, за определенное время должны протестировать предложенное им приложение, используя определенный (чаще всего, новый для них) метод тестирования. Однако не все так просто, как кажется на первый взгляд.
Выделяют несколько целей проведения Testing Dojo:
- Протестировать приложение/продукт
- Оценить использованные инструменты
- Изучить новые подходы к тестированию
- Улучшить взаимодействие между тестировщиками.
В Dojo могут принимать участие столько человек, сколько позволяет имеющееся помещение. Всех участников делят на команды, состоящие из 3-4 человек. Процессом руководит ведущий, в обязанности которого входит определение временных промежутков сессий и координация обратной связи – отчетов и комментариев каждой из команд. Все команды получают по одному ноутбуку и блокноты для записи.
В каждой из команд выделяют следующие роли: тестировщик, наблюдатель и регистратор. Тестировщик (tester), собственно, отвечает за процесс тестирования. Он находится за клавиатурой и сообщает обо всех своих действиях регистратору. Регистратор (recorder), в свою очередь, фиксирует все действия тестировщика для того, чтобы их можно было воспроизвести в дальнейшем. Роль наблюдателя (observer) сводится к молчаливому наблюдению за взаимодействием между тестировщиком и регистратором и поиском вариантов для его оптимизации. Наблюдатель не должен участвовать в самом процессе тестирования и не должен предлагать никаких идей.
Применяем Exploratory Testing
Сразу стоит пояснить, что в Testing Dojo могут применяться любые методы тестирования, которые вы хотите изучить или потренировать. Наша команда QA решила остановиться на Exploratory Testing или исследовательском тестировании, которое предполагает изучение ПО, разработку тестов и их выполнение в одно и то же время, а также использование результатов проведенных тестов для разработки новых. Кстати, одной из целей проведения Testing Dojo является изучение какого-либо подхода к тестированию и дальнейшее применение его на практике.
Раз уж было решено использовать Exploratory Testing, стоит в нескольких словах объяснить, в чем заключается этот метод:
- Exploratory Testing – это НЕ Ad-hoc testing (т.е. в отличие от интуитивного тестирования, в Exploratory Testing всегда присутствует четкий план и цель)
- В Exploratory Testing могут использоваться спецификации и другие виды документации
- Exploratory Testing – это не только ручное тестирование
- Exploratory Testing – это НЕ универсальный подход к тестированию.
В процессе тестирования допускается использование чек-листов и чит-листов, а также функциональной карты и интеллект-карты.
Как проходит Testing Dojo
Тут логично будет обратиться к примеру нашей QA команды и рассказать, как мы провели Testing Dojo. Наши тестировщики (а также 2 менеджера проектов) в количестве 12 человек собрались в конфруме. Двое ведущих поделили всех на 4 команды из трех человек.
Участникам Testing Dojo было предложено протестировать RSS-агрегатор (выбор пал именно на него ввиду приближающегося закрытия Google Reader). Все мероприятие проходило в 3 этапа, или 3 сессии, по 45, 30 и 30 минут.
Во время первой сессии команды должны были ознакомиться с приложением, определить цель тестирования и наметить план действий. Вторая сессия была посвящена собственно тестированию, поиску багов и фиксированию их на бумаге. Во время третьей сессии команды подводили итоги, систематизировали найденные баги по приоритетности и готовились к финальному отчету.
После каждой сессии, представители команд должны были представить отчет по следующей схеме:
- Past. Что произошло во время сессии?
- Results. Чего удалось добиться во время сессии?
- Obstacles. Что мешало эффективному тестированию?
- Outlook. Что еще предстоит сделать?
- Feelings. Какие впечатления остались от сессии?
Во время обсуждений, следовавших за каждой из сессий, участники могли пообщаться с наблюдателем и с членами остальных команд. Такое обсуждение позволяло поделиться опытом, прояснить спорные вопросы и даже скорректировать план действий команды на следующую сессию. Кстати, после каждой сессии участники менялись ролями, т.е. тестировщик становился регистратором, регистратор наблюдателем и т.д. Таким образом, по истечении трех сессий каждый член команды попробовал себя во всех трех ролях.
За найденные баги командам начислялись очки:
- 8 очков за функциональный (критичный) баг
- 5 очков за функциональный (некритичный) баг
- 2 очка за UI баг
- 5 очков за «Пасхальное яйцо».
После трех сессий особо интересные баги были вынесены на общее обсуждение, которое, кстати, оказалось очень бурным. К слову, у нас не было ни победителей, ни проигравших, и на очки мы закрыли глаза, ведь целью было обучиться чему-то, а не померяться навыками.
Итоги и комментарии
Пришло время подвести итоги. Общие впечатления от Testing Dojo можно разделить на положительные и отрицательные, или на плюсы и минусы.
Плюсы
Здесь стоит ориентироваться на те комментарии, которые организаторы получили от участников после окончания мероприятия. Мы не будем подробно описывать найденные баги, хотя, конечно, без жаркой дискуссии по поводу того, «баг это или фича», не обошлось.
Наши тестировщики единогласно отметили, что мероприятие получилось веселым, интересным и познавательным. Среди положительных моментов были названы возможность поучиться друг у друга и сплочение коллектива благодаря командной работе. В общем, практически все выразили желание принимать участие в подобных мероприятиях в будущем, в связи с чем было принято решение проводить Testing Dojo раз в месяц.
Минусы
Сразу оговоримся, что это был наш первый опыт проведения подобного мероприятия, поэтому удалось не все. Но мы постарались собрать feedback, и учесть все негативные отзывы. Больше всего нареканий вызвало приложение, предложенное для тестирования. Некоторые участники не пользовались RSS-агрегаторами до этого и не очень хорошо понимали, для чего нужно такое приложение и как оно должно работать. Прозвучало предложение повторить такое мероприятие, но использовать для тестирования один из наших продуктов.
Опять же, никто из тестировщиков раньше не принимал участие в Dojo, поэтому некоторая путаница возникла в связи с организационными моментами. К примеру, не всегда удавалось четко соблюдать разделение по ролям. Больше всего сложностей вызвала роль наблюдателя. Вот один из отзывов: «Я думаю, что была некоторая сложность работы в команде, так как цель роли наблюдателя не была четко определена. Что он должен наблюдать и для чего? Процесс тестирования приложения или эмоции, поведение, отношение (психологический микроклимат) и т. д. Если же наблюдатель исполняет роль «менеджера», то он должен в какой-то момент (произвольный или четко очерченный - каждые Х минут) рекомендательно (или жестко) вклиниваться в процесс тестирования (направлять процесс). Если же наблюдатель должен именно «перенять опыт» (модель поведения, мышления другого человека), тогда он должен молчать как рыба. И только отмечать для себя: «О! Это круто! И я такой подход буду применять...», и потом в конце игры рассказать про эти «крутые фишки».
Понятно, что эти проблемы решаются очень легко: достаточно подобрать подходящее приложение или продукт для тестирования и потратить больше времени на то, чтобы подробно объяснить обязанности каждого участника команды.
Вывод
Несмотря на некоторые шероховатости, Testing Dojo прошло в нашей QA команде успешно. Одним этим мероприятием удалось «убить несколько зайцев»: потренироваться, обменяться опытом, пообщаться, усилить командный дух и т.д. Это отличное упражнение, которое можно и нужно проводить в отделах тестирования. Конечно, надо учитывать специфику работы той или иной компании, а также межличностные отношения, но в целом, можем порекомендовать Testing Dojo всем.
Подробнее о Testing Dojo можно прочитать здесь http://www.testingdojo.org/.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.