Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно на моем тренинге тестировщица никак не могла разобраться в одном вопросе. Вот о чем она спросила:

Почему некоторые технические руководители (к примеру, руководитель технического отдела, менеджеры разработки, тест-менеджеры и тест-лиды) сразу бросаются к тест-кейсам, если хотят обеспечить отслеживаемость, поделиться усилиями тестирования с заказчиками, и передать знания о фичах тестировщикам?

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

Тестирование, как мы уже многократно заявляли, это не тест-кейсы – это процесс. Как уже говорилось, это процесс изучения продукта через его исследования и эксперименты над ним, что включает в себя (до определенной степени) оспаривание, обучение, моделирование, наблюдения, вмешательства, и так далее. Для этого тест-кейсы не нужны.

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

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

Давайте рассмотрим альтернативы достижения мечтаний руководителей (отслеживаемости, разделения знаний о деятельности тестировщиков, разделения знаний о продукте).

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

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

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

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

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

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

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

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

Хотите, чтобы люди знали, что вы сделали – запишите это и отчитайтесь об этом. Расскажите историю тестирования – она затрагивает не только статус продукта, но и то, как именно вы выполняли свою работу, и что именно сделало ее более или менее ценной, простой, быстрой.

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

Хотите, чтобы тестировщик быстро изучил продукт (или фичу) – дайте ему что-то, что он может изучать, с чем он может взаимодействовать, и дайте ему миссию. Поставьте тестировщика перед:

• Тестируемым продуктом (если он доступен),
• Старой версией продукта (пока ждете новую),
• Прототипом продукта (если он есть),
• Похожим продуктом или продуктом/фичей конкурента (при наличии),
• Спецификацией для анализа (или сравнения с продуктом, если он присутствует),
• Требованиями для изучения,
• Стандартом для ознакомления,
• Юзер-стори для вникания
• Обучающей инструкцией для ее прогона,
• Руководством пользователя для изучения,
• Диаграммой для интерпретации,
• Менеджером продукта для консультации,
• Другим тестировщиком для парной работы,
• Экспертом в нужной области для обрисовки бизнес-процесса.

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

(Что делать, если ничто из списка вам не доступно? У вас вообще ведется хоть какая-то деятельность по разработке? Если это так, чем руководствуются разработчики? Хинт: это не разработко-кейсы!)

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

Что использовать для подтверждения, что тестировщик действительно что-то изучил? Помимо своих заметок, тестировщик может:

• Поговорить с тест-лидом или тест-менеджером
• Предоставить отчет о том, что он делал, и что узнал (то есть отчет о тестировании)
• Предоставить описание продукта или фичи, багов, и так далее (см. эвристику The Honest Manual Writer)
• Предложить исправления, расширения или уточнения для перечисленных выше артефактов
• Набросать список проблем в продукте, с которыми он столкнулся
• Разработать способы, при помощи которых тестировщики могут выявлять несоответствия между продуктом и некими пожеланиями (то есть список полезных оракулов)
• Перечислить в ментальной карте идеи, как можно узнать о продукте больше (а это тест-стратегия)
• Разработать набор идей о том, где искать проблемы в продукте (то есть набросок продуктового покрытия)

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

У моей клиентки были другие вопросы о тест-кейсах. О них мы поговорим в следующий раз.

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