Стандартные ошибки при оформлении тест кейсов

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

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

Пример описания ожидаемого результата: «После выполнения шага 3, на экране должны отобразиться все элементы формы ввода данных.»

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

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

Неправильная структура тест кейсов:

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

Существует несколько типичных ошибок, которые встречаются при оформлении структуры тест кейсов:

• Отсутствие описания тест кейса: Каждый тест кейс должен иметь четкое описание, которое помогает понять его цель и ожидаемый результат. Описание может быть в формате простого текста или использовать структурированные шаблоны.
• Недостаточно детализированный шаги тестирования: Шаги тестирования должны быть максимально детализированными, чтобы тестировщики точно знали, что делать и что ожидать на каждом шаге. Важно указывать все необходимые действия и вводные данные.
• Отсутствие предусловий и ожидаемых результатов: Предусловия — это условия, которые должны быть выполнены перед началом теста, такие как наличие необходимого окружения или данных. Ожидаемые результаты — это то, что ожидается в результате успешного выполнения теста.
• Плохая структура документа: Тест кейсы должны быть организованы в логическом порядке. Рекомендуется использовать списки или таблицы для лучшей наглядности и удобства чтения. Важно также придерживаться единого стиля и формата оформления.

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

Неоднозначные и недостаточно информативные названия:

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

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

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

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

1. Будьте конкретными: Название должно ясно отражать тот функционал, который проверяется. Например, вместо «Тест кейс №1» лучше использовать «Аутентификация пользователя».
2. Используйте ключевые слова: В названии тест кейса можно использовать ключевые слова, которые ясно указывают на проверяемую функциональность. Например, «Регистрация нового пользователя», «Восстановление пароля».
3. Будьте информативными: Название должно содержать достаточно информации для установления связи между тест кейсом и требованиями или задачей, которые он проверяет. Например, «Проверка возможности добавления товара в корзину».
4. Старайтесь избегать сокращений: Сокращения могут быть непонятными для других участников процесса тестирования. Лучше использовать полные и понятные названия. Например, вместо «Создание нового ПО» лучше использовать «Создание нового программного обеспечения».

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

Отсутствие описания предусловий и шагов:

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

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

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

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

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

Пример:

1. Предусловия:
   • Пользователь должен быть зарегистрирован в системе.
   • На счету пользователя должны быть доступные средства для проведения покупки.
2. Шаги:
   1. Авторизоваться в системе, используя логин и пароль.
   2. Перейти на страницу каталога товаров.
   3. Выбрать товар из списка.
   4. Нажать на кнопку «Добавить в корзину».
   5. Перейти в корзину.
   6. Убедиться, что выбранный товар присутствует в корзине.
   7. Нажать на кнопку «Оформить заказ».
   8. Подтвердить детали заказа и нажать на кнопку «Оплатить».
   9. Убедиться, что заказ успешно оформлен и средства списаны со счета пользователя.

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

Ошибки в описании ожидаемого результата:

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

Ошибки, которые можно допустить при описании ожидаемого результата:

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

Как избежать ошибок в описании ожидаемого результата:

1. Детализируйте описание: уделяйте достаточно времени на составление деталей ожидаемого результата. Разбейте его на несколько пунктов, приведите примеры или укажите зависимости от других функциональностей.
2. Будьте конкретными: избегайте неоднозначностей и общих формулировок. Укажите конкретные значения, состояния или данные, которые ожидаются в результатах.
3. Проверьте описание: всегда перечитывайте и проверяйте описание ожидаемого результата. Удостоверьтесь, что оно является правильным и точным описанием функциональности.
4. Поддерживайте связь с разработчиками: чтобы быть уверенными в правильности описания ожидаемого результата, поддерживайте открытую коммуникацию с разработчиками. Уточняйте детали, задавайте вопросы и обсуждайте возможные сценарии работы продукта.

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

Игнорирование специфичных проверок:

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

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

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

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

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

Несоответствие ожидаемых результатов реальным:

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

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

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

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

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

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

Неактуализированные и необновленные тест кейсы:

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

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

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

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

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

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

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

Отсутствие проверки граничных условий:

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

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

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

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

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

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

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

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

Что такое чек-лист в тестировании?

Чек-лист (checklist) представляет собой список проверок, которые планируется провести для оценки качества цифрового продукта. Хотя нет единых жёстких правил по оформлению документа, любой хороший артефакт структурирован и разбит на смысловые блоки и секции. Каждый инженер составляет чек-лист в комфортном для себя формате или согласно требованиям компании.

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

Что важно при составлении чек-листа?

Создание качественногоартефакта – это уже половина успеха. При написании этого документа важно следовать нескольким рекомендациям:

• Придерживайтесь коротких, но прозрачных и понятных формулировок.
• Помните, один пункт списка – это один конкретный шаг.
• Не забывайте о принятых в команде формулировках. Это предотвратит искажённое толкование написанного.
• Убедитесь, что результаты оценки программного продукта по каждому из пунктов можно измерить или предельно точно оценить. Это очень важно при составлении чек-листа.

Специалистам (в особенности начинающим) при составлении артефакта очень поможетумение правильно задавать вопросы.

Чек-лист: как избежать ошибок?

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

1. Чек-лист – это не развёрнутая и досконально проработанная инструкция

Это только лаконичное напоминание, черновик для QA-процесса. Пункты списка касаются только основных этапов тестирования.

1. Чек-лист стоит рассматривать не как план работы, а как эффективнейший инструмент экономии времени

Данный артефакт служит отличной подсказкой, которая направит процесс оценки качество в верное русло.

1. Пункты чек-листа могут и должны корректироваться

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

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

Тест-кейс (test case) – это детальное описание проверки работоспособности программного решения. Совокупность подобных документов называется тестовым набором (test suite).

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

Какие ошибки допускаются тестировщиками при составлении чек-листов?

К типичным недочётам и недоработкам тест-кейсов можно отнести следующее:

• Чрезмерное упрощение документа. Иногда тестировщик настолько сильно увлекается сокращением излагаемой информации, что артефакт начинает походить на конспект. А ведь документ должен содержать исчерпывающий объём информации для инженеров, которые не работали над его составлением.
• Ссылки или копирование пунктов. Недопустимо на каком-либо шаге ссылаться на другой шаг(например, «повторить пункты под номерами 5 и 6 для реализации шага 10»). Такую проверку нужно либо исключить, либо скорректировать.
• Введение подразделов внутри одного пункта. Помните, каждый пункт – это одно конкретное действие.

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

Почему чек-лист и тест-кейс являются очень важными инструментами в руках тестировщика?

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

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

1. Зайти на сайт.
2. Открыть раздел «Книги: новинки».
3. Выбрать книгу.
4. Поместить книгу в корзину.
5. Перейти в корзину.

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

Заключение

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

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

В этом материале о тест кейсах вы узнаете:

1. Что такое тест кейс
2. Из чего состоит тест кейс и какая у тест кейсов форма
3. Правила написания хорошего тест кейса
4. Типичные ошибки в тест кейсах

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

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

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

Хотите научиться писать правильные тест кейсы? Научиться писать тест кейсы вам помогут наши менторы-тестировщики!

Форма тест кейса: из чего состоит тест кейс и поля в тест кейсах

У стандартного тест кейса есть 5 частей, то есть 5 атрибутов тест кейса:

1. Порядковый номер тест кейса
2. Название тест кейса. Из него должно быть понятно, в чем суть тест кейса
3. Предусловия тест кейса. Это условия, которые необходимы для проведения тест кейса. Они должны быть выполнены еще до запуска тест кейса.
   Допустим: компания сдает самокаты в поминутную аренду. Нужно провести тест кейс функции, которая уведомляет пользователя о том, что заряд аккумулятора самоката. Предусловием тест кейса будет то, что самокат должен находиться в состоянии аренды
4. Порядок действий в тест кейсе и описания действий в тест кейсе
5. Ожидаемый результат тест кейса.

Вот пример тест кейса:

Как написать хороший тест кейс: правила и форма хороших тест кейсов

У тест кейса может быть 3 вида результатов:

1. Положительный результат тест кейса. Фактический результат тест кейса совпадает с ожидаемым.
2. Отрицательный результат тест кейса. Фактический результат тест кейса отличается от ожидаемого.
3. Тест кейс не завершен. В процессе проверки тест кейса происходит ошибка.

Существуют 6 правил проведения тест кейсов:

1. Один тест кейс должен проверять только одну конкретную вещь.
2. Тест кейс не должен зависеть от других тест кейсов.
3. Шаги и ожидаемый результат тест кейса должны быть сформулированы четко и однозначно.
4. В тест кейсе должна быть вся информация. необходимая для его проведения.
5. В тест кейсе не должно быть лишних деталей.
6. Для каждого шага тест кейса нужно указывать тип вводимых данных: валидный или невалидный.

Прочитайте статью Что такое правильный баг репорт и по какому шаблону его оформить: базовые правила!

Типичные ошибки при написании тест кейсов

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

Плохо: Уведомление пользователя о заряде
Хорошо: Уведомление пользователя о снижении заряда аккумулятора вручную

Повелительное наклонение в тест кейсе
Это правило этикета тестировщиков.

Плохо: зайди на сайт; нажми на кнопку
Хорошо: зайти на сайт, нажать на кнопку

Не кликабельные ссылки
Не важно, это гиперссылки внутри вашей площадки или ссылки на какие-то внешние ресурсы. Вставили ссылку — нажмите «Ctrl + K». Добавьте тексту кликабельности.

Плохо: yandex.ru
Хорошо: yandex.ru

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

Плохо: нажмите на красную кнопку с надписью «Войти» в верхнем правом углу экрана, под меню.
Хорошо: нажмите на кнопку «Войти»

Недостаток деталей для проведения тест кейса
Ошибка, обратная предыдущей. Хороший тест кейс — это тест кейс, все действия которого можно выполнить, основываясь только на тексте самого тест кейса.

Плохо: перейти в режим разработчика
Хорошо:
1) Открыть меню
2) Перейти во вкладку «Дополнительные возможности»
3) Нажать на кнопку «Включить режим разработчика»

Хотите избежать типичных ошибок в тест кейсах? Вам помогут наши менторы-тестировщики!

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

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

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

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

Словарь терминов некоммерческой организации, занимающейся сертификацией в области тестирования (ISTQB), предлагает следующее определение тест-кейса: «… набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы или же для проверки соответствия определенному требованию».

Комплект из нескольких тест-кейсов принято называть тестовым набором (test suite). Не путайте с понятием тест-плана. Оно обозначает именно планирование работы: что, когда, зачем, как и т.д.

Атрибуты тест-кейса

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

• Уникальный идентификационный номер, состоящий из комбинации букв и цифр.
• Заголовок. Описывает цель тест-кейса. К примеру, тест-кейс для тестирования страницы входа может иметь заголовок «Проверка входа пользователя с верными данными».
• Предусловия. Шаги, предваряющие реализацию тест-кейса. При определенных условиях требуется ввод учетных данных.
• Шаги. Изложение действий, составляющих проверку.
• Постусловия. Список действий, необходимых для восстановления системы до исходного состояния. Указываются, если есть необходимость.
• Ожидаемый результат. Предполагаемый результат, к которому мы придем после реализации тест-кейса.
• Фактический результат. Состояние системы после совершения всех действий тест-кейса(не является обязательным).
• Статус. Успех (Success)/ провал (Failed)/ блокировка (Blocked). Отмечается не всегда, если требуется.

К некоторым формам тест-кейсов добавляют и другие атрибуты. Среди них:

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

Отличия тест-кейсов от чек-листов

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

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

Плюсы и минусы тест-кейсов

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

Минусы такого типа тестирования тесно взаимосвязаны.

• Заполнение требует долгой монотонной работы. Например, при тестировании корректного ввода ФИО надо выполнять простейшие одинаковые шаги: «ввести только символы, «ввести только числа» и т.д. Это особенно заметно, если посмотреть несколько тест-кейсов на один и тот же функционал.
• Затратное по времени редактирование. Малейшее изменение содержания сайта требует коррекции сотен сценариев тест-кейса. Не самое увлекательное и довольно выматывающее занятие.
• Некорректность тест-кейсов. Возникает из-за того, что при создании нового берутся элементы старого, которые не поменяли.

Скачать
файл

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

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

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

Виды тест-кейсов

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

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

Пример.

Надо проверить требование к системе записи клиентов в салон красоты: «В систему нужно добавлять новые филиалы и мастеров».

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

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

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

Правила разработки тест-кейсов

При разработке тест-кейсов учитывают следующие требования для каждого из его атрибутов.

Заголовок

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

Предусловие

• подробно описывает состояние объекта или системы, требуемое для выполнения шагов тест-кейса;
• список источников информации (описание системы, инструкции), которые тестировщик должен прочитать перед тем, как начать выполнение тест-кейса;
• если тестируемая информационная система обладает несколькими средами (прод, тест, препрод…), предусловие не должно включать ссылки на нее. Информацию о ресурсе следует разместить в инструкции, а ссылку добавить в предусловие.
• не прописываются данные для авторизации, их размещают в инструкции, оставляя ссылку в поле тест-кейса для предусловия;
• не должно включать ожидаемый результат и выполняемые шаги. Если есть необходимость держать открытой главную страницу сайта перед тем, как приступаем к шагам проверки, в предусловии отмечается: «открыта главная страница сайта»;
• не должно описывать ожидаемый результат.

Шаги проверки

• ключевые качества: доступность, четкость, последовательность;
• важно избавляться от чрезмерной подробности в описании. Например, вместо «первый шаг — нажать на клавиатуре цифру 2, второй шаг — нажать на клавиатуре цифру 5», следует писать «ввести число 25 в данном поле»;
• применяются только глаголы в неопределенной форме: ввести, нажать, удалить и т.д. Недопустимо: введите, нажмите, удалите;
• если требуется добавить комментарии или пояснения, они размещаются в виде инструкции в базе знаний, а в предусловии размещаем ссылку на нее;
• не допускаются конкретные статистические данные (названия файлов, логины и пароли) и примеры, во избежание эффекта пестицида.

Ожидаемый результат

• описывается у каждого шага проверки;
• содержит внятное и краткое описание состояния, в которое приходит программа или объект после реализации конкретного шага;
• не допустимы лишние описания.

Общие требования к тест-кейсам

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

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

Ошибки при создании тест-кейсов

Посмотрим, как правильно писать тест-кейсы и какие ошибки в них недопустимы.

• Слишком обобщенное название тест-кейса

Это создает путаницу между различными тест-кейсами одного проекта. Поэтому название должно отражать специфику каждого конкретного тест-кейса.

Неправильно: Уведомление пользователя об отсутствии интернет-соединения.
Правильно: Уведомление пользователя о потере Wi-Fi сигнала вручную.

• Употребление повелительного наклонения в тест-кейсе

Дело не в практической целесообразности, а в элементарной вежливости.

Неправильно: перейди на страницу; введи значение и т.д.
Правильно: перейти на страницу; ввести значение и т.д.

• Некликабельные ссылки

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

• Слишком подробные описания действий

Формулировки шагов тест-кейса не должны вызывать вопросов, но при этом не надо писать очевидные вещи.

Неправильно: Наведите мышку и нажмите на зеленую кнопку внизу страницы посередине с надписью «Согласен».

Правильно: Нажмите на кнопку «Согласен».

• Слишком краткое описание действий

Правильный тест-кейс лаконичен, но при этом не требует дополнительных объяснений.

Неправильно: Открыть меню «Дополнительные возможности».
Правильно:

• Нажать на иконку «Профиль».
• Перейти во вкладку «Настройки».
• Выбрать пункт «Дополнительные возможности».

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

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