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

[Levix]

Здраствуйте господа.

Предлагаю обсудить один подход - так называемый First-test design (еще его называют Test-Driven Development).

Сам только начал его изучать. Создается хорошее впечатление.
Интересует мнение экспертов.


В частности интересует участие аналитика в этом процессе и применение к анализу на ранних этапах проекта.

Заранее спасибо за ответы.

[Case]

Метод разработки "тест-код", насколько сам сталкивался в работе, показывает очень замечательные результаты, если разработка проекта ведётся по ХР-методологии. Зачастую правда очень трудно заставить разработчиков писать тесты :)

Если интересует - обратите внимание на ресурс наших партнёров http://xprogramming.com.ua, методика обсуждается в форуме.

По поводу участия аналитика в процессе разработки:
как я вижу методологию - то как раз на этапе создания тестов, которые предшествуют написанию самого кода, аналитик может принимать участие в разработке, то есть вносить более низкоуровненвые замечания. Хотя согласно той же методологии, особенности имплементации ложатся на плечи разработчиков (кодировщиков), и имеется ли место аналитика сказать трудно.
То есть место где приложить знания безусловно в методологии есть, но вот что осветуют по этому вопросу эксперты ХР, нужно у них уточнить.

Пригласим ХР-шников :)

[sashaf]

Здравствуйте,
Я бы разделил понятия First-test design и Test-Driven Development. Test-Driven Development - техника написания модульного теста программистом непосредственно перед написанием кода. Она позволяет проводить проверку участка кода, обычно публичного метода какого-то класса, сразу после его написания. Позволяет лучше понять задачу, иметь возможность применять рефакторинг, быть уверенным в работоспособности множества кода, в конце-концов служить хорошей документацией кода. На эту тему написано множество статей, есть и русскоязычные переводы: http://xprogramming....ua/unittest.php

Что же касается First-test design, то это скорее можно отнести к приёмочному тестированию. В процессе сбора требований по методологии XP рекомендуется вместе с заказчиком обсудить или написать функциональные тесты для будущей системы. Они позволят программисту лучше понять задачу и очертить конкретную цель разработки: пока не выполнится тест. Впоследствии приёмочные тесты можно автоматизировать и запускать ежедневно, тем самым следить за ходом разработки: сколько тестов выполняется, а сколько ещё не работает. На эту тему тоже есть статьи: http://xprogramming....ancetesting.php

Надеюсь это вам поможет.

[Case]

Я всё-таки вставлю свои пять копеек с Вашего позволения.
Или я не очень много работал в "правильными заказчиками", или тут какая то явная проблема с методолгией ХР.
Ну не пишет заказчик тесты. Не пишет.

Да кодировщик, разработчик может по ХР разрабатывать код - очень даже, и тестировщик после может работать с тестом, который разработан кодировщиком, но вот про приёмочное тестирование... Кто нибудь сталкивался с тем, чтобы заказчик, представитель заказчика, ответсвенный разработчик со стороны заказчика, младший уборщик из офиса заказчика писал тесты вместе с разработчиками?
Или мне одному так не повезло? :)
Не видел такого.

Пробовали внедрить на этапе постановки совместную разработку прототипов интерфейсмов (казалось бы - что понятнее и ближе к пользователю, чем кнопочки в которые он будет тыкаться каждый день?) - воют. Воют громким воем - мы этого не понимаем - давайте варианты мы выберем. Кстати и по принципиальным моментам таже петрушка - вы сделайте - мы попробуем и скажем где не так. Неужто один я в такой ситуации, народ? :)

Если чесно, то на мой взгляд, в моментах работы с заказчиком ХР у нас и не работает. Не работает.

[Levix]

Согласен с Case
Заказчик тестов не напишет. Представьте себе, что все таки заказчик написал разработчику тесты...
Что Вы с такими тестами дальше делать будете? (учитываем "виденье полной картинки", знание технологии разработки ПО, и другие грани).

Как базис использую customer behavior - "ПОЙМУ КОГДА УВИЖУ" и пользуюсь прототипом. При определенных усилиях является довольно эффективным подходом.

Относительно предложенной мной темы я для себя ситуацию прояснил.
Работа аналитика описана здесь - Generating Test Cases From Use Cases

[Case]

По методолгии предполагается, что тесты пишет, канечно не Большой Босс Заказчик - это понятно, я тестировщик на стороне заказчика (нанятый отдельно или постоянно работающий).
Но это ближе к реалиям распределённой разработки, когда одна из фирм, софтверная, просто распраделяет задачи между партнёрскими компаниями и сама же выступает заказчиком разработки. Тогда канечно, есть и заказчки, есть и написанные им (специалистом тестировщиком) тесты. В наших реалиях в роли заказчика обычно выступает именно заказчик системы - то есть предприятие, компания, которая хочет автоматизировать часть работ и не имеет собственного отдела автоматизации, или тот не достаточно развит. Тогда канечно говорить о тестах написанных заказчиком безидейно.

[chuk]

Практически постоянная практика (у нас), когда заказчик участвует в процессе тестирования (косвенно конечно). Тест Кейсы, конечно, не пишет (хотя были ситуации, когда и такое случалось), но чаще всего - мы совместно с заказчиком создаем тестовые наборы из которых уже видно, что и как будет делаться.

[Case]

Так дело то в том, что таже ХР методология не приемлет никаких косвенно или частично. По ХР заказчик (представитель оного), вовлечён в процесс разработки по уши - он участник команды.

А вот про создание тестовых наборов - Вам с ним повезло. Насколько знаю обычно как раз всё сводится к "увижу - пойму".

[chuk]

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

[Case]

У нас пока даёт результат только протитипирование вместе с заказчиком.
Кстати как поклонник данного подхода очень рекомендую ссылку: Проектирование интерфейса как часть разработки ТЗ
Сидя рядом и рисуя (на бумаге, в хтмл да как угодно) сам интерфейс выполняется две очень важные на мой взляд задачи: постановщик и ведущий разработчик получат реальное ТЗ, а тестировщик получает сценарий использования системы в чистом виде "как надо", а не как это потом реализуют разработчики.

[chuk]

Согласно нашему Project Flow все так и должно происходить (и почти всегда так и происходит),
но иногода бывают моменты ....... :-)))
Просто была задача получить тестовые данные не такие, какие мы придумаем, а реальные, с которыми работает заказчик.
Но между входными и выходными данными было много логики, которую заказчик при наборе тестовых данных сам отслеживать не захотел.
А что касается интерфейса, то тут тоже есть проблемы - как утрясти вопросы у меня, заказчика, дизайнера и разработчика. Дизайнеры - интересный народ - нарисовать могут все, что угодно (и это
правильно, это их работа :-)))) ).
Обычно они все это делают сами, а потом я ревьювлю то, что написано в Ureq и Treq.
Для меня очень важно, чтобы потом дизайн не менялся (он и не должен меняться), но тоже иногда меняется. Почти всегда со стороны заказчика - тут уж никуда не денешься.
Вот хочется так и все. А если это все происходит на этапе, когда больше половины кода системы реализовано - вот начинается головная боль и хорошо еще, если заказчик согласится перевести все это в change request с дополнительным временем.