Успешный тест-кейс дизайн

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


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

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

Test-case design from Alex Fruzenshtein

Теперь я бегло пройдусь по каждому слайду и поясню, что имелось ввиду в том или ином моменте. Начнем со слайда №4 - вводная часть. Старт был взят с определения терминов и определений, чтобы каждый присутствующий точно понимал о чем будет идти речь далее. Как оказалось это было очень даже эффективным шагом.

Слайды № 5-6 послужили примерами тест-кейсов, которые могут встретиться в работе. Далее в продолжении на №7, аудитории было предложено назвать основные составляющие тест-кейса. В итоге у нас получилось что-то вроде этого:

1. Title
2. Goal
3. Preconditions
4. Steps (Action, Test data, Expected resul, Status)
5. Postconditions

Тут я подчеркнул тот момент, что не каждая test-case management system предоставляет все эти "плюшки", но и это можно обойти незамысловатым лайвхаком. К примеру, если система не предоставляет отдельного поля для пункта Goal, то можно для этого использовать первую ячейку из множества Steps.

№ 8 -10 были предназначены для активного взаимодействия с аудиторией, кстати так и получилось. Обсуждали противостояние коротких тестов и длинных, поверхностных и детальных. К чему пришли в итоге? К разумной комбинации (как это непредсказуемо).

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