Перейти к содержимому

Автоматизация тестов для REST API при помощи Postman
онлайн, начало 11 марта
Школа Тест-Аналитика
онлайн, начало 10 марта
Школа тест-менеджеров v. 2.0
онлайн, начало 10 марта
Chrome DevTools: Инструменты тестировщика
онлайн, начало 11 марта
Фотография

Трейсабилити


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 25

#1 saezar

saezar

    Активный участник

  • Members
  • PipPip
  • 113 сообщений
  • ФИО:Сергей

Отправлено 08 июля 2008 - 08:29

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

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

#2 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 08 июля 2008 - 09:24

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

Бизнес-функция -> Требование -> Функциональность -> Тест
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#3 Alfa

Alfa

    Специалист

  • Members
  • PipPipPipPipPip
  • 553 сообщений
  • Город:Moscow

Отправлено 08 июля 2008 - 09:35

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

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

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

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.


#4 saezar

saezar

    Активный участник

  • Members
  • PipPip
  • 113 сообщений
  • ФИО:Сергей

Отправлено 09 июля 2008 - 03:42

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

#5 Tuchka_84

Tuchka_84

    Активный участник

  • Members
  • PipPip
  • 105 сообщений
  • ФИО:Маша

Отправлено 09 июля 2008 - 06:39

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

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

#6 saezar

saezar

    Активный участник

  • Members
  • PipPip
  • 113 сообщений
  • ФИО:Сергей

Отправлено 09 июля 2008 - 07:49

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

#7 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 09 июля 2008 - 08:01

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

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

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

#8 Galina

Galina

    Постоянный участник

  • Members
  • PipPipPip
  • 151 сообщений
  • Город:Москва

Отправлено 09 июля 2008 - 08:13

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

#9 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 09 июля 2008 - 08:28

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

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

#10 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 09 июля 2008 - 08:32

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

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

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

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

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

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

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

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

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

#11 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 09 июля 2008 - 08:42

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

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

#12 saezar

saezar

    Активный участник

  • Members
  • PipPip
  • 113 сообщений
  • ФИО:Сергей

Отправлено 09 июля 2008 - 08:51

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

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

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

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

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

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

#13 saezar

saezar

    Активный участник

  • Members
  • PipPip
  • 113 сообщений
  • ФИО:Сергей

Отправлено 09 июля 2008 - 09:55

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

#14 Alfa

Alfa

    Специалист

  • Members
  • PipPipPipPipPip
  • 553 сообщений
  • Город:Moscow

Отправлено 09 июля 2008 - 10:17

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

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

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.


#15 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 11 июля 2008 - 08:07

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

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

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

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

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

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

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

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

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


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

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

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

#16 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 11 июля 2008 - 08:35

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

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


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

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

Кстати, развивать эту тему можно до бесконечности. Давайте добавим еще в эту цепочку строчки кода.
:acute:
  • 0
Гринкевич Сергей

#17 Alfa

Alfa

    Специалист

  • Members
  • PipPipPipPipPip
  • 553 сообщений
  • Город:Moscow

Отправлено 11 июля 2008 - 10:20

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

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

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


  • 0

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.


#18 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 11 июля 2008 - 11:16

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

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

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


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

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

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

#19 DexterI

DexterI

    Новый участник

  • Members
  • Pip
  • 26 сообщений
  • ФИО:Илья

Отправлено 14 июля 2008 - 16:07

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

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


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

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

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

#20 saezar

saezar

    Активный участник

  • Members
  • PipPip
  • 113 сообщений
  • ФИО:Сергей

Отправлено 15 июля 2008 - 01:55

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


Практикум по тест-дизайну 2.0
онлайн
Школа для начинающих тестировщиков
онлайн
Школа тест-аналитика
онлайн
Техники локализации плавающих дефектов
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале