Детализация описания тест кейсов (Test Case Specification)

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

Пример тест кейса 1:

Проверка отображения страницы
Действие	Ожидаемый результат	Результат теста
Открыть страницу "Вход в систему"	- Окно "Вход в систему" открыто - Название окна - Вход в систему - Логотип компании отображается в правом верхнем углу - На форме 2 поля - Имя и Пароль - Кнопка Вход доступна - Ссылка "забыл пароль" - доступна	...

Пример тест кейса 2:

Название: Проверка отображения страницы Действие: Открыть страницу "Вход в систему" Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и прилагаем изображение страницы "Вход в систему")

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

На нашем сайте вы также сможете найти пример оформления тест кейса

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

Вывод

В заключение скажу, для того чтобы команда тестирования работала сплоченно и не отвлекалась по вопросам оформления тест кейсов, у всех должен быть единый шаблон или подход к их написанию. То, что предлагаем мы - этоструктура PreConditions, Test Case Description, PostConditions, и уже ваше личное дела - пользоваться ей или придумать свой "велосипед".

Баг Репорт (Bug Report)

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

Для получения более детальной информации о баг репорте, мы рекомендуем Вашему вниманию следующую информацию, ознакомившись с которой вы получите исчерпывающее представление о структуре, особенности написания и некоторых других нюансах, необходимых для написания, хороших баг репортов:

• Структура баг репорта

• Серьезность и Приоритет дефекта

• Написание баг репортов

• Жизненный цикл бага

Предлагаем Вам комментарий одного разработчика: - Прочитав короткое описание бага (Bug Summary), я должен понять в чем состоит проблема, прочитав детальное описание бага (Bug Description) я должен знать строку кода, которую править.

С этим можно соглашаться или не соглашаться, но смысл этого высказывания в том, что вы должны делать все так, чтобы к вам меньше было вопросов по существу описанной в баг репорте проблемы. Так как каждый возвращенный вам баг репорт со статусом "Отклонен", "Не воспроизводится", "Требуется информация" (Rejected, Can't Reproduce, More info) - это потеря времени, как вашего так и разработчика. А время, как известно - это деньги, которые мы получаем, за то что делаем нашу работу лучше всех!

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

Раздел: Тестирование>Тестовые Артефакты>Баг Репорт> Основные поля баг/дефект репорта