QA Engineer

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

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

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

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

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

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

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

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

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

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

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

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

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

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