Требования на проекте — странный предмет: вроде бы есть, а вроде их нет
Вы заметили, что в вашей команде по тестированию есть некие “понятия”, которые вроде бы как подходят для того, чтобы стать требованиями, но нигде не записаны? На вопросы о четких требованиях коллеги отвечают: “Это же и так очевидно”? Вы уже начинаете подозревать, что причина проблем, недопониманий, разногласий и отставания от сроков вполне может скрываться в том, что требования на проекте не прописаны?
Сегодня поговорим о подобных случаях и о том, что с этим делать. Виктория Соковикова, тренер курса Тестирование без требований, ответит на реальные вопросы студентов и расскажет, что лучше предпринять.
Вопрос:
— Добрый день! Подскажите, как быть: периодически, особенно если предстоит новая разработка, нам присылают требования к данным и компонентам. Но глобально прописанных требований нет. Считать ли такое покрытие достаточным? Ответ “да” не совсем подходит, потому что частично требования есть. “Нет” тоже не подходит, так как часть требований отсутствует.
Также обнаружились старые спецификации (реально старые, примерно 20-летней давности). Они достаточно четко описывают многие взаимодействия, сущности (даже UI), но не всегда релевантны текущему положению вещей. Хотя, честно признаюсь, основа не изменилась за эти годы, логически многое осталось таким же.
Как тут считать, есть требования или нет?
И вот еще один, пожалуй, философский вопрос. Можно ли говорить, что требование есть, если оно нигде не записано? Но все в команде понимают, что есть определенное взаимодействие, например, с внешними системами. Все понимают, что система должна работать определенным образом с FTP, но нигде не записана конкретика, потому что, цитирую, «взаимодействие очевидное».
Отвечает тренер курса Виктория Соковикова:
— Добрый вечер! Краткий ответ на вопрос: нет. Если что-то не описано, этого нет 🙂
По оценке покрытия предлагаю общий подход — исходить из конечной цели. После того, как мы выявили недостающие требования, мы принимаем решение об их восстановлении. И, соответственно, если требования есть в достаточном объеме, то мы их из плана выявления исключаем.
Поэтому если вы считаете, что того объема, что есть, достаточно, и ничего дополнительно выявлять не нужно, то «да».
Если есть какие-то белые пятна, лучше ответить «нет», приоритизировать, включить в план и потом уже разбираться, много ли надо восстанавливать.
Вопрос:
— На моем проекте довольно много разрозненной информации о продукте. Часть требований присутствует, но также отсутствуют некоторые разделы. Если составлять вопросы для выявления недостающей информации, то их может оказаться не 10, а даже 100 или 1000 🙂
Для себя определила такой алгоритм: взять сферы, которые нужно документировать (по приоритетам), прописать несколько вопросов для каждой из сфер. Также пересмотреть сферы требований, которые описаны, на предмет неполноты/неоднозначности/непроверяемости.
Как правильно составить вопрос, если одной из сфер требований просто не существует?
Ответ:
— Если сферы не существует, лучше всего действовать в 2 этапа:
1. В свободной форме (можно даже в личке в мессенджере) спросить менеджера или другого ответственного за проект/продукт сотрудника, почему нет данного типа требований.
2. Если менеджер скажет, что так исторически сложилось, или он не в курсе, нужны ли вообще эти требования, собрать встречу с командой, рассказать про данный тип требований, какие плюсы от их документирования (или риски при отсутствии документирования), и совместно принять решение, будете ли восстанавливать и в каком объеме.
Правильная работа с требованиями позволит вашей команде успевать по срокам и снизит процент пропущенных ошибок. Погрузиться в тему подробнее и выявить слабые места в вашем собственном проекте поможет курс Тестирование без требований: выявление и восстановление информации о продукте.
Старт 22 августа!
Больше всего наших коллег, работающих над обучающими курсами для тестировщиков, радует обратная связь от студентов. Приятно видеть, когда уже первое занятие приносит пользу, как, например, было у студентки курса Екатерины:
