Введение в исследовательское тестирование |
18.09.2018 13:22 |
Автор: Марсель Гелен (Marcel Gehlen) Перевод: Ольга Алифанова Коллега как-то попросил меня ввести его в суть исследовательского тестирования. Я сделал список полезных статей в блогах, которые, на мой взгляд, пригодятся новичку. Он среагировал в ключе "да это же целый вводный курс". Я так не думал, но тот список был недалек от совершенства. С тех пор я добавил в него еще ссылок и подумал над упражнениями, чтобы сделать это настоящим вводным курсом. Теперь я могу сразу отправлять этот список интересующимся. Это настоящая кроличья нора – статьи ведут на другие статьи, а те, в свою очередь, на еще большее количество источников. Приятного чтения! Шаг 1. Что такое исследовательское тестирование? Зачастую это первый вопрос, которым люди озадачиваются. Что это такое и, что важнее, зачем это использовать? Некоторые воспринимают исследовательское тестирование в негативном ключе – как будто тестировщики, занимающиеся им, просто тыкают куда попало, и оно не существует без подходов, основанных на тест-кейсах. Некоторые слышали о нем очень хорошие отзывы и хотят попробовать этот крутой "новый" метод. Ниже несколько статей, описывающих, что это такое и с чем его едят:
Упражнение: Если сейчас вы не пользуетесь техниками исследовательского тестирования и опираетесь только на тест-кейсы, понаблюдайте за собой при следующем прогоне кейсов. Действительно ли вы выполняете только указанные шаги и смотрите только на соответствующие им результаты, или же вы делаете больше? Смотрите ли вы по сторонам? Как вы сообщаете людям, что вы нашли, уйдя в сторону от сценария? Как вы сами это припоминаете? Делаете ли вы заметки, не относящиеся к шагам вашего кейса? Основаны ли ваши кейсы и их шаги на рисках проекта? Шаг 2. Как управлять исследовательским тестированием? Сессионный тест-менеджмент – самый популярный метод для управления исследовательским тестированием. Он помогает сделать этот тип тестирования управляемым и подотчетным, особенно если дело касается людей, не состоящих в команде тестирования. Майкл Болтон описывает его как коробки, в которые складываются облака (сессии исследовательского тестирования) – и эти коробки в результате можно пересчитать. Вот несколько статей об этом методе и отчеты об его использовании:
Шаг 3: где найти тест-чартеры? Вопрос, как генерировать тест-чартеры по сравнению с тест-кейсами, волнует многих, делающих первые шаги в исследовательском тестировании и сессионном тест-менеджменте. Большинство привыкло создавать кейсы на основе какой-то разновидности спецификации, которая утверждает, как должно работать ПО (и это необязательно значит "как мы хотим, чтобы оно работало"). Но как же создавать миссии для исследования в дополнение к тест-кейсам или вместо них? Неплохая идея – подумать о целях, которых вы хотите достичь в вашей миссии тестирования. Примеры Саймона для различных типов чартеров помогут вам с этим. Я также перечислил еще несколько моделей и статей, которые будут подспорьем в этом вопросе.
Упражнение: выберите один из перечисленных выше подходов и запишите три тест-чартера для ПО, с которым сейчас работаете. Вы можете использовать шаблон чартера из ссылок шага 2. Шаг 4: Как придумать идеи для тестов? Как только вы разобрались с миссией тестирования, начинается самое интересное – генерация идей, что именно тестировать, следуя своей миссии. Я видел тестировщиков, страдающих от "писательского кризиса", стоило им приступить к первым тест-сессиям. Особенно трудно им приходилось, если они никогда не писали кейсы сами, а только выполняли их в мире скриптованного подхода к тестированию. К счастью, существует множество методов и инструментов, помогающих генерировать идеи для тестов. Я перечислил некоторые из них – про них чаще всего слышишь, глубоко погружаясь в мир исследовательского тестирования, а некоторые из них помогли лично мне. Если вы действительно хотите полноценно изучить этот вопрос, перейдите по ссылке на Эрика Брикарпа и утоните в информации.
Упражнение: Помните тест-чартеры из предыдущего шага? Настало время выполнить эти тест-сессии. В качестве первого шага не тестируйте полтора часа, как указано во вводных текстах, начните с получаса. Шаг 5: Я закончил тест-сессию, что теперь? После одной (или нескольких) сессий должен состояться дебрифинг ("разбор полетов"). Я встречал людей, пропускающих этот этап и спрашивающих, действительно ли он так необходим. Если кратко – да. Если подробнее, то добавить еще одно совещание в расписание, конечно, непросто, но дебрифинг – очень важная, неотъемлемая часть этого процесса. Он помогает определиться с новыми тест-чартерами, распространить результаты тестирования в командах, выявить дыры в документации и процессах, и улучшить тестирование как таковое. Регулярные дебрифинги помогают тестировщикам развиваться профессионально. В целом дебрифинги – это важные совещания, на которых необходимо ваше присутствие. Вот полезные ссылки, объясняющие, как структурировать такие встречи.
Упражнение: Дебрифинг – это обычно совещание, его нельзя проводить в одиночку самостоятельно. Но я все же хочу попросить вас потратить время и поразмышлять над сессиями, которые вы провели в предыдущем упражнении. Запишите ответы на вот какие вопросы: Что произошло в ходе тестирования? Что вы узнали? Было ли что-то, что вы хотели протестировать, но не смогли, и почему? Что осталось протестировать в следующей сессии? Нашли ли вы новые интересные идеи для сессий? Какие? Что вы ощущали в процессе как тестировщик или как потенциальный пользователь? Раздражало ли вас что-то, а может, приятно удивило? Шаг 6: Есть ли инструменты, которые могут мне помочь? Наиболее очевидные для исследователя инструменты подходят какому угодно исследователю – это блокнот и ручка для записи всего, что обнаружено в ходе исследования. Однако многие интересуются специализированным ПО. Есть ПО, помогающее с сессионным тест-менеджментом – к примеру, оно аккумулирует метаданные сессии в секции "TASK BREAKDOWN". Так как заметки – важная часть тест-сессии, выберите подходящий для этого инструмент – лично я использую Evernote. Это наилучшее для меня решение в настоящий момент, особенно учитывая специальное клиентское приложение для Mac. Я хочу особо выделить инструмент TestBuddy. Он все еще в разработке и предназначен специально для исследовательского тестирования и заметок, а сделан людьми, искренне любящими этот стиль тестирования. Прототипы выглядят многообещающе. Пожалуйста, свяжитесь с ребятами из Qeek, они с нетерпением ждут вашей обратной связи и мнений.
Шаг 7: Как документировать тестирование? В окружении, широко использующем скриптованное тестирование и кейсы, тестировщики обычно документируют прогресс, отмечая шаги кейса как "пройденные" или "упавшие". Тест-сессия в сессионном тест-менеджменте так не работает – вместо этого она скорее похожа на заметки детектива, журналиста или ученого, сделанные в процессе расследования или эксперимента. Множество тестировщиков, перешедших на сессионный тест-менеджмент, удивляются объему писанины, который приходится выполнять во время прогона тестов, и им трудно найти идеальный баланс. Лично я убежден, что вы пишете не больше, чем в случае с тест-кейсами – ведь кейсы тоже надо писать! Кейсы обычно широко документированы, просто многие не связывают эту писанину с выполнением тестов, так как писали их задолго до начала тестирования, в отличие от тест-сессий. Еще хочется отметить, что в подходе, ориентированном на кейсы, тестировщики часто неверно документируют собственно сам процесс тестирования – к примеру, помечают все шаги как "вроде бы пройденные", хоть и пропустили несколько штук по привычке. Зачастую они не записывают странности (не баги), выходящие за пределы выполняемого кейса, и информация теряется. Очень важно найти здоровый баланс, документируя сессии тестирования. Ниже – список идей и отчетов. Не волнуйтесь – даже опытные тестировщики постоянно пересматривают свой подход к заметкам, как демонстрируют три последних ссылки.
Упражнение: 10 экспериментов Алана – отличный старт, как насчет попробовать их внедрить? Шаг 8: Пройдет ли исследовательское тестирование аудит? Я часто слышу, как люди списывают исследовательское тестирование со счетов, как простую игру с ПО, неструктурированный подход, который не переживет тщательного аудита. Это полная ерунда. Тестировщики пользуются техниками исследовательского тестирования в ситуациях со множеством ограничений. Ниже приведено несколько ссылок, которые помогут вам отчитаться о тестировании вне масштабов единичной сессии:
Упражнение: Попробуйте придумать низкотехнологичный дашборд для вашего приложения и обсудить его с командой. Книги В дополнение к статьям и ссылкам, вот несколько книг, которые я вам рекомендую:
|