Тестирование требований. Лекция 1

1. Тестирование требований. Лекция 1

2. Что такое требования и зачем их тестировать

Определение требований:
Бизнес-требования – цели, которых хочет достичь заказчик или бизнес
Пользовательские требования – то, что должен уметь продукт с точки зрения
конечного пользователя
Системные (функциональные и нефункциональные) – описание того, как
система должна работать: функции, интерфейсы, ограничения,
производительность и т.д.
Почему важно тестировать требования:
Ошибки, найденные на раннем этапе, дешевле всего исправить
Чёткие требования = меньше недопонимания в команде
Хорошие требования → качественные тесты → меньше дефектов в
продакшене

3. Примеры плохих и хороших требований

❌ Плохие требования:
«Система должна работать быстро»
«Приложение должно быть удобным»
«Добавить корзину для товаров»
«Сайт должен быть красивым»
✅ Хорошие требования:
«Страница должна загружаться не более чем за 2 секунды при 1000 одновременных
пользователей»
«Новый пользователь должен иметь возможность зарегистрироваться за 3 шага (ввод
email, пароль, подтверждение)»
«Пользователь должен иметь возможность добавить товар в корзину и оформить заказ с
выбором способа оплаты и доставки»
«На сайте должны использоваться корпоративные цвета компании: #0055FF и #FFAA00»

4. Мини-интерактив: «Плохое → Хорошее требование»

Исходные (плохие) требования:
«Приложение должно работать без ошибок»
«Система должна поддерживать много пользователей»
«Интерфейс должен быть удобным»
«Кнопка должна быть заметной»
«Регистрация должна быть быстрой»
Пример ответа:
❌ «Приложение должно работать без ошибок»
✅ «При вводе корректных данных система не должна выдавать сообщения
об ошибках и должна сохранять результат в базе данных»

5. Мини-интерактив: «Плохое → Хорошее требование»

Исходные (плохие) требования
Правильные, полные требования:
❌ «Приложение должно работать без ошибок»
✅ «При вводе корректных
данных система должна сохранять информацию в базе без ошибок и показывать
подтверждение пользователю»
❌ «Система должна поддерживать много пользователей»
✅ «Система
должна поддерживать одновременную работу не менее 500 пользователей без
снижения производительности (среднее время ответа ≤ 2 секунд)»
❌ «Интерфейс должен быть удобным»
✅ «Интерфейс должен содержать не
более 5 элементов управления на одном экране и обеспечивать выполнение
ключевого действия за ≤ 3 клика»
❌«Кнопка должна быть заметной»
✅ «Кнопка “Отправить” должна иметь цвет
#007BFF, размер не менее 44×44 px и находиться в верхней части формы»
❌«Регистрация должна быть быстрой»
✅ «Процесс регистрации нового
пользователя должен занимать не более 1 минуты при стандартной скорости
ввода данных»

6. Виды требований

1. Бизнес-требования
Зачем создаётся продукт, какую бизнес-ценность приносит
Отражают цели заказчика и компании
2. Функциональные требования
Что система должна делать
Конкретные функции, процессы, сценарии
3. Нефункциональные требования
Как система должна работать
Ограничения и качества: скорость, надёжность, удобство, безопасность

7. Примеры требований

Сфера
Бизнес-требование
Функциональное
требование
Нефункциональное
требование
Интернет-магазин
Увеличить онлайнпродажи на 15%
Пользователь может
добавить товар в
корзину
Страница каталога
должна загружаться
≤ 3 сек
Банк
Снизить затраты на
обслуживание
клиентов
Клиент может
перевести деньги
через мобильное
приложение
Доступность
сервиса 99,9% в
месяц
Соцсеть
Увеличить
количество активных
пользователей
Пользователь может
публиковать пост с
фото
Фото не должны
занимать > 5 Мб
Госуслуги
Сократить очереди в Пользователь может
МФЦ на 30%
подать заявку на
паспорт онлайн
Сайт должен
поддерживать 50 000
одновременных
сессий

8. Задание

К какому виду относится требование?
Варианты требований:
“Сервис должен поддерживать не менее 10 000 пользователей
одновременно”
“Клиент может оформить заказ на доставку через мобильное
приложение”
“Увеличить количество пользователей приложения на 25% за первый год”
“Заявка на кредит должна обрабатываться не дольше 5 секунд”
“Пользователь может изменить пароль через личный кабинет”

9. Качество требований

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

10. Интерактив: «Хорошее или плохое требование?»

Перед вами примеры требований. Нужно определить, какие из них хорошие
(понятные и тестируемые), а какие плохие
Определите, какие требования корректные:
«Сайт должен открываться быстро»
«Кнопка „Отправить“ должна быть красного цвета и находиться справа от
поля ввода»
«Система должна быть удобной для пользователя»
«Пароль должен содержать минимум 10 символов, включая хотя бы одну
цифру и одну букву»
«Приложение должно поддерживать работу при 500 одновременных
пользователях без ошибок»

11. Интерактив 2: «Найди подвох»

Какие проблемы могут быть с этими требованиями?
«Форма регистрации должна быть простой и интуитивно понятной»
«Приложение должно корректно работать на всех мобильных устройствах»
«Сайт должен поддерживать современный браузер»
«После нажатия кнопки „Заказать“ клиент должен быстро получить
подтверждение»
«Система должна быть безопасной»

12. Ошибки в требованиях и их последствия

80% дефектов появляются ещё
на этапе требований
Чем раньше обнаружена
ошибка, тем дешевле её
исправить
Исправление ошибки на этапе
разработки в 10 раз дороже, чем
на этапе требований
На этапе эксплуатации — в 100
раз дороже

13. Роль тестировщика на этапе работы с требованиями

Основные задачи тестировщика:
Проверять требования на ясность и полноту
Задавать вопросы бизнес-аналитику / заказчику
Находить неясности, противоречия, двусмысленности
Предлагать уточнения в формулировки
Помогать команде понять: «А как мы это будем проверять?»

14. Викторина «Хорошее требование или нет?»

1.
Требование: «Сайт должен открываться быстро»
2.
Требование: «Приложение должно работать на Windows 11»
3.
Требование: «Кнопка должна быть красивой»
4.
Требование: «Система должна сохранять пароль в зашифрованном виде»
5.
Если в требовании есть двусмысленность, тестировщик должен уточнить её
6.
Требование: «Программа должна быть удобной»
7.
Требование: «Сайт должен обрабатывать до 10 000 запросов в минуту»
8.
Если требование неполное, можно всё равно тестировать по-своему
9.
Требование: «Приложение должно открываться за ≤ 3 секунд»
10.
Если требование непонятно, это нормально, главное — протестировать функционал
11.
Требование: «Приложение должно запускаться на Android 12 и выше»
12.
Требование: «Приложение должно быть быстрым»
13.
Требование: «Система должна сохранять данные пользователя каждые 5 минут»
14.
Если в требовании указано «до 5 секунд», оно считается конкретным
15.
Требование: «Пользователь должен авторизоваться через email и пароль»
16.
Требование: «Программа должна работать одинаково на всех устройствах»

15. Тестирование требований. Лекция 2

16. Повторение

Зачем тестировать требования
Типичные ошибки в требованиях

17. Подходы к тестированию требований

Ручное тестирование:
Review (индивидуальная проверка)
Peer review (проверка коллегой)
Инспекции (формальная проверка в группе)
Чек-листы:
Однозначность
Полнота
Отсутствие противоречий
Тестируемость
Вопросы к требованиям:
«Что будет, если…?»
Ограничения и исключения
Ответственность системы и пользователя
Как проверить требование

18. Методы анализа требований

Анализ на полноту
Все функции и сценарии учтены
Нет «дырок»
Анализ на непротиворечивость
Нет противоречий в самих требованиях
Нет конфликтов с другими документами
Анализ на реализуемость
Возможность реализации с учётом технологий, бюджета и сроков
Анализ на тестируемость
Требование можно проверить на практике
Есть чёткие критерии приёмки

19. Найди проблемы в требованиях

Требования к системе интернет-магазина:
Пользователь должен иметь возможность зарегистрироваться на сайте
Пароль должен содержать не менее 6 символов
В другом разделе документа указано: «Пароль должен быть не короче 8 символов»
Заказ должен оформляться максимально удобно
Система должна обрабатывать 10 000 заказов в секунду
Если интернет отсутствует, то заказ всё равно должен оформляться
При успешной оплате заказ сохраняется в базе данных
Разберите эти требования по четырём методам анализа:
Полнота
Непротиворечивость
Реализуемость
Тестируемость

20. Пример правильного разбора

Полнота:
Не описано, что происходит при неуспешной оплате
Не указан процесс восстановления пароля
Неясно, что значит «оформить заказ» — какие шаги входят в процесс
Непротиворечивость:
В одном месте сказано «пароль ≥ 6 символов», в другом — «пароль ≥ 8 символов»
Реализуемость:
Требование обрабатывать 10 000 заказов в секунду может быть невыполнимо для
инфраструктуры
Оформление заказа без интернета технически невозможно (противоречит
здравому смыслу)
Тестируемость:
«Оформление должно быть максимально удобным» — нельзя протестировать, так как это
субъективная формулировка
Нужно конкретизировать: например, «оформление заказа должно занимать не более 3
шагов»

21. Формальные и неформальные техники работы с требованиями

Brainstorm / обсуждение с командой
Use case, user story review
Прототипирование
Диаграммы и модели (UML, BPMN)

22. Кейс: Авторизация в интернет-магазине

Описание (требования):
Пользователь должен иметь возможность войти
в систему по логину и паролю
Если данных нет в системе — должна быть
ошибка
Должна быть возможность зарегистрироваться
Должна быть возможность восстановить пароль
Задание:
Посмотреть на прототип
Найти несоответствия требованиям
Сформулировать вопросы к аналитику /
заказчику

23. Ошибки / недочёты в требованиях

Кнопки «Войти» и «Регистрация» описаны неочевидно
Не указано, какой именно логин: e-mail, телефон, или любое поле?
Нет информации о требованиях к паролю (минимальная длина, сложность)
Не описано, что будет после успешного входа (куда попадает пользователь?)
Восстановление пароля — через e-mail? телефон? SMS?
Нет упоминания о многоразовом входе (чекбокс «Запомнить меня»)

24. Практические способы тестирования требований

Чек-листы качества требований
(например, SMART-критерии)
Создание тест-кейсов на основе требований
(ранний тест-дизайн)
Трассировка требований
(Requirement Traceability Matrix, RTM)

25. Роли в тестировании требований

Тестировщик — первый фильтр
Разработчик — смотрит на реализуемость
Аналитик — отвечает за корректность и полноту
Заказчик — проверяет ценность и бизнес-смысл
Взаимодействие и обратная связь внутри команды

26. Заключение

Ошибки в требованиях дешевле найти на старте
Тестирование требований = формальные + неформальные
методы
Основа для качественного тест-дизайна

27. Спасибо за внимание!