В любом приложении «вход в систему» — это процесс доступа к приложению лицом, имеющим действительные учетные данные пользователя. «Вход в систему» обычно используется для входа на определенную страницу, которую злоумышленники не видят.
В этом посте мы увидим «Тестовые сценарии для страницы входа». Тестирование страницы входа очень важно для любого приложения с точки зрения безопасности. Мы постараемся охватить здесь наиболее широко используемые сценарии страницы входа, включая функциональные тестовые случаи, тестовые случаи безопасности, тестовые случаи пользовательского интерфейса и т. д.
Ранее мы обсуждали некоторые из связанных сообщений, и вот для справки.
- Шаблон тестового набора с подробным объяснением
- Шаблон плана тестирования с подробным объяснением
- Тестовые наборы для страницы регистрации
- Тестовые наборы для банкомата
- Сценарий тестирования vs Test Case
- Стратегия тестирования vs план тестирования
Обычно мы пишем тестовые примеры для страницы входа для каждого тестируемого приложения. Каждая страница входа должна содержать следующие элементы.
- ‘Электронная почта/Номер телефона/Имя пользователя‘ Текстовое поле
- ‘Пароль‘ Текстовое поле< li>Кнопка ‘Войти‘
- ‘Запомнить меня‘ Флажок
- ‘Оставаться в системе‘ Флажок
- ‘< strong>Забыли пароль’ Ссылка
- ‘Зарегистрируйтесь/Создайте учетную запись‘ Ссылка
- CAPTCHA
Здесь мы сосредоточимся на следующем, чтобы написать тестовые примеры для страницы входа.
- Мы должны написать тестовые примеры для каждого объекта в форме входа.
- Мы должны написать как положительные, так и отрицательные тестовые случаи.< li>Нам нужно написать как функциональные, так и нефункциональные тестовые примеры.
- Мы должны написать пользовательский интерфейс, функциональные тесты, тесты совместимости и производительности.
Обязательно к прочтению: Тестовый пример и тестовый сценарий
Примеры тестовых случаев для страницы входа (включая пользовательский интерфейс, функциональные и нефункциональные тестовые примеры для страницы входа)
Тестовые примеры страницы входа (страница входа в сценарии тестирования):
Ниже приведены тестовые случаи для страницы входа пользователя. Список состоит из положительных и отрицательных тестовых сценариев страницы входа, а также тестовых случаев пользовательского интерфейса, тестовых случаев безопасности и т. д.
Сценарии тестирования пользовательского интерфейса страницы входа
- < ли>Убедитесь, что экран входа содержит такие элементы, как имя пользователя, пароль, кнопка входа, флажок «Запомнить пароль», ссылку «Забыли пароль» и создайте ссылку на учетную запись.
- Убедитесь, что все поля, такие как «Имя пользователя», «Пароль», имеют допустимый заполнитель< li>Убедитесь, что все текстовые поля имеют минимальную и максимальную длину.
- Убедитесь, что метки перемещаются вверх, когда текстовое поле находится в фокусе или заполнено (в случае плавающей метки).
- Убедитесь, что шрифт стиль и размер меток, а также текст на каждом объекте хорошо видны.
- Убедитесь, что пользовательский интерфейс приложения (UI) является адаптивным, чтобы оно адаптировалось к различным разрешениям экрана и устройствам.
- Убедитесь, что страница входа и все поля на странице входа отображаются без перерыва в разных браузерах
Сценарии функционального тестирования страницы входа
- Убедитесь, что курсор сфокусирован на текстовом поле «Имя пользователя» при загрузке страницы (страница входа)
- Проверьте эта функция вкладки работает правильно или нет
- Убедитесь, что клавиша Enter/Tab работает вместо кнопки «Вход»
- Убедитесь, что пользователь может войти в систему с действительными учетными данными
- Убедитесь, что пользователь не может войти в систему с недопустимым именем пользователя и неверным паролем< li>Убедитесь, что пользователь не может войти в систему с действительным именем пользователя и неверным паролем
- Убедитесь, что пользователь не может войти в систему с недопустимым именем пользователя и действительным паролем
- Убедитесь, что пользователь не может войти с пустым именем пользователя или паролем
- Убедитесь, что пользователь не может войти в систему с неактивными учетными данными
- Убедитесь, что кнопка сброса очищает данные из всех текстовых полей в форме входа
- Убедитесь, что учетные данные для входа, в основном пароль, хранятся в базе данных в зашифрованном виде. format
- Убедитесь, что нажатие кнопки «Назад» в браузере после успешного входа в систему не должно переводить пользователя в режим выхода из системы
- Убедитесь, что сообщение о проверке отображается в случае, если пользователь оставляет имя пользователя или пароль пустым
- Убедитесь, что в случае превышения лимита символов в полях «Имя пользователя» и «Пароль» отображается сообщение о проверке.
- Убедитесь, что сообщение о проверке отображается в случае ввода специального символа в поля «Имя пользователя» и «Пароль». in” по умолчанию не установлен (зависит от бизнес-логики, он может быть установлен или снят)
- Убедитесь, что тайм-аут сеанса входа в систему (Session Timeout)
- Убедитесь, что ссылка выхода перенаправляется на вход/домашнюю страницу
- Убедитесь, что пользователь перенаправляется на соответствующую страницу после успешного входа в систему
- Убедитесь, что пользователь перенаправляется на страницу «Забыли пароль» при нажатии на ссылку «Забыли пароль».
- Убедитесь, что пользователь перенаправляется на страницу «Создать учетную запись» при нажатии на ссылку «Зарегистрироваться/создать учетную запись».
- Убедитесь, что пользователь должен иметь возможность войти в систему с новым паролем после смены пароля
- Убедитесь, что пользователь не должен иметь возможность войти в систему со старым паролем после смены пароля
- Убедитесь, что пробелы не допускаются перед вводом каких-либо символов пароля.
- Убедитесь, что пользователь все еще находится в системе после ряда действий, таких как вход в систему, закрытие браузера и повторное открытие приложения.
- Убедитесь, что способы чтобы восстановить пароль, если пользователь забудет пароль
Нефункциональные тестовые случаи безопасности для страницы входа
- Убедитесь, что нажатие в браузере назад Кнопка после успешного выхода из системы не должна переводить пользователя в режим входа в систему
- Убедитесь, что существует ограничение на общее количество неудачных попыток входа в систему (количество недопустимых попыток должно основываться на бизнес-логике. На основе бизнес-логики пользователю будет предложено ввести капчу и повторить попытку, иначе пользователь будет заблокирован)
- Убедитесь, что пароль введен в зашифрованном виде (маскированный формат) при вводе в поле пароля.
- Убедитесь, что пароль можно скопировать и вставить. Система не должна позволять пользователям копировать и вставлять пароль.
- Убедитесь, что зашифрованные символы в поле «Пароль» не должны допускать расшифровки при копировании
- Убедитесь, что флажок «Запомнить пароль» не установлен по умолчанию (зависит от бизнес-логики, он может быть установлен или не установлен).
- Убедитесь, что форма входа не раскрывает какую-либо информацию о безопасности, просмотрев исходный код страницы.
- Убедитесь, что имя входа страница уязвима для SQL-инъекций.
- Проверьте, работает ли уязвимость межсайтового скриптинга (XSS) на странице входа. Уязвимость XSS может использоваться хакерами для обхода контроля доступа.
Тестовые примеры производительности для страницы входа
- Проверьте, сколько времени требуется приложению для загрузки домашней страницы после ввода действительного имени пользователя и пароля на странице входа.
Тестовые случаи для CAPTCHA и файлов cookie (Если есть капчу на странице входа)
- Проверьте, выполняется ли проверка на стороне клиента, когда Пользователь не вводит CAPTCHA
- Убедитесь, что ссылка обновления CAPTCHA создает новую CAPTCHA
- Убедитесь, что CAPTCHA чувствительна к регистру.
- Убедитесь, что CAPTCHA поддерживает аудио для прослушивания.
- Убедитесь, что виртуальная клавиатура доступна и правильно работает для ввода учетных данных для входа в банковские приложения.
- Проверьте двустороннюю аутентификацию с помощью OTP. работает правильно в случае банковских приложений.
- Убедитесь, что SSL-сертификат реализован или нет
Файлы cookie. Прочтите этот пост, чтобы узнать больше о тестовых примерах, связанных с тестированием файлов cookie веб-сайта - Убедитесь, что пользователь может войти в систему, когда файлы cookie браузера очищены. Когда файлы cookie удалены, система не должна позволять пользователю автоматически входить в систему.
- Проверьте функцию входа, когда файлы cookie браузера отключены.
Обязательно к прочтению: Сценарии тестирования формы регистрации
Написание тестовых сценариев для приложения требует небольшой практики. Хорошо написанный тестовый пример должен позволить любому тестировщику понять и выполнить тесты, сделать процесс тестирования более плавным и сэкономить много времени в долгосрочной перспективе. Ранее мы разместили видео о том, как писать тестовые случаи. Я завершаю этот пост «Тестовые сценарии входа в систему/Тестовые сценарии формы входа».
Нравится этот пост? Не забудьте поделиться им! Если у вас есть вопросы, оставьте комментарий ниже.
Вот несколько отобранных статей, которые вы можете прочитать следующим образом:
- Как составить хороший отчет о дефектах
- Почему вы выбрали тестирование программного обеспечения в качестве Карьера
- Подробное объяснение шаблона плана тестирования
- Тестирование веб-файлов cookie — тестовые примеры тестирования файлов cookie
TAG: qa
Тестирование — важная и неотъемлемая часть разработки, позволяющая выявить ошибки и оценить удобство использования веб-страниц.
Зачем составлять тест-кейсы, как выявить несоответствие свёрстанной страницы дизайн-макету, как протестировать юзабилити и корректность работы элементов — об этом и не только рассказывает QA-инженер компании HTDev Нурия Хусаинова. Статья будет полезна тем, кто только начинает профессиональный путь в тестировании.
QA-инженер может тестировать свёрстанные страницы вручную или с помощью программных средств.
Автоматизированный способ предотвращает риск возникновения ошибок, которые может допустить специалист при ручном тестировании, а также обеспечивает высокую скорость проверки. Однако написание кода для такой программы требует квалификации и опыта QA-инженера: чтобы автотест не пропускал ошибки, нужно прописать полный сценарий работы. Когда сценарий не выполняется, программа выводит сообщение об ошибке. Получается, что автоматизированное тестирование трудозатратно, поскольку написание автотестов может занять даже больше времени, чем полная проверка веб-страницы вручную.
Ручное тестирование — наиболее целесообразный метод проверки лендингов, который при этом не исключает использование специальных инструментов для более тщательной оценки.
Стоит учитывать, что веб-страницы преследуют разные цели, следовательно, и выглядят неодинаково. В зависимости от длины и функциональности одностраничного сайта скорость тестирования и чеклист проверки будут отличаться.
Тест-кейс ― это проверка работоспособности лендинга на предмет соответствию техническому заданию. Такие тесты позволяют увидеть результат действий пользователя и избежать возможных ошибок. Так, тест-кейс помогает узнать, что произойдёт, если пользователь введёт в форму обратной связи некорректный номер телефона или адрес электронной почты, и что произойдёт, если данные будут введены верно.
С опытом QA-инженер опирается только на техническое задание, а начинающие специалисты могут составить для себя перечень задач для проверки в таблице.
Этот этап состоит из четырёх ключевых проверок, последовательность выполнения которых не влияет на эффективность тестирования.
Сравниваем готовый лендинг и дизайн-макет
QA-инженер может сразу приступить к проверке лендинга с помощью вспомогательных инструментов или сначала выполнить визуальную сверку макета и лендинга.
Делать визуальную сверку необязательно, но опытные QA-инженеры проводят её неосознанно: когда смотрят на макет и сразу замечают несоответствия.
Что нужно тщательно проверить, когда сравнивают итоговый продукт и дизайн-макет:
- стили текста: размер, цвет, шрифт, отступы;
- расстояние между блоками;
- расположение блоков, иконок и картинок;
- меню или бургер;
- текст на предмет ошибок.
Изображения ― картинки, фотографии, иконки и логотипы — не должны быть замыленными. Как правило, то, насколько чётко выглядят графические элементы лендинга, видно невооружённым взглядом.
Для проверки цвета, стиля и кегля шрифтов обязательно нужно посмотреть код на веб-странице и сравнить его с тем, что использован в макете, — как в этом примере:
Чтобы ускорить этот процесс, дизайн-макет накладывается на веб-страницу ― например, с помощью бесплатного расширения Pixel Perfect для Google Chrome. Далее следует убедиться, что все элементы совпадают при наложении. Обычно расхождение в 1–2 пикселя багом не является.
Оцениваем корректность работы элементов лендинга
При тестировании интерфейса QA-инженер изучает, как работают графические элементы, использованные в лендинге. С каждым из них нужно совершить взаимодействие в соответствии с тест-кейсами, чтобы убедиться, что все изменённые состояния элементов отображаются корректно. При клике интерактивные элементы, например, ссылки, должны вести на соответствующие элементы.
Проверяем адаптивность и кросс-браузерность
При изменении ширины экрана элементы могут отображаться неверно — например, часть текста или изображения не будут видны пользователю. Чтобы этого избежать, QA-инженер просматривает веб-страницу на различных типах устройств, операционных системах и браузерах.
Для проверки адаптивности и функциональности лендинга можно использовать BrowserStack ― облачную платформу для тестирования сайтов и мобильных приложений. На момент выхода статьи инструмент доступен для россиян. Есть гибкие тарифные планы: например, использование сервиса без ограничений опций для одного пользователя стоит $39 в месяц.
Тестируем юзабилити
Проверка юзабилити показывает, насколько удобно использовать интерфейс, и как легко посетитель лендинга сможет достичь конечной цели. Этот процесс также поможет выявить орфографические и технические ошибки.
QA-инженер передаёт разработчику список несоответствий и ошибок со скриншотами или видеозаписью экрана, включая пошаговое описание, как появляется тот или иной баг. Если проблему описать неточно, разработчик может не понять суть ошибки и соответственно не исправит её.
Как правило, для передачи ошибок и багов в компании есть утверждённая форма, но может быть и просто комментарий в планировщике задач.
После того, как разработчики исправят баги, QA-инженер снова проводит тестирование лендинга. Для этого специалист выбирает наиболее подходящий способ повторной проверки:
- Smoke-тестирование ― «дымовой», или поверхностный тест. QA-инженер проверяет, исправлены ли баги, о которых он сообщил, и дополнительно тестирует работу основной функциональности лендинга.
- Регрессионное тестирование ― более глубокая проверка для подтверждения отсутствия багов. Такой способ помогает убедиться, что все выявленные ошибки исправлены, а новые не появились.
В нашем примере при повторной проверке использовали smoke-тестирование. После того, как QA-инженер убедился, что выявленные баги устранены, он проверил работоспособность основной функциональности: кнопки «обратный звонок», формы обратной связи, кликабельность ссылок и их соответствие содержанию, отображение информации при наведении на элементы в разделе «Направления».
- Освоите IT-профессию, для которой не требуется опыт и техническое образование
- Изучите ручное и автоматизированное тестирование, а также языки программирования Java, JavaScript и Python
- Начнёте работать через 2 месяца обучения
Не стремитесь выполнять задачу быстрее. Как и в любой профессии, опыт приходит со временем. Лучше уделить проверке больше времени и с вниманием отнестись к деталям, чем выпустить некачественный продукт, в котором пользователи обнаружат баги.
Используйте тест-кейсы. Проводить тестирование можно и без тест-кейса, но начинающим QA-инженерам он облегчит выполнение задач:
- Этапы тестирования будут структурированы ― появится наглядная картинка, что нужно протестировать.
- Отслеживание обязательных для проверки действий будет менее трудозатратным ― станет легче отслеживать, какие этапы остались без тестового покрытия, а какие прошли проверку без выявления багов и с их обнаружением.
- Новый сотрудник быстрее подключается к проекту — тест-кейсы составляют, исходя в основном из технического задания, и наглядно демонстрируют поведение функциональности лендинга.
- Регрессионное или smoke-тестирование будет проходить легче из-за наличия наглядного примера.
Запаситесь терпением и трудолюбием. Если решили тестировать без написания тест-кейсов, держите в голове план и пошагово следуйте ему. Когда вы приступаете к тестированию одного блока, не закончив его проверку, не спешите тестировать другой блок ― так возникает риск упустить что-то важное.
Не пренебрегайте повторной проверкой. Любое изменение кода может повлиять на другие части функциональности. Финальная проверка позволит убедиться, что ошибки исправлены, а новые не появились.
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
В тестировании, чтобы проверить, корректно ли работает программное обеспечение (ПО), делают определенные действия и сверяют полученный результат с ожидаемым. Другими словами — моделируют ситуацию работы ПО. Чтобы описать шаги, создают тест-кейсы.
Что такое тест-кейсы
Это четкое описание входных данных, условий и процедуры тестирования, ожидаемых результатов. Они определяют один сценарий — конкретную цель тестирования программного обеспечения. Целью может быть проверка ПО: соответствует ли оно требованиям.
Четко определенные тест-кейсы позволяют многократно запускать одни и те же тесты, применять для последовательно изменяющихся версий программного обеспечения. А еще отслеживать регрессивные ошибки ПО — то есть те, которые повторяются и ухудшают качество продукта.
Отличия
🚀 От чек-листа
В чек-листе перечисляют аспекты ПО, которые нужно проверить. Когда составляют тест-кейс, описывают состояние программного обеспечения и то, как его изменяют. То есть чек-листом определяют, что тестировать. А тест-кейсом — как тестировать. Чек-лист подойдет в качестве исходного документа, чтобы составить тест-кейсы.
🚀 От баг-репорта
Баг-репорт — это отчет об ошибке. Его составляют, когда находят ошибки в работе ПО. Тест-кейс же нужен, чтобы определить, есть ли ошибка. Он помогает составить качественный баг-репорт.
Виды тест-кейсов
Классификация зависит от типа входных данных, действий и ожидаемого поведения ПО.
1️⃣ Положительные. Подтверждают, что ПО соответствует требованиям. Показывают, что при корректных входных данных и действиях пользователя ПО выполняет функции.
2️⃣ Отрицательные. Показывают, что ПО способно обрабатывать некорректные входные данные или неверные действия пользователя. Например, выводить соответствующие сообщения, подсказывать, как исправить ситуацию.
3️⃣ Деструктивные. Демонстрируют, что никакие внешние воздействия или высокие нагрузки не приводят к потере данных пользователя, ПО можно использовать. Условие: нагрузки не разрушают аппаратную часть.
Пример
У вас есть требование к программной системе расписания занятий: «В систему нужно добавлять новые уроки».
Положительные тест-кейсы должны демонстрировать, что, если ввести корректные данные, новый урок появится в расписании.
Негативные попытаются сломать нормальную работу системы. Например, если добавляют урок, когда нет места в расписании, или не указывают его название.
Деструктивные покажут, сохранится ли расписание при сбоях. Например, если внезапно завершат программу или введут огромное количество данных за короткое время.
Жизненный цикл
У баг-репорта есть полноценный, развитый жизненный цикл. У тест-кейса — набор состояний. Они могут отличаться в зависимости от компании и возможностей систем управления тест-кейсами. Но обычно выделяют четыре состояния:
1️⃣ Не запускался. Тест-кейс создали, но тестирование по нему не проводили.
2️⃣ Пройден успешно. Ожидаемые и фактические результаты работы ПО совпадают.
3️⃣ Провален. Обнаружили дефект: ожидаемый результат минимум по одному шагу тест-кейса не совпадает с фактическим.
4️⃣ Пропущен. Тест-кейс отменили. Например, потому что изменили требования к ПО.
Обязательные атрибуты
Они тоже зависят от внутренней культуры компании или возможностей систем управления тест-кейсами. И даже от типа тестируемого ПО. Но обычно выделяют следующие атрибуты:
✅ Уникальный идентификатор — некое уникальное значение. По нему на тест-кейс ссылаются из других документов или тест-кейсов. Бывает буквенным, числовым, буквенно-числовым. Чаще всего применяют простую сквозную нумерацию.
✅ Краткое описание — лаконичное описание сути тест-кейса. Может содержать ссылку на требование к ПО.
✅ Входные данные — сведения о первоначальном состоянии системы, которое важно для тест-кейса. А еще значения для ввода или передачи ПО.
✅ Шаги — полная последовательность действий. Ее выполняют, чтобы провести описываемую тест-кейсом проверку.
✅ Ожидаемый результат — описание планируемого поведения или результата ПО. Может базироваться на требовании к программному обеспечению, общей логике работы.
✅ Фактический результат — описание итогового поведения или результата ПО. Если они совпадают, это указывают. Когда не совпадают, подробно описывают расхождения. Пометка «не совпадает», «отличается» — это грубая ошибка.
✅ Статус — текущее состояние тест-кейса.
Правила составления тест-кейса
👉 Создавайте простые тест-кейсы. То есть лаконичные и понятные не только вам. Используйте повелительное наклонение, например: «перейдите на домашнюю страницу», «введите данные», «нажмите здесь». Шаги должны быть четкие, без лишних деталей. Так проще понять шаги теста и ускорить работу.
👉 Учитывайте интересы конечного пользователя. Конечная цель любого программного проекта — простое и понятное приложение, отвечающее запросу клиентов. Тестировщик создает тест-кейсы с учетом мнения конечного пользователя.
👉 Избегайте повторов. Если тест-кейс нужен, чтобы выполнить другой тест-кейс, оставьте ссылку по идентификатору в столбце предварительного условия.
👉 Не предполагайте. Не додумывайте функциональность и возможности ПО. Строго придерживайтесь спецификации.
👉 Пишите тестовые примеры. Они должны покрывать все требования к ПО из спецификации. Используйте чек-листы и автоматизированные средства учета покрытия тестами. Это гарантия того, что ни одна функция или условие не останутся непроверенными.
👉 Задавайте идентификатор тест-кейса. Так, чтобы его было легко идентифицировать. Например, когда отслеживают ошибки или определяют требования к ПО на более позднем этапе.
👉 Внедряйте методы тестирования. Эти техники помогают спланировать несколько тест-кейсов и находить ошибки:
- анализ граничных значений — проверяйте верхние и нижние границы для допустимого диапазона значений;
- эквивалентное разделение — разбивайте диапазон всевозможных тест-кейсов на равные части/группы с одинаковым поведением;
- техника перехода состояний — создавайте тест-кейсы, которые покроют поведение ПО при переходе из одного состояния в другое.
👉 Внедряйте самоочистку. Тест-кейс должен возвращать среду в предтестовое состояние. Особенно это касается тестирования конфигураций.
👉 Создавайте повторяемые и самостоятельные текст-кейсы. Они должны всегда генерировать одинаковые результаты: независимо от того, кто их тестирует.
👉 Проводите экспертную оценку. Отправляйте текст-кейсы на проверку коллегам. Они могут обнаружить ошибки в дизайне тест-кейса, которые вы пропустили.
Учитесь создавать тест-кейсы и системы управления ими на курсе «Инженер по тестированию» Skypro. Кроме этого узнаете, как писать чек-листы и тест-планы, составлять отчеты в системах отслеживания ошибок. Проведете функциональное, UX/UI- и регрессионное тестирование — и это только в одном модуле. На курсе рассмотрим еще и тестирование мобильных приложений и API, инструменты тестировщика.
На курсе больше 330 часов теории и практики, пройдете 7 мастер-классов, создадите 4 проекта для портфолио. Доступ к материалам останется навсегда.
Инженер-тестировщик: новая работа через 9 месяцев
Получится, даже если у вас нет опыта в IT
Узнать больше
Шаблон и пример тест-кейса
| Идентификатор | Описание | Шаги | Входные данные | Ожидаемые результаты | Фактические результаты | Статус |
| TU01 | Проверка входа пользователя с существующими логином и паролем | Откройте сайт http://blahblahblah.ru
↓ Введите логин ↓ Введите пароль ↓ Нажмите кнопку «Войти» |
Логин = user99 Пароль = pass99 | Пользователь должен попасть на главную страницу | Как ожидали | Пройден успешно |
| TU02 | Проверка входа пользователя с несуществующими логином и паролем | Откройте сайт http://blahblahblah.ru
↓ Введите логин ↓ Введите пароль ↓ Нажмите кнопку «Войти» |
Логин = user99 Пароль = badlass99 | Пользователь должен остаться на странице логина. Появится сообщение «Неверные логин или пароль» | Как ожидали | Пройден успешно |
Главное о тест-кейсах
- Тест-кейс — это четкое описание входных данных, условий выполнения, процедуры тестирования и ожидаемых результатов.
- Исходным документом для тест-кейсов может быть чек-лист. Проваленный тест-кейс служит источником данных для баг-репорта.
- Обязательные атрибуты тест-кейса: уникальный идентификатор, краткое описание, входные данные. А еще шаги, ожидаемый результат, фактический результат, статус.
- От правильности написания тест-кейсов зависит качество тестирования. Создавайте простые тест-кейсы с учетом интересов конечного пользователя. Избегайте повторов и не предполагайте, пишите тестовые примеры. Внедряйте методы тестирования, самоочистку, консультируйтесь с экспертами.
Когда смотришь на специалистов по тестированию, которые пишут тест-кейсы, то понимаешь, что многие из них даже не имеют представления как это правильно делается. Я не буду приводить множество примеров, которые показывают вопиющие ошибки, а постараюсь озвучить основные принципы того, как надо писать тест-кейсы.
Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB:
Тест-кейс — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определённой цели или тестового условия, таких как выполнения определённого пути программы или же для проверки соответствия определённому требованию.
Определение тест-кейса языком обывателя:
Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.
Надеюсь, теперь многим стало понятно, что такое тест-кейс. Теперь перейдём к правилам написания тест-кейсов, которые вырабатывались не один год и показывают свою эффективность до сих пор.
Обязательные атрибуты для заполнения
- Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс.
- Заголовок — краткое, понятное и ёмкое описание сути проверки.
- Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке.
- Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки.
- Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге.
В зависимости от специфики компании могут присутствовать дополнительные атрибуты для заполнения: приоритет, функциональный блок, программа, ссылка на требование, номер требования и т.д.
Правила написания тест-кейсов
- Заголовок:
- должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
- не может содержать выполняемые шаги и ожидаемый результат.
- Предусловие:
- может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса;
- может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…);
- не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»;
- не может содержать ожидаемый результат.
- Шаги проверки:
- должны быть чёткими, понятными и последовательными;
- следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»; - должны использоваться безличные глаголы.
Правильно: нажать, ввести, перейти.
Неправильно: нажмите, введите, идите; - не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё;
- не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида.
- Ожидаемый результат:
- должен быть у каждого шага проверки;
- должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага;
- не должно быть избыточного описания.
- Общие требования к тест-кейсам:
- язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц;
- тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще);
- тест-кейсы группируются в функциональные блоки по их назначению;
- в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм.
На самом деле правила простые, однако их не так-то просто соблюдать. Если же придерживаться данных правил, то тест-кейсы будут легко поддерживаемыми, легко читаемыми, не будут вызывать отторжения и могут быть использованы всеми участниками команды в процессе разработки программного обеспечения.
Примеры
Для наглядности приведу пару примеров. Рассмотрим на примере сайта, на котором вы сейчас находитесь.
Тест-кейс №1. Корректный
| Номер | 1 |
| Заголовок | Отправка сообщения через форму обратной связи на странице “Контакты” |
| Предусловие | Открыта главная страница сайта victorz.ru. Есть доступ к почте администратора сайта victorz.ru |
| Шаг | Ожидаемый результат |
| В верхнем меню сайта нажать на ссылку “Контакты” | Открылась страница “Контакты” |
| Ввести значение в поле “Ваше имя” состоящее из латинских букв, кириллицы | В поле “Ваше имя” отображается введённое имя |
| Ввести корректный email в поле “Ваш e-mail” | В поле “Ваш e-mail” отображается введённый email |
| Ввести в поле “Тема” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел | В поле “Тема” отображается введённый текст |
| Ввести в поле “Сообщение” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел | В поле “Сообщение” отображается введённый текст |
| Ввести в поле капчи требуемое капчей значение | В поле капчи отображается введённое значение |
| Нажать под заполняемой формой на кнопку “Отправить” | Под кнопкой «Отправить» появился текст “Спасибо. Ваше сообщение было отправлено.” Все заполненные поля очищены. |
| Проверить почту администратора сайта | На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5. |
Тест-кейс №2. Некорректный
В данном тест-кейсе постарался в каждой строке писать неправильно, чтобы было наглядно. И в скобках добавлял наводящие пояснения.
| Номер | 1 |
| Заголовок | Отправить сообщение через форму обратной связи (Указываем, что проверяем или что делаем?) |
| Предусловие | Перейти на главную страницу сайта victorz.ru (Это не предусловие, а описание шага) |
| Шаг | Ожидаемый результат |
| Нажать на ссылку “Контакты” (Где она находится?) | Открылась страница (Какая?) |
| Ввести имя в поле “Ваше имя” (Какие символы вводить?) | (Ничего не указано в ожидаемом результате, что должно произойти?) |
| Ввести email в поле “Ваш e-mail” (корректный или некорректный?) | В поле отображается email (Какой? Введённый? В каком поле отображается?) |
| Ввести в поле значение, состоящее из латинских букв, кириллицы, спецсимволов и чисел (В какое поле?) | В поле “Тема” отображается текст (Какой?) |
| Ввести в поле “Сообщение” текст (Какие символы вводить?) | Видим в поле “Сообщение” введённый текст (Видим или отображается?) |
| Вводим в поле капчи требуемое капчей значение (Помните только безличные глаголы — Ввести). | В поле капчи будет введённое значение (Что будет делать? Танцевать?) |
| Нажать под заполняемой формой на кнопку (На какую?) | Появился текст “Спасибо. Ваше сообщение было отправлено.” (Где появится?) |
| (Последний шаг не заполнен, а это неправильно, так как мы не проверим действительно ли работает отправка писем через форму обратной связи) |
Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:
Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов.
Если вы будете вести тест-кейсы в таблице (к примеру в Excel), то можете скачать шаблон тест-кейсов. В файле две вкладки. На одной шаблон единичного тест-кейса, а на второй пример порядка размещения группы тест-кейсов.
Тест-кейсы по полочкам — как в библиотеке! Наводим порядок в структуре и содержании тестовой документации
Время на прочтение
5 мин
Количество просмотров 28K
Всем привет! На связи Анастасия Макеева. В Утконос Онлайн я работаю лидом автоматизации тестирования на проекте витрины. В мои обязанности входит организация и реализация автоматизированного тестирования сайта, систем и сервисов.
Свой путь в Утконосе я начинала с мануального тестирования, поэтому в этой статье хочу поделиться с вами подходом, который я применила для создания удобной структуры и информативного содержания тестовой документации.
Давным-давно…
Когда мир еще знать не знал, что такое covid.
Когда коллеги дружно работали в офисе.
Когда ходили на встречи в переговорки, а не в Teams или Zoom.
Когда обедали вместе.
Я пришла работать в Утконос.
Моими первыми задачами было:
-
Организовать структуру хранения тестовой документации
-
Распределить и отредактировать уже написанные кейсы согласно новой структуре
-
Написать большую часть недостающих кейсов
Тестовая документация касалась всех блоков, связанных с сайтом Утконос:
-
сам сайт
-
административная часть сайта
-
промо механики
-
разные категории клиентов
-
лендинги
-
интеграции со сторонними подрядчиками
Так или иначе каждый блок содержал в себе свои разделы.
А разделы — подразделы.
По предварительным расчетам общее количество написанных кейсов должно было превысить 1000.
Это большая цифра, и она означала, что с самого начала необходимо продуманно отнестись к созданию и построению удобной структуры хранения тестовой документации.
При планировании мне хотелось добиться:
-
простой и понятной структуры
-
единого стиля
-
быстрой и логичной навигации при поиске
-
удобства при сборке тест-ранов
-
легкости восприятия тест-кейсов
-
чтобы после прочтения кейса тестировщику не хотелось закрыть его и пойти кофейку попить
Структура проекта
Для создания структуры тестовой документации сайта я решила воспользоваться постраничным распределением.
Что это такое?
На нашем сайте существует много функциональностей, и проверять их удобно, если не нужно при этом перескакивать со страницы на страницу. То есть тестировщик будет выполнять все проверки, которые есть на странице, не переходя к другим проверкам. Да и искать определенный тест-кейс в этом случае более логично.
Отсюда сформировались основные блоки нашей будущей структуры:
-
главная страница
-
страница поиска
-
страница карточки товара
-
страница корзины
-
страница с акциями
-
страница чекаута
-
страница спасибо за заказ
-
страница лендинга
-
и т.д.
Далее мне хотелось, чтобы тест-кейсы на фронт и бэкенд не перемешивались. И тогда каждая страница получила по 2 раздела, которые назывались:
— Front
— Back
Но даже в одном разделе — к примеру, главной страницы — насчитывалось очень много кейсов. Хотелось какого-то логического разделения. Поэтому каждый раздел я разбила на подразделы, которые относились к какой-то отдельной функциональности или сущности.
Общие элементы, такие как хедер, добавление адреса и сайдбар (боковая корзина) можно выделить в отдельный блок, поскольку эти элементы есть на каждой странице, но можно и отнести к какой-то определенной странице. Таким образом у нас получилась такая структура для главной страницы:
Названия
Чтобы навигация по кейсам была быстрой и удобной, недостаточно создать только структуру и положить туда все тест-кейсы, названные в разнобой. Чтобы оптимизировать навигацию и сбор тест-ранов, лучше согласовать единый стиль при написании тест-кейсов между тестировщикам. Именно так мы и сделали: утвердили и зафиксировали соглашение о написании тест-кейсов, в котором одним из пунктов был описан принцип составления названия.
Мы воспользовались известной формулой:
Где? Что? Условия?
При нейминге тест-кейса необходимо было придерживаться следующих требований:
-
В начале кейса отражен территориальный признак.
-
Далее указывается суть проверки.
-
После можно указать какие-то особые условия.
-
Каждый пункт разделен между собой точкой для более легкого восприятия текста.
Сразу приведу примеры таких названий:
Ну что, догадались, о чем этот тест-кейс?
Уже идете на главную страницу utkonos.ru, чтобы
добавить товар в корзину из спецпредложений, не указав адрес в личном кабинете?)
А вот тут?
В представленных примерах мы видим, что:
-
В названии отражен территориальный признак: то есть, ГДЕ мы проверяем этот кейс.
-
Далее идет суть самой проверки, то есть, ЧТО мы проверяем в этом кейсе.
-
После чего — некие разветвления/ особые УСЛОВИЯ.
Таким образом после нескольких прохождений кейсов наши тестировщики могут легко ориентироваться только по названию, не заходя в сам кейс.
Описание
Время — самый ценный ресурс. И зачастую по причине большой загрузки, приближающихся дедлайнов или каких-то срочных задач можно не успеть написать тест-кейс. В таком случае можно остановиться на предыдущем шаге, поскольку из названия кейса можно понять, что делать.
Ну а если вы, как и я, стремитесь к идеальным тест-кейсам, тогда стоит зафиксировать важные моменты. Кстати, вторым пунктом в соглашении о написании тест-кейсов!
Как говорил мой замечательный ментор: «Тест-кейс должен быть написан так, чтобы любой человек, пришедший в компанию, сел за стол и мог его спокойно пройти без лишних вопросов.»
Количество шагов
Сколько их должно быть? 1-2-3-4-10?
Будем честны: шаги идеального тест-кейса должны стремиться к 1!
На практике хороший кейс имеет не более 3 шагов.
Стоит учитывать, что мы не говорим здесь о сценариях, которые проверяют E2E.
В шагах нужно отразить только суть самой проверки, остальное выносите в предусловия — не скупитесь!
Не ссылайтесь в шагах на другие шаги или другие тест-кейсы.
Шаг или тест-кейс, на которые вы ссылаетесь, может быть удален или отредактирован. Любой тестировщик не будет рад тому, что необходимо идти к кому-то и узнавать, как работает функционал, особенно, если это регресс, и еще немало непройденных кейсов.
Пишите в шаге только одно действие. Не надо в один шаг описывать басню о царе султане и его дочери. Если вы не хотите делать из одного шага несколько, или просто хотите значительно сократить шаги в тесте — объедините несколько повелительных предложений в одно.
Приведу пример. Допустим вы проверяете авторизацию в личном кабинете.
Было:
Открыть utkonos.ru
Кликнуть на значок личного кабинета
Ввести кпп
Ввести верный пароль
Нажать на кнопку «Вход»
Стало:
Авторизуйтесь в личном кабинете с кпп и верным паролем
Один шаг вместо пяти. Круто?
Если развернутая последовательность ваших шагов интуитивно не очень понятна, можно с первого по четвертый шаг вынести в предусловия.
Ожидаемые результаты
Теперь вспомним об ожидаемых результатах.
Не забудьте, что на одно ваше действие, может случиться несколько ожидаемых результатов. Их нужно зафиксировать в соответствии с принадлежностью шага.
Шаг:
Нажать на кнопку оформить заказ.
Ожидаемый результат:
-
Открыта страница «Спасибо за заказ».
-
Открыто окно с предложением добавить товары в заказ.
Шаг один, а ожидаемых результата два.
В те самые давние времена, когда я пришла в Утконос, у нас не было столько команд, сколько есть сейчас. Сегодня в Утконосе более 10 фича-команд, которые пилят разный функционал. В связи с этим самое верхнеуровневое разделение структуры тестовой документации строится на фича-командах, а далее уже в блоке каждой команды по принципу, описанному выше.
Еще у нас есть мобильные приложения, а также разные системы и сервисы. Они выделены отдельными проектами.
На данный момент для сайта написано более 3000 тест-кейсов.
Высшей наградой для меня была ситуация, когда я зашла почитать нужный мне тест-кейс и не могла понять, кто его писал. Стиль был очень похож на тот, который я описала, но я не помнила, чтобы когда-либо писала этот кейс. И тогда я поняла: заработало!
В данный момент все тест-кейсы, написанные по сайту, имеют удобную структуру и единый стиль написания.
В статье я говорю о сайте, но вы можете применить данный подход к любому приложению, сервису или системе, как мы и сделали в Утконосе.
Надеюсь моя статья помогла вам разложить ваши тест-кейсы по полочкам, как в библиотеке. До связи!
