Requirements: зачем их тестировать
Что такое “требование”?
Требование – описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения для пользователя задачи.
Важность требований:
- Позволяют понять, что и с соблюдением каких условий система должна делать;
- Предоставляют возможность оценить масштаб изменений и управлять изменениями;
- Являются основанием для формирования плана проекта ( в том числе плана тестирования);
- Помогают предотвращать или разрешать конфликтные ситуации;
- Упрощают расстановку приоритетов в наборе задач;
- Позволяют объективно оценить прогресс в разработке проекта;
Самая лучшая картинка, которая отображает проблемы в работе с требованиями, пониманием того, что необходимо сделать и результатом.
Основное место, где происходят и появляются все “косяки” – это работа с требованиями. Чем хуже была проработка на моменте сбора, анализа и тестирования требований – тем больше проблем появиться на следующих этапах процесса разработки.
Уровни требований
Бизнес требования – цель, ради которой создается продукт (для чего, какие проблемы решает, от чего получим прибыль).
Пользовательские требования – задачи, которые пользователи могут выполнять с помощью продукта.
Продуктные требования – наши функциональные (что система должна делать) и нефункциональные требования (как система должна это делать).
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Ограничения – факторы, которые ограничивают выбор способов и средств реализации продукта (Приложение должно работать в последних версиях браузеров Chrome, Firefox, Safari).
Требования к интерфейсам – особенности взаимодействия системы с другими системами (Весь трафик между браузером и сервером должен быть зашифрован (HTTPS соединение)).
Требования к данным – описывают структуры данных, описания баз данных, особенности их использования (Все данные системы должны храниться в БД под управлением СУБД MySQL).
Стадии выявления требований
Есть 4 основные стадии выявления требований:
- Выявление требования
- Первичный анализ
- Документирование требований
- Проверка
Основная сложность всего этого процесса – то, что он может занимать много времени, поскольку бизнес аналитик или другой человек, который занимается сбором и оформлением требований, может возвращаться с каждого этапа на предыдущий или на первый в зависимости от того, как была проделана работа и как все было зафиксировано и “понято”. Чем больше информации будет получено от заказчика или Product Owner, тем лучше будут описаны требования и тем лучше будет результат.
Способы выявлений требований:
- Опрос
- Наблюдение
- Изучение конкурентных продуктов
- Обсуждения и мозговые штурмы
- Прототипирование
Свойства качественных требований:
- Полнота – Все ли описано? Ничего ли не забыли?
- Однозначность – «Отчет должен загружаться быстро» → что значит «быстро»?
- Непротеречивость – Требования не должны противоречить сами себе.
- Необходимость – «Кратко, но емко»
- Осуществимость – А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?
- Тестируемость – Можно ли протестировать этот функционал?
Почему важно тестировать требования?
Для менеджера:
- Увеличивает скорость разработки;
- Раньше получают важную информацию, для принятия важных решений;
- Выше качество продукта;
Для автора требований:
- Обратная связь сразу, пока он еще в контексте;
- Дополнительная информация о рисках;
- Меньше одинаковых вопросов;
Для разработчика:
- Качественные требования, из которых понятно, что нужно сделать;
- Меньше новых требований, которые появляются уже после разработки. И меньше усилий, чтобы вписать их в систему;
Для тестировщика:
- Возможность влиять на проект в самом начале. Часто тестировщики знают, как продукт работает на самом деле и какие есть подводные камни;
- Меньше багов на этапе тестирования продукта;
- Понятнее, что должно получиться и как это проверять. Следовательно проще разрабатывать план тестирования и тестовую документацию;
Если не тестировать требования, то:
- Проблемы в требованиях найдут уже тестировщики или пользователи. Чинить такие проблемы может быть дорого, а иногда и невозможно;
- Разработчики будут тратить больше времени, пытаясь прояснить детали;
- Разработчикам придётся выкручиваться и придумывать костыли, чтобы вписать пропущенные требования в систему;
Как упростить работу с требованиями:
- Написать test cases или checklists;
- Задавать вопросы;
- Нарисовать схемы (use cases, mind map);
- Рецензирование;
Способы представления документации:
- Use-cases
- User stories
- UI mockups or Prototypes
- Спецификация
- Wiki
Очень важно при работе с требованиями так же задавать хорошие вопросы, чтобы получить на них хорошие ответы и таким образом получить больше нужной информации. Примеры хороших и плохих вопросов можно посмотреть на картинке ниже.
