Написание приемочных тест-кейсов (по определенным правилам)

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

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

Для пресечения такой ситуации было перепробовано множество различных способов и методов, начиная с дружеского разъяснения, проведения обучающих семинаров, написания чек-листов и памяток для разработчиков и заканчивая различными степенями наказания (насколько позволяет корпоративная культура), но ничего не помогало. Поэтому было решено подготавливать некоторые наборы приемочных тест-кейсов для разработчиков, которые они в обязательном порядке должны прогонять на системе для разработке перед выкладкой тестовой версии. Обязательным условием выкладки тестовой версии является 100% Pass приемочных тест-кейсов. После выкладки тестовой версии тестировщики начинают свою работу с повторного прогона того же самого приемочного набора для проверки того, что разработчики действительно выполнили все тест-кейсы (а не просто проставили отметки). Я здесь не вдаюсь в технические детали всей этой процедуры. По результатам такой проверки тестировщиками происходит разбор полетов, после которого кто-то получает прянички, а кто-то кнуты.

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

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

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

2. Существует два варианта подготовки приемочных тест-кейсов: первый — после подготовки набора тест-кейсов для полного тестирования выбрать из него тест-кейсы для приемочного тестирования, которые покрывают основной (положительный) путь работы приложения; второй — специально подготовить набор только приемочных тест-кейсов.

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

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

Сокращенно звучит он так — один тест-кейс — одна проверка.

Как реагировать на следующий тест-кейс?

...

Steps

1. Действие 1

2. Действие 2

3. Действие 3

4. Действие 4

Expected Results

1. Результат 1

2. Результат 2

3. Результат 3

4. Результат 4

...

Каждому номеру действия необходимо сопоставлять соответствующий номер ожидаемого результата? Или же после выполнения полностью всех действий мы получим результат, состоящий из четырех пунктов? А может быть как — то еще?

Здесь же встает еще и другой вопрос — какой статус выставлять для тест-кейса, если либо часть действий выполнилась, а часть нет, либо в результате успешного выполнения всех действий часть ожидаемых результатов появилась, а часть нет?

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

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

5. Своевременность отметок о прохождении/сбое тест-кейсов

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

В нашем случае цель проста — в любой момент времени отслеживать текущую ситуацию по процессу выполнения тест-кейсов:

• процент выполнения от общего запланированного количества;
• количество успешно пройденных тест-кейсов;
• количество проваленных тест-кейсов;
• и другие производные от них метрики.

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

Чаще всего тестировщики не проставляют отметки сразу же, откладывая на потом, когда полностью закончат тестирование. Какие я вижу минусы в этом подходе:

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

Выполнив 125 тест-кейсов тестировщик вряд ли точно вспомнит, какие тест-кейсы прошли успешно, а какие нет.

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

Поэтому давайте делать все в свое время! Как говорится: «Дорога ложка к обеду».

Управление ошибками