Автор: Пол Симан (Paul Seaman) в соавторстве с Ли Хокинсом (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

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

Что имеется в виду под детализированными тест-кейсами?

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

Начнем с начала

Для целей этой статьи начало – это планирование. Статья защищает детализированные кейсы следующим образом:

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

Помогает продумать, что нужно протестировать

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

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

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

Планирование приведет к ускорению тестирования и нахождению большего количества дефектов.

Удивительно обнаружить подобное утверждение без малейших доказательств его правоты. Так как в основе тестирования лежат доказательства, нам кажется странным заявлять нечто подобное и ожидать, что оно будет принято как факт. Недоумеваем, как автор пришел к обоим выводам.

Имеет ли автор в виду, что следование детальным инструкциям приведет к более высокой скорости тестирования? Это аргумент в защиту продуктивности ценой эффективности? Основываясь на опыте, мы бы сказали, что детализированные тест-кейсы и неэффективны, и непродуктивны. Много лет назад Пол, работая в водопаде, решил создать детальные кейсы, которые может выполнить кто угодно. На тот момент это было "золотым стандартом" мышления в тестировании. Три недели спустя Пола назначили на тестирование. В промежутке он занимался другими проектами, и, вернувшись, обнаружил, что дополнительные детали были абсолютно бесполезны. Они были в состоянии "на тот момент". В связи с отсутствием актуальных знаний о продукте кейсы были неясными, и понадобилось много работы, чтобы включиться в тестирование изменений. Если вы когда-либо работали с чужими детализированными кейсами, вам знакома эта проблема.

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

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

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

Вы должны быть способны организовать тестирование оптимальным образом

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

Если мы концентрируемся (как и должны) на риске, у нас будет представление о порядке запуска тестов, но мы не можем знать это наверняка, пока не начнем тестировать и видеть поведение системы своими глазами. Даже в случае единичного теста наш взгляд на "оптимальное" может измениться, поэтому мы должны оставаться достаточно гибкими, чтобы суметь изменить направление и планы по ходу дела.

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

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

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

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

Выводы

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

Дополнительное чтение:

• Бах, Ходдер: "Тест-кейсы – это не тестирование" 
• https://software-testing.ru/library/testing/general-testing/2724-test-cases-not-testing-2
• Болтон: "Тест-кейс – это не тест” 
• Серия статей Болтона "Легкий способ бросить тест-кейсы"