Написание приемочных тест-кейсов (по определенным правилам)
В предыдущих заметках я уже упоминал о приемочных тестах, которые подготавливают тестировщики для принятия на тестирование очередной тестовой версии приложения.
Проясню немного ситуацию. На проекте сложилась классическая ситуация, описанная еще когда-то господином Канером, когда с появлением выделенного тестирования разработчики расслабляются и абсолютно перестают тестировать свои бесценные творения. Доходит даже до того, что написав что-то (или исправив очередную ошибку в коде) они даже не удосуживаются посмотреть, что же в результате их писательства получилось, а с легкой руки передают на тестирование. Спасибо, что хоть привычка компилировать еще сохранилась!
Для пресечения такой ситуации было перепробовано множество различных способов и методов, начиная с дружеского разъяснения, проведения обучающих семинаров, написания чек-листов и памяток для разработчиков и заканчивая различными степенями наказания (насколько позволяет корпоративная культура), но ничего не помогало. Поэтому было решено подготавливать некоторые наборы приемочных тест-кейсов для разработчиков, которые они в обязательном порядке должны прогонять на системе для разработке перед выкладкой тестовой версии. Обязательным условием выкладки тестовой версии является 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 тест-кейсов тестировщик вряд ли точно вспомнит, какие тест-кейсы прошли успешно, а какие нет.
Тестировщику придется потратить дополнительное время для того, чтобы восстановить в памяти, что было некоторое время назад и, самое главное, чтобы проставить все эти статусы (а если тест-кейсов будет несколько тысяч, а процесс тестирования будет занимать несколько месяцев, сколько же времени понадобиться на приведение статусов к актуальному виду?). И даже если тестировщику это удастся, то данная информация к тому времени утратит свою ценность.
Поэтому давайте делать все в свое время! Как говорится: «Дорога ложка к обеду».
Управление ошибками