Сообщений в теме: 5

[Mahmud]

Хотелось бы узнать о подводных камнях этого вида тестирования. На что обращать внимание в первую очередь? Тестирование, это по сути дела сравнение ЧТО ЕСТЬ и ЧТО ДОЛЖНО БЫТЬ... Но в этом случае нет эталона, с чем можно было бы провести сравнение... В общем, хотелось бы услышать ваше мнение!

[barancev]

Если есть самостоятельный документ, описывающий требования (функциональная спецификация), вот он и будет эталоном.

Если такового не имеется, эталоном будет мнение полномочного представителя закачика или эксперта предметной области, если явно выраженного заказчика нет.

[Green]

На мой взгляд, это два разных вопроса.
:)

1. Проверка того что есть и того что должно быть.
Здесь может помочь только тесный контакт с заказчиком.

2. Проверка того что есть на полноту и реализуемость.
В этом вопросе, говорят, могут помочь специализированные тулы, но мне сталкиваться с такими пока не приходилось. Пользовались обычным Excel файлом (точнее, аналогом Excel файла) и воображением.
B)

[Viktor]

Хотелось бы узнать о подводных камнях этого вида тестирования. На что обращать внимание в первую очередь? Тестирование, это по сути дела сравнение ЧТО ЕСТЬ и ЧТО ДОЛЖНО БЫТЬ... Но в этом случае нет эталона, с чем можно было бы провести сравнение... В общем, хотелось бы услышать ваше мнение!

Вобщем-то, действительно. Не с чем сравнивать, значит нечего и тестировать. Зачем "испытывать тех. задание"? :)
Мне кажется дальнейшая разработка - и есть испытание ТЗ :). Слава богу (многие крестятся), что оно вообще есть. :).
Хотя если под тестированием ТЗ понимать его оценку. Тогда оцените требования ТЗ, как это предлагает ГОСТ
Критерии:
1 учет потребностей заказчика;
2 соответствие потребностям заказчика;
3 тестируемость;
4 выполнимость проектирования системной архитектуры;
5 возможность эксплуатации и сопровождения.

[Mahmud]

Большое спасибо! :)

[van]

На мой взгляд тестирование ТЗ необходимо разделить на три составляющие:
1. Его структура, организация и оформление
2. Полнота, целостность, непроворечивость и т.п.
3. Его соответствие требованиям заказчика

По - поводу третьего пункта уже писали ранее, поэтому я повторяться не буду.

Относительно первого и второго пункта напишу, как это делаю я

При проверке структуры, организации, содержания и оформления ТЗ я руководствуюсь стандартом IEEE Std 830 - 1993. Очень достойный документ. Рекомендую ознакомиться и, в первую очередь тем, кто пишет ТЗ :)

Что касается полноты, целостности и т.д., то здесь лучшее средство - это непосредственное написание тестов. И не просто тестов, а используя схематичный подход с его прекрвсными критериями тестов. Данный подход подробно описан в книге Луизы Тамре. Схематичный подход позволяет не только написать прекрасные тесты, но и определить множество изъянов и недостатков в требованиях.

Также рекомендую использовать для этих целей диаграммы переходов и таблицы состояний- тоже очень эфективный метод построения тестов и тесирования ТЗ.

Желаю удачи.