Практика 1. Лабораторная работа 1. Анализ требований и классификация проверок

Цель

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

Результаты обучения

После выполнения работы обучающийся должен уметь:

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

Краткие теоретические сведения

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

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

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

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

---

Учебная система

Команда разрабатывает сервис регистрации на образовательной платформе. Аналитик подготовил исходные требования:

1. Пользователь регистрируется по имени, адресу электронной почты, паролю и возрасту.
2. Регистрироваться могут только совершеннолетние пользователи.
3. Адрес электронной почты должен быть корректным и уникальным.
4. Пароль должен быть надёжным.
5. После успешной регистрации пользователь получает сообщение об успехе.
6. При ошибке система показывает понятное сообщение.

Эти требования намеренно неполные. Их необходимо анализировать, а не дополнять скрытыми предположениями.

Организация репозитория

Создайте репозиторий со следующей структурой:

software-testing-lab-01/
├── README.md
├── docs/
│   ├── requirements-review.md
│   ├── risks.md
│   ├── checklist.md
│   └── bug-reports.md
└── evidence/
    └── README.md

В README.md укажите:

• ФИО и группу;
• название лабораторной работы;
• объект тестирования;
• перечень подготовленных материалов;
• краткий вывод.

---

Задание 1. Анализ требований

Для каждого исходного требования определите:

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

Оформите результат в docs/requirements-review.md.

Рекомендуемая таблица:

№	Требование	Проблема	Уточняющий вопрос	Вариант критерия приёмки
1	Пользователь регистрируется…	Не указаны обязательные поля	Можно ли оставить имя пустым?	Имя обязательно и содержит 2–50 символов

Не выдавайте собственный вариант за утверждённое требование. Последний столбец — предложение для обсуждения.

Минимальный результат: не менее 10 содержательных вопросов по шести требованиям.

Задание 2. Модель рисков

Определите не менее восьми рисков для регистрации. Рассмотрите:

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

Оформите docs/risks.md в виде таблицы:

Риск	Вероятность	Влияние	Приоритет проверки	Предлагаемая проверка

Используйте шкалу «низкая / средняя / высокая» и кратко объясните оценки.

Задание 3. Чек-лист функциональных проверок

Создайте docs/checklist.md. Включите не менее 25 проверок, разделённых на группы:

1. имя пользователя;
2. адрес электронной почты;
3. пароль;
4. возраст;
5. успешная регистрация;
6. обработка ошибок;
7. повторная отправка формы.

В каждой группе должны присутствовать:

• позитивные сценарии;
• негативные сценарии;
• проверки обязательности;
• проверки границ, если граница определена;
• проверки сообщений пользователю.

Не используйте пункты вида «Проверить email». Формулируйте ожидаемое наблюдаемое поведение: «Форма отклоняет адрес без доменной части и сообщает причину».

Задание 4. Классификация проверок

Выберите 15 пунктов чек-листа и для каждого укажите:

• уровень: модульный, интеграционный, системный или приёмочный;
• вид: функциональный или нефункциональный;
• характер: позитивный или негативный;
• способ: ручной или автоматизированный;
• обоснование выбора.

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

Задание 5. Отчёты о дефектах

Ниже приведены наблюдения из тестовой версии системы:

1. Пользователь 18 лет получает сообщение «Регистрация доступна только с 18 лет».
2. После двойного нажатия кнопки «Зарегистрироваться» создаются две учётные записи.
3. При вводе существующего email система показывает полный объект пользователя в техническом сообщении об ошибке.

Оформите три отчёта в docs/bug-reports.md по шаблону:

## Краткий заголовок

- Окружение:
- Предусловия:
- Серьёзность:
- Приоритет:

### Шаги воспроизведения
1. ...

### Фактический результат
...

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

### Дополнительные материалы
...

Заголовок должен описывать действие, условие и проблему. Не используйте заголовки «Ошибка регистрации» или «Не работает».

Задание 6. Итоговый вывод

В README.md ответьте на вопросы:

1. Можно ли начинать реализацию по исходным требованиям без уточнений?
2. Какие три риска требуют первоочередного тестирования?
3. Какие проверки следует автоматизировать в первую очередь?
4. Какие проверки требуют участия человека?
5. Какие сведения необходимы для определения готовности функции к выпуску?

---

Требования к сдаче

• работа предоставляется в виде ссылки на Git-репозиторий;
• все документы находятся в формате Markdown;
• история Git содержит осмысленные коммиты;
• репозиторий не содержит персональных данных, ключей и служебных файлов IDE;
• ссылки и изображения в отчёте открываются;
• формулировки проверок допускают однозначный результат «пройдено / не пройдено».

Критерии оценивания

Критерий	Вес
Анализ требований и уточняющие вопросы	20%
Модель рисков и обоснование приоритетов	15%
Полнота и проверяемость чек-листа	25%
Корректность классификации проверок	15%
Качество отчётов о дефектах	15%
Оформление репозитория и итоговый вывод	10%

Работа считается зачтённой при результате не менее 60%. Критические ошибки:

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

Вопросы для защиты

1. Почему тестирование начинается до появления исполняемого кода?
2. Чем требование отличается от критерия приёмки?
3. Почему неоднозначное требование нельзя молча трактовать удобным способом?
4. Чем чек-лист отличается от подробного тест-кейса?
5. В чём разница между позитивной и негативной проверкой?
6. На каком уровне лучше проверять минимальный допустимый возраст и почему?
7. Чем серьёзность дефекта отличается от приоритета исправления?
8. Почему создание двух аккаунтов после двойного нажатия является интеграционным риском, а не только проблемой интерфейса?
9. Какие сведения делают дефект воспроизводимым?
10. Какие проверки регистрации вы бы включили в регрессионный набор?