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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тест-кейс для отправленного электронного письма

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

Шаги:

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

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

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

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

Шаги:

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

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

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

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

Шаги:

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

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

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

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

Шаги:

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

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

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

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

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

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

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

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

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

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

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

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