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

[saezar]

Чтото я совсем запарился,
В идеале же должно быть так?
Бизнес-функция ---> Функциональность ----> Требование -> Тест
........................|--> ............................ |---> ................. -> Тест2
................................................................................-> Тест3

Эм... Такая вот ASCII картинка :) Хреново получилась, но я надеюсь, понятно, что это дерево такое...
Я тут ветки с корнями не перепутал?

[Case]

Имхо перепуталось чуток:

Бизнес-функция -> Требование -> Функциональность -> Тест

[Alfa]

Имхо перепуталось чуток:

Бизнес-функция -> Требование -> Функциональность -> Тест

И кое чего не хватает:
Бизнес-функция -> Требование -> Функциональность -> Тест -> (Результат теста/Баг)

[saezar]

Стойте стойте.... Тут то и зарыто это животное.
Что то тут не так. Либо в терминах либо в схеме, либо там и там. У софта есть бизнесфункции, допустим у блокнота - редактировать тестовые файлы. Для выполнения этой бизнесфункции блокнот должен реализовывать некую функциональность (печать, копипаст, редактирование, сохранение....). На эту функциональность накладываются требования (копипаст по CtrlC CtrlV, сохранять в юникод.... и тд). Тесты проверяют функциональность на предмет соответствия требованиям. Потом конечно результаты и/или баги, но должно быть так, имхо.
Тоесть требования должны писаться на функциональность, или я опять туплю?

[Tuchka_84]

Стойте стойте.... Тут то и зарыто это животное.
Что то тут не так. Либо в терминах либо в схеме, либо там и там. У софта есть бизнесфункции, допустим у блокнота - редактировать тестовые файлы. Для выполнения этой бизнесфункции блокнот должен реализовывать некую функциональность (печать, копипаст, редактирование, сохранение....). На эту функциональность накладываются требования (копипаст по CtrlC CtrlV, сохранять в юникод.... и тд). Тесты проверяют функциональность на предмет соответствия требованиям. Потом конечно результаты и/или баги, но должно быть так, имхо.
Тоесть требования должны писаться на функциональность, или я опять туплю?

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

[saezar]

Таки стоп. Функциональность - не есть реализация функций в коде. Это список. Просто список функций. Другое дело, что этот список обязан быть частью требований.
Осмелюсь расширить схемку
Бизнесфункции ---> Бизнестребования ---> Список функциональности ---> Технические требования ---> Реализация в коде ---> Тестирование
Вот мне упроно кажется, что список функциональности раньше требований должен появляться. Требования - они же к чемуто должны предъявляться. И тестирование не чего то абстактного, а именно этих функций на предмет соответствия требованиям. Опять же имхо.

[LeshaL]

Стойте стойте.... Тут то и зарыто это животное.
Что то тут не так. Либо в терминах либо в схеме, либо там и там. У софта есть бизнесфункции, допустим у блокнота - редактировать тестовые файлы. Для выполнения этой бизнесфункции блокнот должен реализовывать некую функциональность (печать, копипаст, редактирование, сохранение....). На эту функциональность накладываются требования (копипаст по CtrlC CtrlV, сохранять в юникод.... и тд). Тесты проверяют функциональность на предмет соответствия требованиям. Потом конечно результаты и/или баги, но должно быть так, имхо.
Тоесть требования должны писаться на функциональность, или я опять туплю?

Коллега, а зачем вам вообще такое понятие как Бизнес-функции? Если оно никуда не вписывается, предлагаю избавиться и не думать о них. Или считать что бизнес-функции = top level requirements.
Тогда, ИМХО, должно получиться что-то типа такого:

1. Требование -> Функциональность (т.е. программная реализация функциональных требований) -> Use Cases (опционально) -> Тест-кейзы
2. Требование (не функциональное) -> Тест-кейзы

[Galina]

А разве требование не может быть в виде Use Cases?

[LeshaL]

Таки стоп. Функциональность - не есть реализация функций в коде. Это список. Просто список функций. Другое дело, что этот список обязан быть частью требований.
Осмелюсь расширить схемку
Бизнесфункции ---> Бизнестребования ---> Список функциональности ---> Технические требования ---> Реализация в коде ---> Тестирование
Вот мне упроно кажется, что список функциональности раньше требований должен появляться. Требования - они же к чемуто должны предъявляться. И тестирование не чего то абстактного, а именно этих функций на предмет соответствия требованиям. Опять же имхо.

Думаю, что если "Технические требования" заменить на слова "Функциональная спецификация" должно получиться понятнее. Тогда, как я уже написал выше, и "Бизнес-функции" (все-таки а что это такое?) и "Бизнес-требования" можно будет заменить на просто "Требования" и упростить картинку.
Объясню свою логику: требования предъявляются к продукту, которого еще нет, но который должен им соответствовать. Для реализации функциональных требований можно сделать например дизайн системы, расписав каждый компонент будущей системы, и какие требования этот компонент реализует, или каким из них соответствует (например для сторонних библиотек). Так, теперь у нас есть список будущей функциоанальности. Далее можно составить спецификацию, в которой описать особенности реализации той или иной фунциональности. Теперь появляется достаточно информации для написания тестов.

[Green]

Братцы,
Так прикольно смотреть, как иногда люди спотыкаются на ровном месте.

На мой взгляд, проблема кроется в словах.

Давайте разбираться по порядку.

Этап 1. Видение проекта.
Определяем что должно получаться в результате работы программы. Это бизнес-функции. Другими словами, какие бизнес-задачи должны решаться посредством программы.

Этап 2. Детализация требований.
Описываем механизмы, которыми мы будем пользоваться для решения бизнес-задач. Это user stories.
Эти же самые user stories, но имеющие различные схемы и более высокий уровень детализации и формализации - требования. Составная часть требования - use case.

Этап 3. Реализация.
На основании требований (user stories) пишем код программы - функциональность.

Этап 3а. Разработка тестов.
На основании требований формулируем тесты. Это можно делать до кода, одновременно с кодом и после кода. Но из-за того, что тесты вторичны по отношению к коду, поэтому мы ставим их в трейси-цепочку после функционала. Но! Это условно и не принципиально.

Этап 4. Проверка.
Выполняем тесты и документируем дефекты.

В результате получаем:
Бизнес-функция -> user stories -> требования -> функциональность -> тесты -> дефекты

[LeshaL]

А разве требование не может быть в виде Use Cases?

Может конечно, но и реализация требований может добавить юз-кейзы. Для тестирования важны как те, так и другие случаи использования какой-либо функциональности.
Возьмем пример с copy-paste. Требование: текстовый редактор должен поддерживать copy-paste внутри редактируемого документа.
Реализация может поддерживать только шоткаты CTRL+C CTRL+V, может предложить пункты меню в главном меню Edit, может быть реализовано и через контекстное меню и еще и с другими шоткатами CTRL+INS SHFT+INS. А может и вообще как в линуксе, операция copy в явном виде отсутствуе - заселектил чего-нить и сразу можно сделать paste в другом месте.
Не думаю, что имеет смысл описывать требования столь детально.

[saezar]

Этап 1. Видение проекта....

Вот тут согласен с Green. Бизнесфункции выбрасывать нельзя. Иначе можно упустить чего или наворотить лишнего. Первый этап нужен.

Ну я вобщем разобрался в путанице терминов.

... Так, теперь у нас есть список будущей функциоанальности. Далее можно составить спецификацию...

Вот об этом собсно и речь!
Кстати, "функциоАнальности", очень похоже на правду. Смеялся.

User Stories (Функциональная спецификация) у меня обозвался "Списком функциональности". Кстати, это официальный термин? В переводимом глоссарии есть?
Вопрос возник собсно из того, что у меня программеры отказываются в требованиях выделять функциональность, расписывать требования сообразно сценариям использования системы, и вообще к требованиям имеют только одно требование - мы их писать не должны. (жалуюсь :( )

[saezar]

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

[Alfa]

И есть ли какой не шибко дорогой инструмент для этого?

Excel или какой-то жирный коммерческий для ведения требований, тест кейсов и возможно багов, но они обычно не дешевы. Есть всякие open sourсe типа Testopia, TestLink, QAtraq.
Основная фича таких инструментов вести требования/тест кейсы, ну как один из отчетов получается traceability matrix.

[Boltick]

Братцы,
Так прикольно смотреть, как иногда люди спотыкаются на ровном месте.

На мой взгляд, проблема кроется в словах.

Давайте разбираться по порядку.

Этап 1. Видение проекта.
Определяем что должно получаться в результате работы программы. Это бизнес-функции. Другими словами, какие бизнес-задачи должны решаться посредством программы.

Этап 2. Детализация требований.
Описываем механизмы, которыми мы будем пользоваться для решения бизнес-задач. Это user stories.
Эти же самые user stories, но имеющие различные схемы и более высокий уровень детализации и формализации - требования. Составная часть требования - use case.

Этап 3. Реализация.
На основании требований (user stories) пишем код программы - функциональность.

Этап 3а. Разработка тестов.
На основании требований формулируем тесты. Это можно делать до кода, одновременно с кодом и после кода. Но из-за того, что тесты вторичны по отношению к коду, поэтому мы ставим их в трейси-цепочку после функционала. Но! Это условно и не принципиально.

Этап 4. Проверка.
Выполняем тесты и документируем дефекты.

В результате получаем:
Бизнес-функция -> user stories -> требования -> функциональность -> тесты -> дефекты

Добрый день, Сергей, спасибо за подробное описание...

Но я вот думаю, что незачем очень сильно дробить схему и выделять user stories как отдельную сущность.
Еще я не согласен, что после выполнения тестов пишутся только дефекты! Результатом прогона теста будет результат выполнения, т.е. либо PASSED либо FAILED, и только есть тест не прошел появляется дефект... Т.е. такую сущность как дефект можно заменить на Результат Теста.

В итоге мне кажется, что все сведется к схеме вида:
Бизнес-функция -> требования -> функциональность -> тесты -> Результат Теста

[Green]

Но я вот думаю, что незачем очень сильно дробить схему и выделять user stories как отдельную сущность.
Еще я не согласен, что после выполнения тестов пишутся только дефекты! Результатом прогона теста будет результат выполнения, т.е. либо PASSED либо FAILED, и только есть тест не прошел появляется дефект... Т.е. такую сущность как дефект можно заменить на Результат Теста.

В итоге мне кажется, что все сведется к схеме вида:
Бизнес-функция -> требования -> функциональность -> тесты -> Результат Теста

Ничего не имею против. Все зависит от того, что именно применяется в вашем проекте. Некоторые пишут user stories, другие оформляют требования в стиле RUP. И есть даже такие, что сразу переходит к функциональности и по ней формирует тесты. Не суть важно, каким именно способом в настоящий момент строится трейсебилити матрица. Отсутствие элементов - это может быть область к совершенствованию процесса.

Важно иметь такую матрицу и поддерживать ее в актуальном состоянии, так как это, по сути, единственная достоверная информация о текущем состоянии проекта.

Кстати, развивать эту тему можно до бесконечности. Давайте добавим еще в эту цепочку строчки кода.

[Alfa]

Кстати, развивать эту тему можно до бесконечности. Давайте добавим еще в эту цепочку строчки кода.

Вроде бы в вашем предыдущем посте говорится, что "функциональность" это и есть строчки кода, ну или очень к ним близко.
Или я что-то не так понял?

Этап 3. Реализация.
На основании требований (user stories) пишем код программы - функциональность.

[Green]

Кстати, развивать эту тему можно до бесконечности. Давайте добавим еще в эту цепочку строчки кода.

Вроде бы в вашем предыдущем посте говорится, что "функциональность" это и есть строчки кода, ну или очень к ним близко.
Или я что-то не так понял?

Этап 3. Реализация.
На основании требований (user stories) пишем код программы - функциональность.

Совершенно верно. Функциональность - это код. Только не весь код, в моей трактовке, а название функции (функции класса, если она в классе), которая реализует некий набор операций.

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

Справедливо и обратное. Если мы можем легко опуститься на уровень строчек кода, то, следовательно, мы можем легко протрейсить, что вот такая и такая ветви (читай строчки кода) работают, а вот эта ветвь - не работает.

[DexterI]

В принципе с описанием согласен, кроме вот этого

Этап 3а. Разработка тестов.
На основании требований формулируем тесты. Это можно делать до кода, одновременно с кодом и после кода. Но из-за того, что тесты вторичны по отношению к коду, поэтому мы ставим их в трейси-цепочку после функционала. Но! Это условно и не принципиально.

Сами тесты приципиально важно писать ДО реализации в коде (общий сценарий на основании ТЗ), а потом и ПОСЛЕ реализации в коде (здесь имеющейся общий сценарий детализируется на основании уже реализованного требования).

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

Может немного и оффтоп, но я посчитал важным обратить на это внимаени!:)

[saezar]

2 DexterI: Возможно, возможно... Я представляю что для этого нужно и сразу погружаюсь в мечтательное состояние... Это ж какого качаства спецификации должны мне предоставляться, какие прототипы... А работа дизайнера интерфейса до написания кода... Testdriven development... Эх..