Как видите, контрольные списки и тест-кейсы значительно упрощают процесс тестирования. Разница между ними заключается в том, что контрольные списки показывают направление тестирования, в то время как тест-кейсы подробно описывают, как проводить тестирование.
Основы тестирования. Тест-кейсы и чек-листы
Думаю, даже противники бюрократии не будут отрицать, что описанный контрольный список значительно упрощает процесс тестирования и экономит массу времени в дальнейшем.
Так что же это за документы и как сделать их своими помощниками, а не врагами? Ответ на эти вопросы вы найдете в этой статье.
Тестовые случаи и контрольные списки являются частью тестовой документации. Их цель — систематизировать и упростить процесс тестирования, сделав его более прозрачным и структурированным. Они также могут сэкономить много времени.
Тест-кейс
Тестовый пример — это набор входных значений, предполагаемых условий выполнения, ожидаемых результатов и условий после выполнения, предназначенный для конкретной цели или условия тестирования, например, для выполнения определенного пути программы или проверки определенного требования. IEEE 610
Другими словами, это артефакт или документ, который описывает наши тесты. В нем указывается, как они должны быть выполнены, при каких условиях, и каков должен быть ожидаемый результат после выполнения шагов, указанных в тестовом примере, т.е. каков ожидаемый результат.
Для стандартизации и упрощения создания и дальнейшего чтения тестовых случаев тестовый случай имеет определенный шаблон. Шаблон является условно стандартизированным, поскольку в разных компаниях и процедурах он может отличаться.
1. ID — это уникальный номер. Обычно они автоматически сохраняются в системах хранения тестовых примеров.
2. краткое описание тестового случая (название). Название тестового случая должно быть коротким и понятным. Эти два слова очень важны.
Если мы будем использовать только короткое имя, то в таких случаях будет очень трудно сориентироваться. Например, мы проверяем запись и вызываем тестовый пример: «Проверьте успешную регистрацию. Это кажется логичным, но такое название предполагает проверку записей в нескольких полях. И оказывается, что название не является информативным.
Например, если название тестового случая слишком длинное, его очень трудно прочитать: «Проверка правильности ввода при вводе логина латинскими буквами без цифр и пробелов с паролем из цифр». Такой заголовок трудно читать. Кроме того, некоторые инструменты для хранения тестовых примеров могут отсекать длинные имена.
Что делать? Немного сократите название, уберите «test» и слова, не имеющие важного значения, и вы получите следующее: «Вход по латинскому ярлыку», «Вход по ярлыку с цифрами» и так далее.
3. ссылка на требования — ссылка на требование или TSI, в соответствии с которым был создан тестовый пример.
4. автор — тестировщик, написавший тестовый пример.
5. приоритет — насколько важен данный тест, в каком порядке он должен быть выполнен.
6. компонент/версия — описание программного обеспечения, с помощью которого может быть выполнен тестовый пример.
7. предварительное условие — шаги, которые должны быть предприняты перед тестированием данного тестового случая.
8. шаги — точная последовательность действий для выполнения теста.
Шаги должны быть четкими и понятными. В идеале они должны быть написаны таким образом, чтобы человек, впервые видящий проект и тесты, мог их понять. Четкие шаги снижают риск того, что тестовый пример будет неправильно понят другими тестировщиками и, следовательно, протестирован неверно, особенно новичками, которые только что присоединились к проекту. Иногда вам даже трудно понять, что вы имели в виду под тем или иным шагом, спустя некоторое время.
9 Ожидаемый результат — то, что мы получим после выполнения шага.
10 Вложения — дополнительная информация, которая помогает нам выполнить тестовый пример, например, скриншоты, текстовые и другие файлы.
Тест-кейс для авторизации на сайте
Рассмотрите возможность написания тестового примера для примера проверки формы разрешения на сайте. Предположим, нам нужно проверить разрешение существующего пользователя:
1 ID Пусть это будет номер 1, так как это наш первый тестовый случай.
2 Краткое описание тестового случая (название) Существующее разрешение пользователя.
Если бы у нас было несколько способов регистрации (телефон, электронная почта, ВКонтакте, Facebook и т.д.), название выглядело бы так: «Аутентификация существующего пользователя через ВКонтакте».
3. связь с требованиями В нашем случае требований нет. Это означает, что мы оставляем это поле пустым.
Автор Иванов И.
5. высокий приоритет, так как важна функциональность. Короче говоря, чем важнее предмет тестирования и проверки, тем выше приоритет.
6. название продукта/устройства/версия (Component/Version) Случай относится непосредственно к гарантии, поэтому указывается это устройство.
7. Необходимое условие Во-первых, пользователь должен войти в систему https://msk.farfor.ru. Во-вторых, пользователь должен существовать и не быть зарегистрированным в системе.
8. шаги (Steps) 1) Введите «+7 900 000-00-00» в поле, 2) Введите пароль «123» в поле, 3) Нажмите кнопку «Login».
9. ожидаемый результат Авторизация прошла успешно, пользователь останется на странице https://msk.farfor.ru.
10. Вложения На этот раз нам не нужны никакие файлы, поэтому мы их опустим.
Для наглядности мы включим их все в таблицу.
Обратите внимание, что лучше всего указывать любые проверочные данные, такие как электронная почта или пароль, чтобы избежать путаницы и хлопот при попытке найти нужную учетную запись.
В приведенном выше примере все шаги приводят к одному и тому же результату. Однако бывают ситуации, когда каждый шаг приводит к другому ожидаемому результату.
Когда для компонента выполняется несколько тестов, тестовые случаи могут быть объединены в набор тестов.
Теперь давайте немного поговорим о контрольных списках в тестах.
Контрольный список (частная команда) — создается на основе команды. Обычно он содержит полное описание конкретной части разрабатываемого продукта и ВИ (варианты использования, сценарии использования объекта разработки пользователями, макеты разрабатываемой части объекта разработки, его логика и суть).
Чек лист в тестировании: назначение
Контрольные списки незаменимы для компаний, поскольку они выполняют следующие функции:
- Улучшение организации труда. Упорядоченная последовательность действий помогает вам сосредоточиться, не упустить из виду важные аспекты, действовать быстро и эффективно,
- увеличить производительность. В руководстве определены приоритеты, на которых следует сосредоточиться. Сотрудникам не нужно время, чтобы обдумать процесс и принять правильное для себя решение,
- Контроль. Установленная последовательность действий важна и полезна как для самоинспекции, так и для инспекции третьей стороной,
- Снижение стресса. Негатив перед решением общего проекта снижается, поскольку он разделен на множество мелких проектов, которые можно легко выполнить. Дополнительная нагрузка на память снижается. Поощряются креативность и экстравертное мышление в контексте четко поставленной задачи.
Чек лист тестирования сайта
При тестировании веб-сайта инженеры QA выполняют определенную последовательность проверок. Результат каждой операции должен соответствовать ожиданиям. Список этих проверок составляет контрольный список. Он имеет форму списка или таблицы, хорошо структурированной для работы, пронумерованной или маркированной.
Использование этого инструмента во время тестирования помогает получить полное представление о системе, определить состояние готовности, не упустить ни одного важного аспекта работы и спланировать дальнейшие действия по оптимизации процесса.
Образец контрольного перечня для проверки сайта:
Тест кейс и чек лист: сходства и отличия
Контрольный перечень представляет собой четкое перечисление последовательности действий, которые необходимо предпринять для проверки испытуемого объекта.
Тестовый пример — это пошаговый алгоритм тестирования.
Таким образом, тестовый случай — это более узкое понятие, описание конкретного направления тестирования, в то время как контрольный список — это серия всех страниц тестовых сценариев. Тестовые примеры пишутся очень четко и прозрачно, максимально подробно, чтобы исключить все вопросы, которые могут возникнуть, включая все возможные нюансы.
