Home

Автор: Виктория Кузнецова (Viktoria Kuznetcova)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=25

Перевод: Ольга Алифанова

Исследовательское тестирование набирает популярность в последнее время. Это не может не радовать, однако я обнаружила, что люди, говорящие о нем, подразумевают совершенно разные вещи. Иногда эта разница довольно забавна, иногда шокирует и открывает глаза на то, что скрыто. Иногда – к примеру, когда ваш коллега отказывается пробовать что-то новое, утверждая, что «и так занимается исследовательским тестированием», это просто раздражает.

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

Исследовательское тестирование – это не просто использование диаграмм и сессионного тестирования, это не работа в Agile-окружении, и это совершенно точно не список эвристик, который вы обязаны использовать. Для меня оно сосредоточено на идее исследования. Это про обучение, расследование, разъяснения. Это задавание вопросов, экспериментирование, приобретение знаний о тестируемом объекте. Мне нравится думать о себе, как о марсоходе «Кьюриосити» или как о члене команды Звездолета. Я исследую новые миры. Я знаю, что никогда не узнаю всего, что можно узнать, но у меня есть нужные инструменты, увлеченность, и желание учиться.

Как тестировщик, я приступаю к работе, вооруженная знаниями и предположениями о проекте, который я тестирую. Обычно у меня на руках есть требования бизнеса, описание технологии, понимание окружения, общие знания об IT, ожидания от ПО, основанные на личном опыте работы с похожими задачами, и так далее. Я создаю карту, основанную на моем опыте. Карта включает стратегию тестирования и идеи тестирования, которые я собираюсь развивать. У меня под рукой множество помогающих мне инструментов – от специализированного ПО до техник тест-анализа. Все это необходимо, чтобы помочь мне – но если я дам техникам и инструментам определять, что мне делать, моя работа станет механической. Мне не понадобится мощь человеческого мозга – тестирование сведется к использованию инструментов и выполнению предначертанных сценариев. Когда я тестирую методом свободного поиска, я постоянно задаю вопросы и проверяю свои предположения. Поразительно, сколько можно получить, действуя согласно этой простенькой идее.

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

Исследовательское тестирование делает работу веселее – не стоит это недооценивать, если вы так же быстро начинаете скучать, как, например, я. Оно также подталкивает вас к использованию техник из других областей – люди исследуют мир с момента своего появления в нем, и исторический опыт и мудрость вполне применимы в тестировании. Примите в расчет огромное количество литературы про научные методы, двойное слепое тестирование в социологии, профилирование преступников в ФБР, планирование разведывательных операций на территории противника – все эти техники могут дать вам что-то полезное как тестировщику.

Если вы согласны со мной, что тестирование завязано на задавание вопросов и поиск знаний, вы можете использовать это понимание, имея дело с задачами, которые попадают в ваши руки. Я зачастую обнаруживала, что менеджер продукта, или же тот, кто отвечает за проект, давит тест-команду вопросами типа «готовы ли мы к релизу» и «когда мы будем готовы». Проблема в том, что тест-команда не имеет власти повлиять на ситуацию. Они не могут решать, что допустимо для релиза, а что нет, они не могут добавить время на тестирование или на разарботку, и они не могут подталкивать разработчиков, дизайнеров и переводчиков. А если у тебя нет власти, у тебя нет и ответственности.

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

1. Миссия тестирования – это не обеспечение качества, а сбор и предоставление полезной информации тем, кто принимает решение о продукте и его качестве.
2. Исследовательское тестирование – подход, который не зависит от используемой модели жизненного цикла. Оно применимо в любой ситуации, даже вне области разработки ПО.
3. Соглашаться на точные данные о том, сколько времени понадобится на тестирование, на длинной дистанции – очень плохая идея. Тестирование зачастую – это вход в темную комнату, которая продолжает меняться. Убедитесь, что ваше руководство знает, что может повлиять на тестирование, и способно изменить временные оценки.
4. Исследовательское тестирование состоит из множества итераций двух совершенно разных фаз – обнаружение и исследование. Каждая фаза по-своему трудна и преследует различные цели. Обнаруживая, вы сконцентрированы на поиске проблем, а исследуя – на сборе информации, которая необходима для работы с этой проблемой.
5. Используйте тест-идеи, чтобы направлять свое тестирование, а не тест-кейсы, определяющие его. Задавать вопросы и смотреть на проблемы под разными углами очень важно, как и использовать новые тесты вместо старых.
6. Используйте автоматизацию для рутинных задач – развяжите себе руки для более интересных проблем. Автоматизация не должна быть заменой ручного тестирования.
7. Давайте обратную связь, как только сможете ответить на важные для проекта вопросы. Делает ли эта фича то, что должна? Исправлен ли этот баг? Давайте внятную и специфичную обратную связь, и убедитесь, что она не принимает форму личного оскорбления.
8. Приоритезируйте свою работу: решите, какие фичи тестируются в первую очередь, сколько времени потратить на задачу, какие риски снизить, с каких задач начать. Риск-менеджмент – неплохой базовый интрумент, помогающий в этих случаях.
9. Знайте свои инструменты: эвристики, практики, диаграммы, ПО, помогающее в работе.
10. Знайте ваше ПО как с точки зрения бизнеса, так и с точки зрения технологии. Какие проблемы оно должно решать, кто входит в круг      заинтересованных лиц, и как оно должно работать?
11. Не тратьте время на документацию, которую никто не будет ни читать, ни использовать. Пусть ваша документация будет необходимым, постоянно поддерживаемым в актуальном состоянии минимумом. Не держите ваш опыт и знания в голове, делитесь ими.

Последнее, о чем я хотела бы сказать – это о распространенном заблуждении, что к исследовательскому тестированию можно подпускать только опытных тестировщиков. Возможно, за это надо выругаться в адрес ISTQB – они описывают исследовательское тестирование именно так. Мой опыт как тестировщика и тест-лида говорит о том, что это ложь. Тестировщик-новичок (в продукте или в разработке как таковой) может обучиться исследовательскому тестированию и немедленно к нему приступить.

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

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

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