Форум QAClub.com.ua

Многие знают о том, что самые дешевые баги - это баги, найденные в требованиях к продукту до начала имплементации, а еще лучше - до разработки архитектуры приложения.
А приходилось ли кому-то выполнять тестирование требований как отдельную задачу? Какие есть рекомендации по организации этого процесса?

Приходилось, но не полноценно, а только частично. У меня это проходило как инспекция SRS.

Основной целью было:
1) Выявить неоднозначно трактуемые требования
2) Выявить, чего не хватает в требованиях
3) Выявить возможную несостыковку разных требований друг с другом
4) Определить реализуемость требований (иногда сразу пишут, а потом понимают в процессе, что полность это сделать не реально)
ну и т.п.

Проходило это все как обычная инспекция... участников было 3-4. Ну а дальше стандартно: планирование - подготовка - проведение инспекции - фиксация деффектов - исправление. И потом все сначала, но с уже обновленными требованиями

Времени это занимает не много, у нас это было где-то час на подготовку, и 1-2 часа на инспекцию.

Более быстрый и экономный вариант - обычное review или walkthrough, что иногда тоже бывает очень полезным (и не только для SRS).

Вообще самое эффективное тестирование требований наступает тогда, когда начинаешь покрывать их тестами. Вот тогда и проявляется весь маразм некоторых требований.

Иногда на этапе ревью кажется, что да, это требование тестируемо, все ОК. Но начинаешь писать тесткейсы и понимаешь, что требование либо не так должно звучать, либо его вообще быть не должно/должно идти как пояснение к одному из других требований.

С тестированием требований не сталкивалась, потому что при их появлении на нашей фирме все пункты обсудились с программерами и геймдизами. В итоге остались те, которые соответствуют нашим разработкам и движку. А при появлении обновленной версии требований, новые пункты также обсуждаются и принимается решение, вносить их в наши требования или забить на них.