Software Test

Test Cases. Простые и сложные.

Составление и написание Test Cases (тестовых примеров) является одним из ключевых моментов тестирования. Этому вопросу уделяют много внимания в различных публикациях по тематике тестирования. Мы не будем останавливаться на определении и правилах составления Test Cases. Цель этой статьи - дать не совсем обычный взгляд на проблему.

Мы неоднократно сталкивались с различными мнениями по этому вопросу. В одной из конференций была развернута целая дискуссия на эту тему. Как обычно мнения разделились.

Составление Test Cases помимо всех благ имеет и один существенный недостаток - время на написание. Именно на написание, т.к. разработка их в том или ином виде все же имеется в большинстве случаев.

Возьмем такой вариант: мелкая софтверная компания. Выдержать конкуренцию на рынке можно производством софта хорошего качества в кратчайший срок. Необходимость тестирования очевидна, но время решает все. Разработчику всегда проще написать код, чем документацию к нему. И, если за 1 месяц он подготовит продукт к передаче на тестирование, то с написанием документации этот срок растянется на 1,5 - 2 мес. Любая задержка в разработке - сокращение сроков на тестирование. Первое, возможно ошибочное, но часто принимаемое решение - не писать документацию. Для тестировщика в этом случае есть только один выход - разработка Test Cases по ходу изучения продукта, как только он будет передан на тестирование.

В этой ситуации (имеется в виду очень малый срок разработки или, например, работа малой команды над очень крупным проектом) тестировщику на разработку и написание Test Cases потребуется неоправданно (особенно, если так считает руководство) много времени. Убеждать руководство в большинстве случаев - так же трата времени (притом за частую неоправданная). Что можно предпринять в данной ситуации?

На наш взгляд, альтернативой может быть формулирование цели каждого Test Cases (не полное и подробное его описание, а именно формулирование того, что должно проверить). Такой список позволит не упустить чего-либо при проверке и вместе с тем даст возможность сэкономить время на "писанине".

И еще одна мысль. В программах с пошаговым интерфейсом (а его элементы присутствуют во многих программных продуктах), где переход на следующий шаг возможен только после выполнения всех "обязательных" действий на предыдущем, на наш взгляд, можно использовать сложные (или составные) Test Cases.

Т.е. если в некоторой программе в окне ШАГ_1 кнопка ШАГ2 становится доступной только после верного заполнения ПОЛЯ1, то проведя такой тест:

1. Запустить программу (предположим, что при старте сразу попадаем на окно ШАГ_1).
2. Заполнить ПОЛЕ1.
3. Нажать кнопку ШАГ2.
4. Завершить работу с программой.

при включении в него необходимых проверок, можно "убить" сразу целую "кучу" зайцев:

1. Проверить наличие окна ШАГ_1 при старте программы.
2. Проверить наличие ПОЛЯ1 в окне ШАГ1.
3. Проверить наличие кнопки ШАГ2 и смогу убедится, что она не доступна.
4. Проверить позволяет ли ПОЛЕ1 принимать нужное значение.
5. Проверить становится ли кнопка ШАГ2 доступной после п.4
6. Проверить, что при нажатии на кнопку ШАГ2 программа продолжает работу корректно.

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

На наш взгляд, Test Cases можно разделить на простые и сложные (или составные). Под "простым" мы понимаем такой Test Case, который на ряду с начальным (приведение программы в необходимое состояние) и конечным (перевод программы в исходное состояние) элементами имеет только один элемент верификации. "Составным" же можно назвать такой Test Case, который по мимо начального и конечного элементов включал бы в себя 2 и более элементов верификации.

Простые Test Cases можно рассматривать как некий "идеальный" вариант, к которому нужно стремиться. Он с успехом подойдет крупной или средней компании с хорошим финансированием, четкими сроками, достаточным количеством сотрудников и грамотно поставленным документооборотом.

Сложные (составные) Test Cases - альтернативный выход для мелких фирм с запутанными (или резко ограниченными) сроками, отсутствием документооборота и недостаточным штатом сотрудников.

См. также:
Тестинг. Test Cases.
Школа. Тест кейсы и тест свиты.
Школа. Кому нужны тест кейсы?