Как писать тест-кейсы: полное руководство с примерами

В этом углубленном практическом руководстве по написанию тестовых примеров (тест-кейсов) подробно рассматривается, что такое тестовый пример, его стандартное определение и методы разработки.

Что такое тест-кейс?

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

Другими словами, это набор инструкций о том, “КАК” проверить определенную цель/задачу тестирования, выполнение которых позволит определить, удовлетворяет ли поведение ПО ожидаемому результату или нет.

Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

Что вы узнаете:

• Что такое тест-кейсы и как их писать?
  • Зачем мы пишем тестовые примеры?
  • Как писать тестовые примеры?
  • Стандартный пример тест-кейса.
  • Факторы, влияющие на написание тестовых примеров.
• Советы по написанию эффективных тест-кейсов.
  • Будьте просты, но не слишком; усложняйте, но в меру.
  • После документирования тестовых примеров пересмотрите их глазами тестировщика.
  • Облегчайте работу тестировщикам.
  • Принимайте участие.
  • Никогда не забывайте о конечном пользователе
• Как достичь совершенства в документировании тестовых примеров.
• Полезные советы и рекомендации.
  • Проверьте состояние тестового документа.
  • Не забывайте про негативные тест-кейсы.
  • Проводите атомарные тесты.
  • Определите приоритет тестов.
  • Уделите внимание последовательности.
  • Добавьте время тестирования и имя тестировщика в комментарии.
  • Включите информацию о браузере.
  • Держите в документе два отдельных листа — «Ошибки» и «Сводка».
• Как НЕ нужно писать тесты.
• 3 наиболее распространенные проблемы написания тест-кейсов.
  • Составные шаги.
  • Поведение приложения воспринимается как ожидаемое.
  • Несколько условий в одном примере.
• Как повысить эффективность тест-кейсов.
  • Сбор документов для написания тестов.
  • Реальный пример.
  • Документирование тестового случая.
  • Сбор данных для тестирования.
• Важность стандартизации тестовых примеров.
  • Причины повторного использования тестовых примеров.
  • Что такое стандартный тест в веб-тестировании?

Что такое тест-кейсы и как их писать?

Написание эффективных кейсов – это навык. Вы можете приобрести его на основе опыта и знаний о тестируемом приложении.

Уровни процесса написания тестов:

• Уровень 1: Вы разрабатываете основные примеры на основе имеющейся спецификации и пользовательской документации.
• Уровень 2: Практический этап, на котором написание примеров зависит от фактического функционального и системного потока приложения.
• Уровень 3: На этом этапе вы группируете несколько тест-кейсов и создаете тестовый набор, который представляет собой не что иное, как комбинацию небольших тестовых случаев (не более 10).
• Уровень 4: Автоматизация проекта. Это сведет к минимуму взаимодействие человека с системой, в результате чего специалист по обеспечению качества сможет сосредоточиться на тестировании обновленных в настоящее время функций, а не заниматься регрессионным тестированием.

Зачем мы пишем тестовые примеры?

Тест на знание Git – часть 1

Основная цель написания примеров заключается в проверке тестового покрытия приложения.

Если вы работаете в какой-либо организации, использующей CMMi (Capability Maturity Model Integration – Комплексная модель производительности и зрелости), то стандарты тестирования будут соблюдаться более тщательно. Написание примеров привносит своего рода стандартизацию и сводит к минимуму Ad-Hoc тестирование.

Как писать тестовые примеры?

Поля тест-кейса:

• Идентификатор.
• Модуль для тестирования: что должно быть проверено?
• Предположения.
• Тестовые данные: переменные и их значения.
• Действия, которые необходимо выполнить (они же шаги).
• Ожидаемый результат.
• Фактический результат.
• Тест пройден/не пройден.
• Комментарии.

Стандартный пример тест-кейса

Проверка (Verify)
Используя [название инструмента, имя тега, диалоговое окно и т. д.]
С [условия]
Для [что возвращается, показывается, демонстрируется]

Verify: Используется в качестве первого слова тестового оператора..
Используя: Для определения того, что проверяется. В зависимости от ситуации здесь можно использовать “ввод” или “выбор” вместо “использование”.Чтобы определить, что тестируется. Вместо использования здесь вы можете использовать «ввод» или «выбор» в зависимости от ситуации.

Для любого приложения необходимо охватить все типы тестов, такие как

• Функциональные.
• Негативные.
• Анализ граничных значений.

Все ваши тестовые примеры должны быть простыми и понятными.

Факторы, влияющие на написание тестовых примеров

Одним из наиболее частых и основных видов деятельности тестировщика программного обеспечения (специалиста SQA/SQC) является написание тестовых сценариев и примеров.

Есть несколько важных факторов, непосредственно связанных с этим основным видом деятельности. Давайте рассмотрим их подробнее.

Важные факторы, участвующие в процессе написания:

a) Тест-кейсы подвержены регулярному пересмотру и обновлению

Мы живем в постоянно меняющемся мире, то же самое относится и к программному обеспечению. Изменение требований к ПО напрямую влияет на документацию. Если требования поменялись, нужно изменить тест-кейс.

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

Во время регрессионного тестирования малейшие исправления и/или отклонения требуют пересмотра или создания новых тестов.

б) Тест-кейсы должны быть распределены между тестировщиками, которые будут их выполнять

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

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

в) Тест-кейсы склонны к кластеризации и пакетному распределению

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

Аналогично, в соответствии с бизнес-логикой AUT, один тест-кейс может отвечать нескольким условиям тестирования, а одно условие тестирования может включать в себя несколько тестов.

г) Тест-кейсы имеют тенденцию к взаимозависимости

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

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

д) Тест-кейсы склонны к распределению между разработчиками (особенно в TDD):

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

Аналогичным образом, если используется TDD (test-driven development – разработка, управляемая тестами), тестовые примеры напрямую используются разработчиками для построения логики и покрытия всех сценариев в коде, которые рассматриваются в тесте.

Советы по написанию эффективных тестов

Учитывая вышеперечисленные 5 факторов, рассмотрим несколько советов по написанию эффективных ТС.

1) Будьте просты, но не слишком; усложняйте, но в меру

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

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

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

2) После документирования тестовых примеров пересмотрите их глазами тестировщика

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

Оцените все шаги и проверьте, понятно ли вы их описали и соответствуют ли ожидаемые результаты этим шагам.

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

3) Облегчайте работу тестировщикам

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

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

Обеспечьте удобство тестировщикам, разбив тестовые примеры по категориям тестирования и соответствующим областям приложения. Четко проинструктируйте и упомяните, какие из них являются взаимозависимыми и/или объединенными в группы. Аналогично, явно укажите, какие тест-кейсы являются независимыми и изолированными, чтобы тестировщик мог соответствующим образом управлять процессом проверки.

4) Принимайте участие

Никогда не принимайте функциональную спецификацию (ФС) или проектную документацию такой, какая она есть. Ваша задача – не только просмотреть документацию и определить сценарии тестирования. Никогда не стесняйтесь вносить свой вклад в бизнес и что-либо предлагать, если вы чувствуете, что в приложении можно что-то улучшить.

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

Будучи действительно QA инженером, не просто тестируйте, а меняйте ситуацию к лучшему!

5) Никогда не забывайте о конечном пользователе

Самой важной заинтересованной стороной является “конечный пользователь”, который в итоге будет использовать приложение. Поэтому никогда не забывайте о нем на любом этапе написания тест-кейсов. На самом деле, конечного пользователя нельзя игнорировать ни на одном этапе SDLC. Тем не менее, мы пока акцентируем внимание на теме тестовой документации.

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

Как достичь совершенства в документировании тестовых примеров

Как тестировщики программного обеспечения, вы наверняка знаете, что создание идеального тестового документа – действительно сложная задача.

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

Очень важно хорошо понимать цель написания тестовых примеров, прежде чем приступать к процессу документирования.

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

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

Полезные советы и рекомендации

Здесь мы рассмотрим некоторые полезные рекомендации, которые могут дать вам преимущество при составлении тестовой документации перед другими.

1) Проверьте состояние тестового документа

Самый лучший и простой способ организовать документацию по тестированию – разбить ее на множество отдельных полезных разделов. Разделите весь процесс на несколько тестовых сценариев. Затем разделите каждый сценарий на несколько тестов. Наконец, разделите каждый пример на несколько этапов тестирования.

Если вы используете excel, документируйте тестовые случаи с на отдельном листе рабочего документа, где каждый тест описывает один полный поток тестирования.

2) Не забывайте про негативные тест-кейсы

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

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

3) Проводите атомарные тесты

Каждый шаг тестирования должен быть атомарным. Не должно быть никаких дополнительных подшагов. Чем проще и понятнее шаг тестирования, тем легче приступить к тестированию.

4) Определите приоритет тестов

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

Вы можете использовать любую кодировку для определения приоритета теста. Лучше использовать любой из трех уровней: высокий, средний и низкий, или 1, 50 и 100. Поэтому, когда у вас строгие временные рамки, сначала выполните все тесты с высоким приоритетом, а затем переходите к тестам со средним и низким приоритетом.

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

5) Уделите внимание последовательности

Убедитесь, что последовательность шагов в тесте абсолютно правильная. Если она будет неверная, это может привести к путанице.

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

6) Добавьте время тестирования и имя тестировщика в комментарии

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

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

7) Включите информацию о браузере

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

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

8) Держите в документе два отдельных листа — «Ошибки» и «Сводка».

Если вы ведете документацию в excel, то первые два листа рабочей книги должны называться “Сводка” и “Ошибки”. На листе “Сводка” должен быть кратко изложен сценарий тестирования, а на листе “Ошибки” должны быть перечислены все проблемы, возникшие во время тестирования.

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

Тестовый документ должен обеспечивать наилучшее тестовое покрытие, отличную читабельность и должен следовать одному стандартному формату.

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

Как НЕ нужно писать тесты

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

3 наиболее распространенные проблемы написания тест-кейсов.

1. Сложные шаги.
2. Поведение приложения принимается за ожидаемое.
3. Несколько условий в одном случае.

Эти три пункта входят в список самых распространенных проблем в процессе написания тестов.

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

Давайте обсудим каждый из них:

1) Составные шаги

Во-первых, что такое составной шаг?

Например, вы указываете направление из пункта А в пункт Б. Если вы скажете: “Поезжайте в пункт XYZ, а затем в ABC”, это не будет иметь смысла, потому что здесь возникает вопрос: “А как добраться до XYZ в первую очередь?” Куда лучше будет начать со слов “Поверните от этой точки налево и пройдите 1 километр, затем поверните направо на дорогу № 11, и вы попадете в XYZ”. Так можно добиться лучших результатов.

Те же правила применимы и к тестам и их шагам.

Например, тест для Amazon.com – разместить заказ на любой товар.

Ниже приведены шаги этого теста:

• Откройте Amazon.com.
• Найдите товар, введя ключевое слово/название товара в поле “Поиск” в верхней части экрана.
• Из отображаемых результатов поиска выберите самый первый.
• Нажмите кнопку “Добавить в корзину” на странице с информацией о товаре.
• Оформите заказ и оплатите.
• Проверьте страницу подтверждения заказа.

Теперь определим, какой из этих шагов является составным? Правильный ответ “Оформите заказ и оплатите”.

Помните, что тесты всегда проверяют “Как” тестировать, поэтому важно написать точные шаги “Как проверить и оплатить” в вашем тесте.

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

• Откройте Amazon.com.
• Найдите товар, введя ключевое слово/название товара в поле “Поиск” в верхней части экрана.
• Из отображаемых результатов поиска выберите самый первый.
• Нажмите кнопку Добавить в корзину на странице с информацией о товаре.
• Нажмите на кнопку Оформить заказ на странице корзины.
• Введите информацию о CC, доставке и выставлении счета.
• Нажмите Оформить заказ.
• Проверьте страницу подтверждения заказа.

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

2) Поведение приложения воспринимается как ожидаемое поведение

В наши дни все чаще встречается подобная ситуация.

Отсутствие документации, экстремальное программирование, быстрые циклы разработки – это лишь немногие причины, которые заставляют нас полагаться на приложение (его старую версию) для написания тестов или для построения процесса тестирования в целом. И это не самая лучшая практика.

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

3) Несколько условий в одном примере.

И снова давайте рассмотрим пример.

Посмотрите на приведенные ниже шаги теста. Это этапы тестирования в рамках одного теста для функции входа в систему:

• Введите достоверные данные и нажмите кнопку Отправить.
• Оставьте поле Имя пользователя пустым. Нажмите Отправить.
• Оставьте поле Пароль пустым и нажмите Отправить.
• Выберите уже зарегистрированное имя пользователя/пароль и нажмите Отправить.

То, что должно быть разделено на 4 разных действия, объединили в одно целое. Вы можете подумать – что в этом плохого? Это экономит много документации, и то, что я могу сделать за 4 раза, я делаю за 1, разве это не здорово? А вот и не так.

Что если только одно условие не сработает? Мы будем вынуждены отметить весь тест как “не пройден?”. Если мы это сделаем, значит по условиям документации все 4 шага не работают, что не соответствует реальности.
Тесты должны иметь поток. От предусловия к шагу 1 и далее по всем шагам по порядку.

Заключение

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

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

Перевод статьи «How To Write Test Cases: The Ultimate Guide With Examples».