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

[Олешка]

Требования к продукту, как таковые, также должны тестироваться на согласованность, непротиворечивость и тестируемость. А реально кто-нибудь занимается тестированием постановки задачи на уровне алгоритма?

[Case]

Занимаемся. Я непосредственно только что по документу с постановкой на модуль закончил работу.
Обычная процедура - запросы на изменение, только не на разработчика, а на постановщика. И что самое интересное сами постановщики только за.
И алгоритмы и требования проверяем на непротиворечивость. И тестовые реальные данные прогоняем по нашим получившимся алгоритмам ещё до прогона их системой.

[Олешка]

Занимаемся. Я непосредственно только что по документу с постановкой на модуль закончил работу.
Обычная процедура - запросы на изменение, только не на разработчика, а на постановщика. И что самое интересное сами постановщики только за.
И алгоритмы и требования проверяем на непротиворечивость. И тестовые реальные данные прогоняем по нашим получившимся алгоритмам ещё до прогона их системой.

А теперь вопрос... насколько понимаю, считаете руками? Проверяете формулы, логику и т.д.? Или используете какой-нибудь тул?

[Case]

Руками. Ибо постановка формализована до уровня документа.
Есть формула - есть результат рассчёта предоставленный заказчиком, который есть критерием оценки верности нашей реализации, то есть частью ТЗ. Его перепроверкой занимаемся тоже.

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

[Case]

С трудом представляю тул, который выловит логическую ошибку в документе. Такой себе скромный семантик анализатор, который встраивается в Ворд, имеет расширение под логику предметной области и выделяет подчёркиванием неуместности. Вроде такого быть не может. Или может? :)

[Олешка]

Доктор, можно мне таблетки от жадности... ;) а лучше бы такой тул. Боюсь, пока нет. Вот reuirements management tools должны быть.

[Case]

Тул для управления требований видится мне не в пример реальнее чем миф о анализаторе логики :)

[SALar]

Забавно. Поднял старый тред и выяснил, что вчера в блоге дал ответ на вопрос, заданный три года назад.

Приходит на ум сказка о "разговорчивых" тролях.

[chuk]

Занимаемся этим на каждом проекте.
Но проблем много - кастомеры разные, форма док-тов разная, степень детализации разная.

Идеальный случай - наличие диаграмм, хорошие Use Cases, хорошие снепшоты.
Но такое редко. Чаще всего - просто описание.

Худший вариант - это вообще требование в эл. почте по принципу - "хочу, чтобы было так и все" - в этой ситуации идет долгая переписка с представителем кастомера и утряска всех вопрососв по постановке задачи.

формулы ручками.
Чаще всего - таблицы в экселике, которые потом можно подгружать как тестовые данные через TestComplete (это для формул)

или же логика - те же таблички в экселике.
Дерево охвата всех веток логики.

очень хочется подобрать хороший тул для менеджмента требований, но пока все никак не нашел то, что нужно.

хочется, чтобы тул был открытым, чтобы не требовал отдельной должности Requirement Manager, чтобы кастомер туда тоже "иногда" заглядывал, а не ждал, когда его дернут или когда ему что-то новое приспичит.

Caliber понравился, но не сложилось.
Вот может свое что-то наваяем для себя.

Но что интересно - трудность не в тестировании как таковом постановки задачи - тут просто внимательность и логика - отследить связи и возможные противоречия. Основная трудность у нас - это увязать все до кучи - так как само по себе тестирование постановки задачи без тесной связи кастомера, девелоперов, райтеров и QA приводит к огромным временным затратам. Пока все "очухаются" на запросы - то много времени проходит.

а вообще стараюсь все проверки по требованиям в виде схем и таблиц оформлять - так нагляднее и ошибок меньше пропускается.
С одной стороны дольше, а с другой стороны - такие проверки легко править и анализировать.

что касается анализатора логики - то пытались RUP-ом по моделям и UML-диаграмам ходить, но для этого сначала надо их иметь или сделать самому - а это время и переработка требований в виде кастомера (а он их дает в чем угодно, хоть в звонках телефонных). Поэтому отказались от такой работы - дешевле пока ручками практиковаться.

[QArer]

Требования к продукту, как таковые, также должны тестироваться на согласованность, непротиворечивость и тестируемость. А реально кто-нибудь занимается тестированием постановки задачи на уровне алгоритма?

Только это называется анализ, а не тестирование.

[Clauster]

Требования к продукту, как таковые, также должны тестироваться на согласованность, непротиворечивость и тестируемость. А реально кто-нибудь занимается тестированием постановки задачи на уровне алгоритма?

Только это называется анализ, а не тестирование.

что из двух?

[idunin]

Худший вариант - это вообще требование в эл. почте по принципу - "хочу, чтобы было так и все" - в этой ситуации идет долгая переписка с представителем кастомера и утряска всех вопрососв по постановке задачи.

А в этом случае что? Уже получается что тестер вовсе не тестер, а аналитик? Это я правильно понимаю, что такое бывает.

[Rost]

А в этом случае что? Уже получается что тестер вовсе не тестер, а аналитик? Это я правильно понимаю, что такое бывает.

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

[idunin]

Обычная процедура - запросы на изменение, только не на разработчика, а на постановщика.

А можно пример таких запросов? Что они из себя представляют? Это просто описание какого-то не соответствия в ТЗ?

[_Sergey_]

По-поводу системы управления требованиями.... Советую рассмотреть DOORS. Система в России слабо распространена (и даже не исвестна), хотя в остальном мире очень широко используется и при всяких сравнениях с Rational and Caliber стабильно занимает первые места. Система DOORS является продуктом Telelogic (www.telelogic.ru).

Желаю правильного выбора ))).

[Darkus]

Ага, только DOORS стоит, "как самолёт" :)

[QArer]

Требования к продукту, как таковые, также должны тестироваться на согласованность, непротиворечивость и тестируемость. А реально кто-нибудь занимается тестированием постановки задачи на уровне алгоритма?

Только это называется анализ, а не тестирование.

что из двух?

Если я правильно понял:
И постановка задачи, и спецификация, и дизайн и иные промежуточные продукты должны быть (в идеале, естественно) подвергнуты анализу (как analysis так и review, хотя разницы может и нет) .
Этому учат все модели и подходы к менеджменту качества.

И это нельзя назвать тестированием, поскольку тестирование - это испытание. Испытывать документацию - некорректно.

И не факт что тестеры должны такой анализ проводить - скорее аналитики, тим лидеры и т.п.

[Shander]

По-поводу системы управления требованиями.... Советую рассмотреть DOORS. Система в России слабо распространена (и даже не исвестна), хотя в остальном мире очень широко используется и при всяких сравнениях с Rational and Caliber стабильно занимает первые места. Система DOORS является продуктом Telelogic (www.telelogic.ru).
Желаю правильного выбора ))).

Сергей, учитывая, что, по Вашим словам, система мало известна в России, было бы очень полезно, если бы вы рассказали подробнее о ней, и о вашем опыте (как я понял, он у вас есть) ее использования. Чем именно она завоевала ваше признание, и в чем её основные плюсы относительно Requisite Pro и CaliberRM?