First-test Design
#1
Отправлено 11 сентября 2003 - 11:47
Предлагаю обсудить один подход - так называемый First-test design (еще его называют Test-Driven Development).
Сам только начал его изучать. Создается хорошее впечатление.
Интересует мнение экспертов.
В частности интересует участие аналитика в этом процессе и применение к анализу на ранних этапах проекта.
Заранее спасибо за ответы.
#2
Отправлено 11 сентября 2003 - 14:17
Если интересует - обратите внимание на ресурс наших партнёров http://xprogramming.com.ua, методика обсуждается в форуме.
По поводу участия аналитика в процессе разработки:
как я вижу методологию - то как раз на этапе создания тестов, которые предшествуют написанию самого кода, аналитик может принимать участие в разработке, то есть вносить более низкоуровненвые замечания. Хотя согласно той же методологии, особенности имплементации ложатся на плечи разработчиков (кодировщиков), и имеется ли место аналитика сказать трудно.
То есть место где приложить знания безусловно в методологии есть, но вот что осветуют по этому вопросу эксперты ХР, нужно у них уточнить.
Пригласим ХР-шников :)
Редактор портала www.it4business.ru
#3
Отправлено 11 сентября 2003 - 14:48
Я бы разделил понятия First-test design и Test-Driven Development. Test-Driven Development - техника написания модульного теста программистом непосредственно перед написанием кода. Она позволяет проводить проверку участка кода, обычно публичного метода какого-то класса, сразу после его написания. Позволяет лучше понять задачу, иметь возможность применять рефакторинг, быть уверенным в работоспособности множества кода, в конце-концов служить хорошей документацией кода. На эту тему написано множество статей, есть и русскоязычные переводы: http://xprogramming....ua/unittest.php
Что же касается First-test design, то это скорее можно отнести к приёмочному тестированию. В процессе сбора требований по методологии XP рекомендуется вместе с заказчиком обсудить или написать функциональные тесты для будущей системы. Они позволят программисту лучше понять задачу и очертить конкретную цель разработки: пока не выполнится тест. Впоследствии приёмочные тесты можно автоматизировать и запускать ежедневно, тем самым следить за ходом разработки: сколько тестов выполняется, а сколько ещё не работает. На эту тему тоже есть статьи: http://xprogramming....ancetesting.php
Надеюсь это вам поможет.
#4
Отправлено 15 сентября 2003 - 09:58
Или я не очень много работал в "правильными заказчиками", или тут какая то явная проблема с методолгией ХР.
Ну не пишет заказчик тесты. Не пишет.
Да кодировщик, разработчик может по ХР разрабатывать код - очень даже, и тестировщик после может работать с тестом, который разработан кодировщиком, но вот про приёмочное тестирование... Кто нибудь сталкивался с тем, чтобы заказчик, представитель заказчика, ответсвенный разработчик со стороны заказчика, младший уборщик из офиса заказчика писал тесты вместе с разработчиками?
Или мне одному так не повезло? :)
Не видел такого.
Пробовали внедрить на этапе постановки совместную разработку прототипов интерфейсмов (казалось бы - что понятнее и ближе к пользователю, чем кнопочки в которые он будет тыкаться каждый день?) - воют. Воют громким воем - мы этого не понимаем - давайте варианты мы выберем. Кстати и по принципиальным моментам таже петрушка - вы сделайте - мы попробуем и скажем где не так. Неужто один я в такой ситуации, народ? :)
Если чесно, то на мой взгляд, в моментах работы с заказчиком ХР у нас и не работает. Не работает.
Редактор портала www.it4business.ru
#5
Отправлено 16 сентября 2003 - 06:12
Заказчик тестов не напишет. Представьте себе, что все таки заказчик написал разработчику тесты...
Что Вы с такими тестами дальше делать будете? (учитываем "виденье полной картинки", знание технологии разработки ПО, и другие грани).
Как базис использую customer behavior - "ПОЙМУ КОГДА УВИЖУ" и пользуюсь прототипом. При определенных усилиях является довольно эффективным подходом.
Относительно предложенной мной темы я для себя ситуацию прояснил.
Работа аналитика описана здесь - Generating Test Cases From Use Cases
#6
Отправлено 16 сентября 2003 - 08:43
Но это ближе к реалиям распределённой разработки, когда одна из фирм, софтверная, просто распраделяет задачи между партнёрскими компаниями и сама же выступает заказчиком разработки. Тогда канечно, есть и заказчки, есть и написанные им (специалистом тестировщиком) тесты. В наших реалиях в роли заказчика обычно выступает именно заказчик системы - то есть предприятие, компания, которая хочет автоматизировать часть работ и не имеет собственного отдела автоматизации, или тот не достаточно развит. Тогда канечно говорить о тестах написанных заказчиком безидейно.
Редактор портала www.it4business.ru
#7
Отправлено 18 сентября 2003 - 13:52
#8
Отправлено 19 сентября 2003 - 07:22
А вот про создание тестовых наборов - Вам с ним повезло. Насколько знаю обычно как раз всё сводится к "увижу - пойму".
Редактор портала www.it4business.ru
#9
Отправлено 19 сентября 2003 - 08:05
Когда на Access пишешь базу с формами ввода (чтоб им легче вводить было), а представитель со
стороны заказчика хочет еще и логику туда навернуть, чтоб вообще вводить данные не думая, что вводишь, т.е получается такой маленький пилотный проект.
Но я думаю, что затраты на это окупаются, т.к. потом я эти базы подключаю в готовом виде к тесткейсам
#10
Отправлено 19 сентября 2003 - 08:13
Кстати как поклонник данного подхода очень рекомендую ссылку: Проектирование интерфейса как часть разработки ТЗ
Сидя рядом и рисуя (на бумаге, в хтмл да как угодно) сам интерфейс выполняется две очень важные на мой взляд задачи: постановщик и ведущий разработчик получат реальное ТЗ, а тестировщик получает сценарий использования системы в чистом виде "как надо", а не как это потом реализуют разработчики.
Редактор портала www.it4business.ru
#11
Отправлено 19 сентября 2003 - 08:45
но иногода бывают моменты ....... :-)))
Просто была задача получить тестовые данные не такие, какие мы придумаем, а реальные, с которыми работает заказчик.
Но между входными и выходными данными было много логики, которую заказчик при наборе тестовых данных сам отслеживать не захотел.
А что касается интерфейса, то тут тоже есть проблемы - как утрясти вопросы у меня, заказчика, дизайнера и разработчика. Дизайнеры - интересный народ - нарисовать могут все, что угодно (и это
правильно, это их работа :-)))) ).
Обычно они все это делают сами, а потом я ревьювлю то, что написано в Ureq и Treq.
Для меня очень важно, чтобы потом дизайн не менялся (он и не должен меняться), но тоже иногда меняется. Почти всегда со стороны заказчика - тут уж никуда не денешься.
Вот хочется так и все. А если это все происходит на этапе, когда больше половины кода системы реализовано - вот начинается головная боль и хорошо еще, если заказчик согласится перевести все это в change request с дополнительным временем.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных