Страница 1 из 1

Тестирование требований к ПО

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

СообщениеДобавлено: 06 окт 2008, 11:55
wishaway
Приходилось, но не полноценно, а только частично. У меня это проходило как инспекция SRS.

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

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

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

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

СообщениеДобавлено: 28 янв 2009, 15:23
BrainStorm
Вообще самое эффективное тестирование требований наступает тогда, когда начинаешь покрывать их тестами. Вот тогда и проявляется весь маразм некоторых требований.

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

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