Home

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2016/05/30/how-much-detail-is-too-much/

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

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

В ручном тестировании очень важно контролировать, что уже проверено, а что еще нет.

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

Я видел разные форматы кейсов:

• Общие описания, как должно работать,
• Пошаговые инструкции,
• Ad-hoc тесты без инструкций.

Аргументация у этих подходов тоже различается:

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

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

Дьявол в деталях

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

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

Пример

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

Если вы ручной тестировщик, предпочитающий детальность, ваш кейс может выглядеть вот так:

Тест-кейс: создание нового профиля пользователя

Открыть сайт http://www.mytestsite.org
Кликнуть по ссылке "Новый пользователь" в верхней части экрана.

Ввести имя пользователя на экране создания нового пользователя

Ввести пароль

Ввести пароль еще раз

Нажать "Подтвердить"

На странице "Расскажите о себе" выбрать профессию "Тестировщик"

Выбрать "Кандидат наук" из выпадающего списка уровня образования

Выбрать чекбокс "Оригами" в разделе "Хобби"

Нажать "Подтвердить"

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

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

Что будет, если для регистрации нужно будет вводить еще и электронную почту? Нам придется все переписывать! В каждом кейсе появится строчка "Введите валидную почту в поле "Почта".

Кейсы также придется перерабатывать, если:

• Изменится ссылка
• Изменится текст ссылки – вместо "Новый пользователь" она переименуется в "Регистрацию".
• Изменится заголовок экрана создания нового пользователя.
• Или заголовок экрана "Расскажите о себе".
• Уберут выпадающее меню со списком профессий (больно уж это личное, позор юзабилистам!)
• Все остальные секции изменят имя или исчезнут
• Значение, которое нужно выбрать при прохождении кейса, более недоступно…

Ну вы меня поняли, я думаю. Любая мелкая перемена повлечет за собой переработку всех связанных с ней кейсов, а такие правки – штука достаточно частая!

Болевая точка

Мой лозунг – это "Даешь поддержку каждой строчки кода!"

Но тут кроется огромное "но": не только каждая строчка кода, но и каждая строчка текста нуждается в поддержке, иначе она быстро протухнет.

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

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

В результате придется или нанять дополнительных людей, или просто забивать на ряд кейсов, чтобы успеть к сроку. И первый, и второй варианты обходятся довольно дорого.

Эта проблема, проблема масштабирования, не исчезнет никуда, если вы не начнете что-то менять.

Можно ли это исправить?

Да, я думаю, что можно. Всегда найдется способ сделать что-то лучше, чем это делается сейчас.

Мы не нанимаем для тестирования кого попало. А те, кого мы наняли, теоретически достаточно умны, чтобы запомнить, как что-то делается, после внятной демонстрации.

Вместо кучи подробностей попробуйте писать кейсы так, чтобы они доносили суть, но при этом не требовали постоянных переработок.

Создание нового профиля пользователя с профессией, образованием и хобби

Откройте сайт

Создайте нового пользователя с любой профессией, образованием и хобби

Сохраните информацию

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

Видите, что произошло? Мы стали писать не про то, как создавать нового пользователя. Мы скорее пишем, что именно мы хотим протестировать.

В каком случае детализация приносит пользу?

Безусловно, есть ситуации, когда пошаговые инструкции очень полезны, и все они относятся к автоматизированному тестированию.

Такой уровень детализации очень подходит для инструментов вроде Cucumber, который управляется и с тем, "как" мы будем тестировать, и с тем, "что" именно.

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

Чем меньше подробностей – тем лучше:

У такого метода составления кейсов есть и дополнительные выгоды:

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