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

Что такое пользовательские истории и критерии приемки?

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

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

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

Рассмотрим эти понятия на примерах. 

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

Критерии приемки для этой истории могут быть следующими:

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

Обработка крайних случаев в критериях приемки

Крайние случаи — это сценарии, возникающие на крайних значениях рабочих параметров.

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

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

• что произойдет, если пользователь введет неправильный адрес электронной почты;
• что произойдет, если истечет срок действия ссылки для сброса пароля.

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

Написание тест-кейсов для пользовательских историй

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

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

Тест-кейс для отправленного e-mail

Описание: убедитесь, что письмо для сброса пароля отправлено.

Шаги:

• Перейдите на страницу входа.
• Нажмите «Забыли пароль».
• Введите зарегистрированный адрес электронной почты.
• Нажмите «Отправить».

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

Тест-кейс для для безопасной ссылки

Описание: убедитесь, что ссылка сброса ведет на защищенную страницу.

Разместите
тендер бесплатно

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

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

Шаги:

• Откройте письмо для сброса пароля.
• Нажмите на ссылку сброса.

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

Тест-кейс для проверки сложности пароля

Описание: проверьте требования к сложности пароля.

Шаги:

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

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

Тест-кейс для подтверждения e-mail

Описание: убедитесь, что после сброса пароля было отправлено электронное письмо с подтверждением.

Шаги:

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

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

Обеспечение всестороннего охвата критериев приемки

Чтобы гарантировать всесторонний охват критериев приемки, тестировщики должны:

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

Определение количества тест-кейсов

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

Проверка тест-кейсов

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

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

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

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