Home

Автор: Джон Эндрюс (John Andrews)

Оригинал статьи: https://testingfromthehip.wordpress.com/2017/01/11/test-cases-are-evil-or-are-they/

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

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

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

Ряд недостатков тест-кейсов прекрасно документирован в статьях и блогах. Это обычно что-то вроде подобного списка:

1. Тестировщик тупо "проверяет", а не тестирует.

2. Следуя сценарию, можно упустить важные проблемы.

3. Тестировщик выключает мозг, гоняя тест-кейс.

4. Вы просто валидируете небольшой кусочек функциональности.

5. Любой может выполнять их – они не заменяют опытных тестировщиков, которые действительно умеют тестировать.

6. Если последовательность шагов так важна, автоматизируйте ее.

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

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

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

А? Что?

Что он только что посмел сказать?

Ниже – мои мысли по поводу достоинств тест-кейсов и того, как они поддерживают ваше тестирование. Как и все в тестировании, мои мысли зависят от контекста.

Итак, глубокий вдох, мы начинаем…

Время

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

Ресурсы

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

Напоминания

Когда на вас висит множество фич, зачастую вы постоянно спрашиваете себя "А что там у нас за воркфлоу?" или "Как там бишь это должно работать", или же "Как это там настраивается и конфигурируется, я забыл"? Еще вариант – "Какие данные мне нужны?". Я думаю, идея понятна. Тест-кейсы напоминают тестировщикам, как конфигурировать, настраивать и выполнять базовые сценарии. Когда время – деньги, это очень важно. Сильный профессионал всегда смотрит по сторонам, выполняя тест-кейс. Он использует его, как базу своего тестирования, направляющую его.

Доменное знание

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

Знания о продукте

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

Выработка единодушия

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

Технический долг

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

Лучше, чем ничего

Я часто описывал выполнение тест-кейса как тестирование, которое лучше, чем ничего. Хоть я и согласен с вышеописанными недостатками кейсов, в большинстве вышеописанных примеров они лучше, чем ничего.

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

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

И да, если можете, автоматизируйте эти чертовы кейсы!

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