Тестирование тех. заданий. Кто стакивался?
#1
Отправлено 06 октября 2004 - 07:49
#2
Отправлено 06 октября 2004 - 08:48
Если такового не имеется, эталоном будет мнение полномочного представителя закачика или эксперта предметной области, если явно выраженного заказчика нет.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#3
Отправлено 06 октября 2004 - 08:52
:)
1. Проверка того что есть и того что должно быть.
Здесь может помочь только тесный контакт с заказчиком.
2. Проверка того что есть на полноту и реализуемость.
В этом вопросе, говорят, могут помочь специализированные тулы, но мне сталкиваться с такими пока не приходилось. Пользовались обычным Excel файлом (точнее, аналогом Excel файла) и воображением.
B)
#4
Отправлено 06 октября 2004 - 09:52
Вобщем-то, действительно. Не с чем сравнивать, значит нечего и тестировать. Зачем "испытывать тех. задание"? :)Хотелось бы узнать о подводных камнях этого вида тестирования. На что обращать внимание в первую очередь? Тестирование, это по сути дела сравнение ЧТО ЕСТЬ и ЧТО ДОЛЖНО БЫТЬ... Но в этом случае нет эталона, с чем можно было бы провести сравнение... В общем, хотелось бы услышать ваше мнение!
Мне кажется дальнейшая разработка - и есть испытание ТЗ :). Слава богу (многие крестятся), что оно вообще есть. :).
Хотя если под тестированием ТЗ понимать его оценку. Тогда оцените требования ТЗ, как это предлагает ГОСТ
Критерии:
1 учет потребностей заказчика;
2 соответствие потребностям заказчика;
3 тестируемость;
4 выполнимость проектирования системной архитектуры;
5 возможность эксплуатации и сопровождения.
Нельзя обсуждать здесь ересь, если только мы не размышляем, как ее уничтожить.
#5
Отправлено 06 октября 2004 - 11:15
#6
Отправлено 08 октября 2004 - 06:00
1. Его структура, организация и оформление
2. Полнота, целостность, непроворечивость и т.п.
3. Его соответствие требованиям заказчика
По - поводу третьего пункта уже писали ранее, поэтому я повторяться не буду.
Относительно первого и второго пункта напишу, как это делаю я
При проверке структуры, организации, содержания и оформления ТЗ я руководствуюсь стандартом IEEE Std 830 - 1993. Очень достойный документ. Рекомендую ознакомиться и, в первую очередь тем, кто пишет ТЗ :)
Что касается полноты, целостности и т.д., то здесь лучшее средство - это непосредственное написание тестов. И не просто тестов, а используя схематичный подход с его прекрвсными критериями тестов. Данный подход подробно описан в книге Луизы Тамре. Схематичный подход позволяет не только написать прекрасные тесты, но и определить множество изъянов и недостатков в требованиях.
Также рекомендую использовать для этих целей диаграммы переходов и таблицы состояний- тоже очень эфективный метод построения тестов и тесирования ТЗ.
Желаю удачи.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных