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

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

— Полнота — документ должен содержать абсолютно всю информацию, чтобы достичь цели тестирования, ради которой он создан, и сравнить ожидаемый результат с фактическим.

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

Немного практических советов

Обратите внимание на формулировки в вашем тест-кейсе и то, в каком времени они указаны. Описывая предварительные условия вашего документа, лучше придерживаться формулировки, отвечающей на вопросы «Что сделано?» или «Что должно быть сделано?». Шаги проверок стоит описывать, отвечая на вопрос «Что сделать сейчас?». Ожидаемый результат лучше описывать как завершенное сбывшееся действие, отвечая на вопрос «Что сделано/получено/запущено?»

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

Пример разного ожидаемого результата

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

Если вы имели в виду первый вариант, но использовали формулировки из второго, то поймет ли это тот, кто будет проходить ваш тест-кейс или же он воспримет текст буквально? Лучше избегать подобных разночтений.

Об атомарности и сложности тест-кейса

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

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

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

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

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

Говоря о сложности тест-кейсов, можно сказать, что атомарные тест-кейсы сами по себе короткие, простые в понимании и проверках. Однако при таком подходе сложно контролировать аспекты системы и согласованность тест-кейсов. На практике далеко не каждый проект может позволить себе атомарные тест-кейсы. Это может быть связано как со спецификой тестируемого продукта, так и с бюджетом проекта.

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

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

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

Также это влияет на модифицируемость документа в случае обновлений функционала. Объемные тест-кейсы сложны для чтения и понимания сути их действий и проверок. Иногда необходимо удерживать в голове тонкости нескольких таких больших тест-кейсов, чтобы они оставались согласованными после обновления.

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

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

5.2. Bug Report

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