Скрытая угроза: проблемы с требованиями на проекте и к чему они приводят
Отсутствие требований на проекте может вызвать кучу недопониманий в команде и отставание от сроков. Какие конкретно проблемы светят вам, если требования либо описаны нечетко, либо не существуют вовсе?
Начнем с определения тестирования требований. Это процесс проверки того, насколько все требования к создаваемому продукту поняты командой-исполнителем. Требования должны быть достижимы и не противоречить друг другу. Обсуждение требований и их четкое декларирование — залог отсутствия разногласий между заказчиком и разработчиками. А это, в свою очередь, идеальный мир для тестировщика. Но ожидание и реальность сходятся далеко не всегда, и зачастую на проекте требований может не быть, или они могут быть нигде не записанными, а «сами по себе подразумевающимися» где-то в голове у тим-лида, что приводит к конфликтам и тормозит скорость работы.
В идеале каждое требование должно быть:
- Завершённым.
Все важные нюансы должны быть определены уже на старте, оставлять что-то на будущее в состоянии TBD (to be defined) нельзя.
- Непротиворечивым.
Требование не должно содержать противоречий внутри себя и не должно конфликтовать с другими требованиями.
- Корректным.
Недопустимо при написании требования полагаться на «очевидность» из разряда «сами догадаются» или «это и так понятно».
- Недвусмысленным.
Требование не должно допускать разночтений.
- Проверяемым.
Требование должно быть сформулировано так, чтобы существовали способы однозначной проверки – выполнено требование или нет.
Но жить было бы скучно, если бы все правила беспрекословно выполнялись. Да и тестировщики бы остались без работы…
Поэтому вот несколько примеров из всего разнообразия проблем, которые тянут за собой неидеальные требования, на которые какая-либо из сторон решила «подзабить»:
1. Неполнота требований.
Если что-то подразумевается лишь на словах, нет ничего удивительного, если про это забудут. Например, разработчики могут забыть добавить (или вообще не знать, что это нужно было сделать) определенный функционал, который ожидал увидеть заказчик.
2. Неоднозначность/двусмысленность требований.
Допустим, в требованиях указано, что кнопка «Сохранить» должна быть выделена цветом. Но каким именно? На выяснение этого вопроса уйдет время, а время — деньги. А может, этот вопрос и вовсе никто не станет выяснять, что станет сюрпризом для заказчика при приемке.
3. Противоречивость требований.
Представьте, что у вас есть два требования:
- Для регистрации в приложении нужно использовать номер мобильного телефона.
- Для входа в приложение пользователь должен использовать е-мэйл.
Как тестировать подобное и откуда должен взяться адрес электронной почты, если человек регистрировался на номер?
4. Изменения требований.
У разработки и рисования есть больше общего, чем кажется! Если художника попросить сдвинуть законченную картину на сантиметр влево, у него задергается глаз. Так и в создании ПО зачастую приходящие в голову заказчика гениальные и, несомненно, очень важные идеи, бывают совсем «не в тему». Переделывание всего на ходу займет много времени, которое лишним не бывает, а заказчику будет стоить денег.
Но не стоит пугаться этих сложностей. Если на вашем проекте требований нет, или с ними творится полная неразбериха, всё решаемо!
Что именно делать в таких случаях, как спасти себя и команду от головной боли, мы рассказываем и показываем на курсе «Тестирование без требований: выявление и восстановление информации о продукте».