Модуль 08: Тестирование и качество в анализе — Практическое задание

Общая информация

Кейс: Система управления задачами (Task Manager) — фаза тестирования и анализа качества требований.

Цель задания: Применить знания основ тестирования, техник тест-дизайна и управления качеством требований для анализа и улучшения качества проекта.

Формат сдачи: Один PDF или документ Markdown.

Баллы: 10 баллов.

---

Задание 1: Разработка тест-кейсов (3 балла)

Для следующей User Story напишите 4 тест-кейса, применяя техники тест-дизайна.

User Story:

Как пользователь Task Manager, я могу зарегистрироваться в системе, указав email и пароль, чтобы получить доступ к управлению задачами.

Acceptance Criteria:

• Форма регистрации: email (обязательно, формат email), пароль (обязательно, 8–64 символа, содержит минимум одну цифру и одну заглавную букву), имя (обязательно, 2–100 символов)
• При успешной регистрации система возвращает 201 и создаёт нового пользователя
• При ошибке валидации система возвращает 422 с описанием каждого невалидного поля
• Email должен быть уникальным (повторная регистрация с тем же email — 409 Conflict)
• После регистрации пользователь автоматически авторизован (возвращается JWT-токен)

Требования к тест-кейсам:

№	Техника	Что тестируем
1	Boundary Value Analysis	Поле password: границы 8 и 64 символа
2	Equivalent Partitioning	Поле email: валидные и невалидные классы
3	Decision Table	Комбинация: email уже существует / пароль не соответствует правилам / все поля валидны
4	Error Path	Сервер вернул 500 — что видит пользователь? (требование не указано — предложите сами)

Формат: стандартный тест-кейс (ID, Title, Preconditions, Steps, Expected Result).

Методические указания к Заданию 1

1.1. Boundary Value Analysis для пароля

Пароль: 8–64 символа, минимум 1 цифра, 1 заглавная буква.

BVA проверяет ТОЛЬКО границы длины. Состав (цифра, заглавная) проверяется отдельно, это классы эквивалентности.

Таблица границ:

Тип границы	N-1	N	N+1	Пояснение
Нижняя (8)	7 символов	8 символов	9 символов	Проверяем, что 7 ❌, 8 ✅, 9 ✅
Верхняя (64)	63 символа	64 символа	65 символов	Проверяем, что 63 ✅, 64 ✅, 65 ❌

Важно: При тестировании границ убедитесь, что пароль всегда содержит цифру и заглавную букву (чтобы не получить ошибку по другой причине).

Пример: «ABCDef1» (7 символов, есть цифра и заглавная) — должен вернуть ошибку длины. «ABCDef12» (8 символов) — должен пройти.

Совет: В тест-кейсе укажите конкретные значения пароля, например:

• 7 символов: Abc1234 (ожидание: ошибка «минимум 8 символов»)
• 8 символов: Abc12345 (ожидание: успех)
• 9 символов: Abc123456 (ожидание: успех)
• 63 символа: сгенерировать строку длиной 63 с цифрой и заглавной
• 64 символа: сгенерировать строку длиной 64
• 65 символов: сгенерировать строку длиной 65 (ожидание: ошибка «максимум 64 символа»)

1.2. Equivalent Partitioning для email

Классы эквивалентности для email:

Класс	Пример	Ожидание	Пояснение
Валидный email	user@example.com	✅	Стандартный формат
Нет @	userexample.com	❌	Невалидный email
Нет домена после @	user@	❌	Невалидный email
Нет имени до @	@example.com	❌	Невалидный email
Спецсимволы в имени	user+tag@example.com	✅	Допустимо по RFC 5322
Email с кириллицей	пользователь@пример.рф	?	Зависит от требований (обычно ❌)
Пустая строка	""	❌	Поле обязательное
Пробелы в начале/конце	" user@example.com "	❌ или ✅	Уточнить в requirements

Совет:

• Выберите 1–2 представителя из валидного класса (✅)
• Выберите 2–3 из невалидных (❌)
• Если требование не уточняет обработку пробелов — запишите это как баг/уточнение к требованиям

1.3. Decision Table

Условия для регистрации:

Условие	Варианты
C1: Email уникален?	Да / Нет
C2: Пароль по правилам?	Да / Нет
C3: Имя валидно?	Да / Нет
C4: Email валиден?	Да / Нет

Таблица решений (сокращённая):

	C1: Email уникален	C2: Пароль ок	C3: Имя ок	C4: Email ок	Результат
1	Да	Да	Да	Да	✅ 201 Created
2	Нет	—	—	—	❌ 409 Conflict
3	—	Нет	—	—	❌ 422 Validation Error
4	—	—	Нет	—	❌ 422 Validation Error
5	—	—	—	Нет	❌ 422 Validation Error

Пояснения:

• Комбинации 2–5 покрывают все бизнес-правила. В одном тест-кейсе можно проверить несколько ошибок (например, пароль невалидный + email невалидный), но комбинация уникальности — отдельная.
• В реальном тесте можно сделать комбинацию: email уже существует + пароль не по правилам → что вернёт система? Скорее всего, 409 Conflict (email важнее), но аналитик должен уточнить это в требованиях.

Совет: Если Decision Table показывает комбинацию, которая не описана в требованиях — это баг требований (пропуск).

1.4. Error Path (500 ошибка)

Что делать: Требования не описывают поведение при 500 ошибке. Предложите разумное поведение.

Хорошее решение:

• Система возвращает 500 + JSON: {"error": "internal_server_error", "message": "Произошла ошибка. Попробуйте позже."}
• Пользователь видит: сообщение «Сервис временно недоступен» и кнопку «Повторить»
• На фронтенде: retry 3 раза с exponential backoff
• В лог: запись ошибки с traceId

Плохое решение: (которое вы должны заметить как баг)

• Пользователь видит белый экран или бесконечную загрузку
• Текст ошибки на английском в русском интерфейсе
• Показ stack trace пользователю (уязвимость!)

Совет: Error Path — лучший способ показать, что аналитик думает не только о «солнечном сценарии», но и о том, что реально происходит в production.

Баллы за Задание 1:

Критерий	Баллы	Подсказка
Boundary Value Analysis (пароль 8 и 64)	0,75	Должны быть конкретные значения N-1, N, N+1 для обеих границ
Equivalent Partitioning (email классы)	0,75	Минимум 3 класса (1 валидный + 2 невалидных)
Decision Table (комбинации условий)	0,75	Минимум 4 комбинации, включая конфликт (email существует)
Error Path (500 ошибка) + логичность	0,75	Предложено разумное поведение системы, есть альтернатива
Дополнительный балл	+0,25	Если в тест-кейсе учтены предусловия (user не авторизован, БД доступна)

---

Задание 2: Анализ качества требований (3 балла)

Дан фрагмент SRS для Task Manager. Проанализируйте его и выполните задания 2.1, 2.2, 2.3.

Фрагмент SRS:

1. Функциональные требования
1.1. Регистрация пользователя
FR-01: Система должна поддерживать регистрацию пользователей.
FR-02: Пользователь должен ввести email и пароль.
FR-03: Пароль должен быть надёжным.

1.2. Управление задачами
FR-04: Пользователь может создавать задачи.
FR-05: Пользователь может изменять задачи.
FR-06: Система должна быть быстрой.

1.3. Уведомления
FR-07: При изменении задачи отправляется уведомление.
FR-08: Уведомления приходят вовремя.

Задание 2.1 (1 балл)

Оцените каждое требование по критериям IEEE 830 (однозначность, полнота, проверяемость) по шкале 1–5. Заполните таблицу:

Требование	Однозначность (1–5)	Полнота (1–5)	Проверяемость (1–5)	Комментарий
FR-01
FR-02
FR-03
FR-04
FR-05
FR-06
FR-07
FR-08

Задание 2.2 (1 балл)

Для 3 худших требований (с наименьшей оценкой) перепишите их так, чтобы они соответствовали критериям IEEE 830 (однозначно, полно, проверяемо).

Задание 2.3 (1 балл)

Дайте рекомендации по улучшению SRS (5–10 предложений). Какие разделы отсутствуют? Какие типы требований не описаны? Какие нефункциональные требования нужно добавить?

Методические указания к Заданию 2

2.1. Как оценивать требования

Используйте шкалу:

Оценка	Однозначность	Полнота	Проверяемость
5	Единственная интерпретация	Все сценарии + ошибки	Можно написать тест-кейс
4	Почти однозначно	Почти полно, 1 пропуск	Легко проверить
3	Есть неоднозначность	Частично полно	Сложно, но можно
2	Сильная неоднозначность	Много пропусков	Почти непроверяемо
1	«Вода», нет конкретики	Почти ничего не описано	Нельзя проверить

Пример разбора FR-01 «Система должна поддерживать регистрацию пользователей»:

• Однозначность: 1 — что значит «поддерживать регистрацию»? Веб-форма? API? OAuth? Самому или через админа?
• Полнота: 2 — не сказано про email, пароль, валидацию, ошибки, дубликаты
• Проверяемость: 1 — «поддерживает» — это проверяется? Как?

Пример разбора FR-06 «Система должна быть быстрой»:

• Однозначность: 1 — «быстрая» относительно чего? Для кого?
• Полнота: 1 — нет метрик, нет условий
• Проверяемость: 1 — «быстрая» — субъективно. Один скажет «быстро», другой «тормозит»

2.2. Как переписывать требования

Плохое требование: «Система должна быть быстрой.» Хорошее: «Время загрузки страницы списка задач не должно превышать 2 секунд для 90% запросов при одновременной работе 100 пользователей. Время отклика API (P95) — не более 500 мс.»

Плохое требование: «Пароль должен быть надёжным.» Хорошее: «Пароль должен содержать минимум 8 символов, максимум 64 символа, включать минимум одну цифру (0-9) и одну заглавную букву (A-Z). При нарушении — ошибка с описанием каждого невыполненного правила.»

Шаблон хорошего требования:

[Роль/Система] должен/должна [действие] при [условие] с результатом [ожидаемый результат].
Exception: [что при ошибке].

2.3. Какие разделы отсутствуют в SRS

Отсутствующий раздел	Почему нужен
НФТ (производительность)	FR-06 «быстрая» — нужно заменить на конкретные метрики
НФТ (безопасность)	Не сказано про аутентификацию (JWT?), роли (кто создаёт задачи?), шифрование паролей
НФТ (доступность)	SLA не указан. Сколько должна работать без отказа?
Граничные условия	Что если 1 млн задач? База данных выдержит?
Ошибки и исключения	Ни одно требование не описывает Error Path
Acceptance Criteria	Нет ни одного критерия приёмки
Трассировка	Нет ID источника требований

---

Задание 3: Инспекция требований (2,5 балла)

Проведите виртуальную инспекцию требований (Inspection).

Инспектируемый фрагмент:

FR-10: Удаление задачи
Пользователь может удалить задачу. Задача удаляется безвозвратно.

Задание 3.1 (0,5 балла)

Какие роли нужны для инспекции? Перечислите и укажите, какую роль будете играть вы (аналитик).

Задание 3.2 (1 балл)

Примените чек-лист review (урок 08.03). Найдите минимум 5 проблем в этом требовании. Оформите таблицу:

№	Проблема	Тип (IEEE 830)	Как исправить
1
2	...

Задание 3.3 (1 балл)

Напишите исправленную версию требования FR-10 с Acceptance Criteria (4–7 пунктов).

Методические указания к Заданию 3

3.1. Роли в инспекции

Роль	Кто	Что делает
Author	Автор требования	Предоставляет материал, отвечает на вопросы
Moderator	Старший аналитик / Scrum Master	Планирует, ведёт встречу, следит за правилами
Inspector	Разработчик, тестировщик, аналитик	Ищет дефекты по чек-листу
Scribe	Может совпадать с модератором	Записывает замечания

Ваш выбор: Вы — аналитик. Наиболее вероятная роль: Inspector (если не вы автор) или Author (если вы написали требование). В учебном задании вы можете выбрать любую роль.

3.2. Что искать в FR-10

Подсказки по проблемам:

Категория	Вопросы
Роль/актёр	Кто именно может удалять? Только автор? Администратор? Менеджер проекта? Исполнитель?
Безопасность	Нет аутентификации. Что если пользователь не авторизован?
Статусы	Можно удалять задачу в любом статусе? В Done? В Blocked? А если задача в работе у исполнителя?
Каскадное удаление	Что происходит с комментариями? Вложениями? Ссылками из других задач?
Подтверждение	Нужно ли подтверждение удаления? (В требовании не сказано — разработчик может сделать без подтверждения)
Аудит	Нужно ли логировать удаление? Кто удалил, когда, какую задачу?
Ошибки	Что если сеть упала? База недоступна? Задача не найдена?
Бизнес-правила	Есть ли ограничение по времени: нельзя удалять задачу, если она была выполнена более 30 дней назад?
Восстановление	«Безвозвратно» — это точно нужно бизнесу? Может, мягкое удаление (is_deleted)?

Ожидаемый список проблем (минимум 5):

1. Не указана роль (кто может удалять?) → нарушение Complete
2. Нет аутентификации (любой может удалить?) → нарушение Correct (и безопасность)
3. Не указано каскадное удаление (комментарии, вложения) → нарушение Complete
4. Нет Error Path (что если задача не найдена? 404?) → нарушение Complete
5. «Безвозвратно» — может не соответствовать бизнесу (нужно soft delete?) → нарушение Correct
6. Нет ограничения по статусу (можно удалить задачу в работе?) → нарушение Complete
7. Нет подтверждения (UI) → нарушение Complete (Usability)
8. Нет аудита (кто, когда удалил?) → нарушение Traceable

3.3. Исправленная версия FR-10

Шаблон исправленной версии:

FR-10: Удаление задачи (исправленная версия)

Описание:
  Авторизованный пользователь может удалить задачу, автором которой он является,
  если задача находится в статусе "To Do" или "Blocked". Задача помечается как удалённая
  (soft delete) и не отображается в списке задач, но доступна администратору в течение 30 дней.

Acceptance Criteria:
  1. Пользователь авторизован и является автором задачи → кнопка "Удалить" активна
  2. Пользователь нажимает "Удалить" → появляется диалог подтверждения
  3. Пользователь подтверждает → задача помечается is_deleted=true, комментарии также помечаются
  4. Задача не отображается в списке задач ни у кого
  5. Если задача в статусе "Done" или "In Progress" → кнопка "Удалить" неактивна
  6. Если пользователь не авторизован → 401 Unauthorized
  7. Если задача не найдена → 404 Not Found
  8. Если пользователь не является автором → 403 Forbidden
  9. Все действия логируются (user_id, task_id, timestamp)
 10. Администратор может восстановить задачу в течение 30 дней

---

Задание 4: Метрики и интерпретация (1,5 балла)

Даны следующие данные по проекту Task Manager:

Метрика	Значение
Всего требований	75
Дефектов в требованиях (найдено при review)	12
Дефектов в требованиях (пропущено, найдено при разработке)	3
Требований, покрытых тест-кейсами	60
Требований изменено за месяц	5 из 75
Слов-паразитов в SRS («быстро», «удобно», «достаточно»)	7

Задание 4.1 (0,75 балла)

Посчитайте метрики:

1. Плотность дефектов в требованиях = (дефекты при review + дефекты при разработке) / всего требований
2. Покрытие требований тестами = покрытые / всего × 100%
3. Стабильность требований = (всего — изменено) / всего × 100%
4. Эффективность review = дефекты при review / (дефекты при review + дефекты при разработке) × 100%

Задание 4.2 (0,75 балла)

Интерпретируйте результаты:

• Какая метрика в норме, какая — ниже нормы?
• Что нужно улучшить?
• Какая метрика самая критичная? Почему?

Нормативные значения (из урока 08.03):

• Плотность дефектов: < 0.1
• Покрытие тестами: > 90%
• Стабильность: > 80%
• Эффективность review: > 70%

Методические указания к Заданию 4

4.1. Расчёт метрик

Метрика	Формула	Расчёт	Значение
Плотность дефектов	(review + dev) / total	(12 + 3) / 75	0.2
Покрытие тестами	covered / total × 100%	60 / 75 × 100%	80%
Стабильность	(total — changed) / total × 100%	(75 — 5) / 75 × 100%	93.3%
Эффективность review	review / (review + dev) × 100%	12 / (12 + 3) × 100%	80%

4.2. Интерпретация результатов

Плотность дефектов: 0.2 — ПЛОХО (норма < 0.1)

Что это значит: На каждые 10 требований приходится 2 дефекта. Это вдвое выше нормы.

Рекомендации:

• Усилить review требований (проводить Fagan Inspection, а не только Walkthrough)
• Добавить чек-листы для самопроверки аналитика перед review
• Провести обучение команды по написанию качественных требований
• Внедрить шаблон User Story с обязательными полями (Preconditions, Error Path, Acceptance Criteria)

Покрытие тестами: 80% — НИЖЕ НОРМЫ (норма > 90%)

Что это значит: 15 из 75 требований не покрыты тестами. Это риск: эти 15 требований могут работать неправильно, и мы узнаем об этом только в production.

Рекомендации:

• Провести mapping требований → тест-кейсы
• Для uncovered требований: написать тесты или обосновать, почему они не тестируются (например, «не тестируется, потому что будет удалено в следующем спринте»)
• Договориться с QA: каждое новое требование принимается в разработку только с тест-кейсами

Стабильность: 93.3% — ОТЛИЧНО (норма > 80%)

Что это значит: Требования стабильны. За месяц изменилось только 5 из 75 (6.7%). Это говорит о хорошем сборе требований на старте проекта.

Рекомендации: Поддерживать текущий уровень. Продолжить согласование требований до начала разработки.

Эффективность review: 80% — ХОРОШО (норма > 70%)

Что это значит: 80% дефектов найдено на review, 20% (3 дефекта) «протекли» в разработку. Это приемлемо, но есть потенциал для улучшения.

Рекомендации:

• Провести пост-мортем по 3 пропущенным дефектам: почему их пропустили? Как не пропустить в следующий раз?
• Обновить чек-лист review — добавить пункты, которые пропустили

4.3. Какая метрика самая критичная?

Самая критичная: Плотность дефектов (0.2).

Почему:

• Высокая плотность дефектов означает, что требования плохо сформулированы
• Каждый дефект требований превращается в N часов переделки кода (эффект множителя: 1 дефект в требованиях = 5–10 часов лишней работы разработчика)
• Если не снизить плотность сейчас, проект будет накапливать технический долг экспоненциально

Вторая по критичности: Покрытие тестами (80%).

• 15 непокрытых требований = 15 зон риска
• Если среди них есть критическая функциональность — риск срыва релиза

4.4. Общий вывод по проекту

Сильные стороны:

• Стабильность требований (93.3%) — отлично, проект не «плывёт» в требованиях
• Эффективность review (80%) — хороший показатель, большинство дефектов находится вовремя

Слабые стороны:

• Плотность дефектов (0.2) — вдвое выше нормы, требует немедленного улучшения
• Покрытие тестами (80%) — ниже нормы, требует доработки

План первоочередных действий:

1. Провести Fagan Inspection для требований с наибольшим количеством дефектов
2. Обновить чек-лист review
3. Довести покрытие тестами до 90%+
4. Провести пост-мортем по пропущенным дефектам

---

Критерии оценки (суммарно)

Задание	Баллы
Задание 1: Тест-кейсы (4 шт)	3,0
Задание 2: Анализ качества требований	3,0
Задание 3: Инспекция требований	2,5
Задание 4: Метрики	1,5
Итого	10,0

Шкала оценивания:

• 9–10 баллов: Отлично
• 7–8 баллов: Хорошо
• 5–6 баллов: Удовлетворительно
• 0–4 балла: Требуется доработка

---

Требования к оформлению

1. Формат: Markdown или PDF
2. Тест-кейсы: Полные, с предусловиями и шагами. Каждый тест-кейс содержит: ID, Title, Preconditions, Test Data, Steps, Expected Result
3. Decision Table: В виде таблицы (минимум 4 комбинации)
4. Метрики: С формулой, расчётом, значением и интерпретацией
5. Именование файла: Модуль08_ФамилияИО.md или .pdf

---

Советы для успешного выполнения

Задание 1 (Тест-кейсы)

• Для BVA пароля: проверьте 7 символов (ошибка), 8 символов (ок), 63 символа (ок), 64 символа (ок), 65 символов (ошибка)
• Для Decision Table: три условия — email уникален (да/нет), пароль по правилам (да/нет), имя заполнено (да/нет) = 8 комбинаций. Можно сократить до 4, выделив главное условие (уникальность email)
• Error Path 500 — предложите поведение: «Система показывает "Произошла ошибка. Попробуйте позже" + кнопка "Повторить"» — это хорошо. «Белый экран» — плохо
• В Preconditions укажите: «Пользователь не авторизован (или авторизован, если тест требует токена)», «Система доступна»
• В Test Data укажите конкретные значения

Задание 2 (Анализ качества)

• FR-01: слишком общее — что значит «поддерживать регистрацию»?
• FR-03: «надёжный» — непроверяемо (1 балл по проверяемости)
• FR-06: «быстрая» — непроверяемо (1 балл)
• FR-08: «вовремя» — сколько миллисекунд?
• Используйте шкалу честно: если требование — «вода», ставьте 1
• В рекомендациях укажите: добавить раздел НФТ, добавить Acceptance Criteria, добавить Error Path для каждого требования

Задание 3 (Инспекция)

• Используйте 7 критериев IEEE 830 как чек-лист
• Проверьте: ID уникален? Атомарно? Кто актёр? Есть ли Action?
• Подумайте про безопасность: кто может удалять?
• Подумайте про бизнес-логику: все ли статусы разрешают удаление?
• В исправленной версии обязательно опишите: роли, статусы, каскадное удаление, аудит, ошибки

Задание 4 (Метрики)

• Плотность дефектов: (12+3)/75 = 0.2 — выше нормы (>0.1)
• Эффективность review: 12/(12+3) = 80% — неплохо, но можно улучшить до 90%
• Покрытие: 60/75 = 80% — ниже 90%, нужно улучшать
• Стабильность: (75-5)/75 = 93.3% — отлично, выше нормы (80%)
• В интерпретации: не просто констатируйте «норма/не норма», а предлагайте конкретные действия
• Самая критичная метрика — плотность дефектов (0.2). Обоснуйте: каждый пропущенный дефект в требованиях превращается в 5–10 часов переделки в разработке