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

[YuP]

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

[Ra.]

Версионность тестов ИМХО обязательна, т.к. тест - главный артефакт тестирования. Все вокруг тестов крутится. И очень важно хранить их версии, чтобы делать правильные выводы об эффективности и иметь возможность управлять процессом тестирования.
И так же обязательна версионность требований, т.к тесты должны что-то конкретное проверять, а требования - живой докумен, меняется постоянно вместе с продуктом.

Я вовсе не хочу спорить с цитатой выше :) Я лишь рассуждаю...
Я считаю, что если есть версионность требований - это уже очень хорошо. Ибо по большому счету не так важен тест и способ каким было проверено данное требование, важен результат. Скажем есть требование - "Система должна выдерживать 100 конкурентных запросов типа X". Результат теста - "Выдерживает 120, passed". Далее требование меняется: "Система должна выдерживать 120 конкурентных запросов типа Y". Результат теста - "Fail - (выдерживает только 80)". С точки зрения ретроспективного анализа развития продукта/проекта, все фактические данные есть - есть требования (и все их версии) и есть результаты (ес-но речь идет о том, что все результаты тестов тоже есть)... Конечно, если далее требование снова меняется (гипотетически) на первоначальное, то удобней просто откатить и версию теста к первоначальной... Но, это уже можно рассматривать как удобство :) Я еще раз подчеркну, я согласен, и мне тоже кажется это естественным - версионность требований и тестов, но все-таки даже без версионности тестов теоретически можно жить :)

[YuP]

С таким тестом - да, согласен, версионность не очень нужна, результат говорит о многом.

А вот другой пример (извиняюсь заранее за упрощение): вызовом такого-то пункта в контекстном меню открыть Окно1, ввести в нем такие-то значения, сохранить результат вычисления в файл нажатием кнопки Save, ожидаемый результат: файл должен быть записан и иметь такой-то формат.
Результат не цифра, а факт наличия нужного файла после выполнения определенных действий.

А теперь меняем в тесте в силу каких-либо причин "вызовом такого-то пункта" на "даблкликом по иконке"... Файл перестал сохраняться. А почему? А как раньше его сохраняли? Вот тут уже просмотр предыдущей версии теста пригодился бы..

[Ra.]

С таким тестом - да, согласен, версионность не очень нужна, результат говорит о многом.

А вот другой пример (извиняюсь заранее за упрощение): вызовом такого-то пункта в контекстном меню открыть Окно1, ввести в нем такие-то значения, сохранить результат вычисления в файл нажатием кнопки Save, ожидаемый результат: файл должен быть записан и иметь такой-то формат.
Результат не цифра, а факт наличия нужного файла после выполнения определенных действий.

А теперь меняем в тесте в силу каких-либо причин "вызовом такого-то пункта" на "даблкликом по иконке"... Файл перестал сохраняться. А почему? А как раньше его сохраняли? Вот тут уже просмотр предыдущей версии теста пригодился бы..

Ну и тут подискутирую. У вас налицо или изменение требований в интерфейсу (нужно было чтобы выполнялось определенное действие посредством вызова пункта меню, а стало - посредством нажатия на иконке). Или (если изначально в требования к интерфейсу была заложена альтернатива в вызове действия как пунктом меню, так и кликом на иконке) изначально неполный тест.

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

Опять же с точки зрения создания ПО не важно какой был тест - важно определить качество продукта и соответствие его требованиям.
И версионность в данном случае нужна лишь для анализа работы тестировщика разработавшего тест...

[YuP]

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

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

Да и вообще, не важно был ли тест полным или неполным изначально и каким он стал после редактирования. Человек вправе ошибиться и сначала сформулировать мысль не правильно, а потом постараться ее откорректировать. Может получиться и наоборот.. Вот для того, чтобы иметь право на ошибку и нужна версионность.

[Ra.]

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

Ну, да. С версионностью хорошо. Просто есть необходимые условия для выполнения какой-то работы (процесса) и есть достаточные.
Чтобы сделать рагу из зайца нужно как минимум иметь зайца. Без него - ни никак. А вот наличие соуса к этому рагу - это уже "опция", приятная, но и без нее жить в принципе тоже можно :)

Прошу прощения за лирическое отступление.

[Wizard]

Господа, почему вы решили, что в Mercury QC нет версионности тестов? Давно и успешно работаю с данным инструментом, и имхо там есть полная поддержка версий требований. С историей и т.д.

[Case]

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

Версионность требований нужна - но совсем не потому что это живой документ :)

[Case]

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

Может это и не спроста? Хинт: некоторые используют тестовые сценарии вместо требований и довольно успешно.

[Ra.]

Господа, почему вы решили, что в Mercury QC нет версионности тестов? Давно и успешно работаю с данным инструментом, и имхо там есть полная поддержка версий требований. С историей и т.д.

Речь шла о версионности именно test-case'ов. Как например в TestLink.

[Ra.]

Хинт: некоторые используют тестовые сценарии вместо требований и довольно успешно.

Вы имеете в виду, что под требованиями выступает по-сути описание test-case'a, успешное выполнение которого свидетельствует о работоспособности функционала? Этакий вариант Test-Driven Development'a, когда мы описываем как должно быть, а потом уже реализуем и проверяем, ну вполне логично, если я правильно понял...

[YuP]

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

Версионность требований нужна - но совсем не потому что это живой документ :)

Скорее не только потому, что это живой документ :)

Примеры чуть выше были. Неохота продолжать креативничать на эту тему..
Но раз уж просьба прозвучала.. :)

Пример.
Есть 2 параллельные ветви разработки одного и того же продукта. Разошлись они совсем недавно из-за отличий в тонкостях ТЗ для двух разных заказчиков. Со временем ветви обязательно объединятся. Тест определенной функциональности немного отличается в деталях для одной ветви относительно другой. Мало того, сначала это был один тест, а теперь необходимо вести две его ветви. Можно бы сделать 2 теста - каждый на свою версию тестируемого приложения. Но т.к. отличия минимальны, а сам тест достаточно объемен, то удобнее вести 2 параллельные версии одного теста.

Вот другой аспект применения версионности тестов.

[Ra.]

Есть 2 параллельные ветви разработки одного и того же продукта.

Ну....

А почему элементарно не считать это разными версиями продукта, со всеми так сказать вытекающими? Ну сойдутся они когда-ить - ну и здорово, будете тестить одну версию, а разойдутся на еще большее количество веток - будете тестить столько, сколько надо, главное - множество тестов определите, и используйте когда надо общие (одни и те же) тесты для любой версии, когда надо - специализированные из вашей Test Library, зачем же здесь версионность, все определяется вашими тест-планами. Это даже TestLink (бесплатный, кстати :)) позволяет сделать :)? (Кстати, там есть и версионность test-case'ов, правда на мой взгляд немного неудачно реализованная, но это уже другой разговор...)

[saezar]

Коллеги, подскажите. Я не совсем понимаю структуру линейки Mercury. TestDirector входит в Mercury Quality Center, наборот, или это одно и то же? Грубо говоря, что качать?! 8-0
Я попытался скачать с оффсайта Quality Center. Там еще и DashBoard в инсталляшке. Оно мне надо или не надо? Я бы не спрашивал, но файлик оказался битый. У меня не халявный интернет, что бы по второму разу 100 мб качать. Я засомневался, то ли это, что мне нужно? А нужно управление тестами, багтрек и управление требованиями в одном флаконе.
И кстати. Что же всё таки выбрать? Rational или Mercury???

[Ra.]

Коллеги, подскажите. Я не совсем понимаю структуру линейки Mercury. TestDirector входит в Mercury Quality Center, наборот, или это одно и то же? Грубо говоря, что качать?! 8-0
Я попытался скачать с оффсайта Quality Center. Там еще и DashBoard в инсталляшке. Оно мне надо или не надо? Я бы не спрашивал, но файлик оказался битый. У меня не халявный интернет, что бы по второму разу 100 мб качать. Я засомневался, то ли это, что мне нужно? А нужно управление тестами, багтрек и управление требованиями в одном флаконе.
И кстати. Что же всё таки выбрать? Rational или Mercury???

Ну, акценты ("не халявный интернет, что бы по второму разу 100 мб качать") расставлены, а когда акценты расставлены, то решение дается легче :) Качать ес-но лучше Mercury. Причем однозначно, ибо согласитесь, одно дело скачать 400 метров (или около того, но явно не 100) или 1.2 Гб Rational?

Шутка конечно. Могу сказать только что лучше вам посмотреть и то и другое. Это - факт.

Не удержусь (настроение хорошее) заметить, что не пристало человеку выбирающему ПО на десятки (!) тысяч евро (лицензия на одно раб. место Mercury вам обойдтся минимум в 5-10 тыщ. EUR) 100 Мб трафика считать :) но это лирическое отступление, опять же в шутку, не более того ...

Что касается линейки Mercury Quality Center, то "Mercury Quality Center представляет собой законченную интегрированную систему с web интерфейсом для обеспечения управления процессами контроля качества в широком диапазоне разнообразных IT сред"... в том числе он включает в себя и TestDirector и QuickTest Professional и WinRunner и Business Process Testing и кажется Application Delivery Dashboard и может быть и еще чего... и багтрек и управления требованиями он включает. Как и Rational - оба решения предлагают до безобразия интегрированные решения, с широчайшими возможностями по перспективам развития...

Чтобы решить что использовать - нужно определиться с требованиями (А что собственно нужно? Есть масса систем и более дешевых. И даже бесплатных). А чтобы решить что качать - нужно пожалуй любопытство :)

C уважением,
А.

[saezar]

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

[Dmitry_NJ]

Коллеги, подскажите. Я не совсем понимаю структуру линейки Mercury. TestDirector входит в Mercury Quality Center, наборот, или это одно и то же? Грубо говоря, что качать?! 8-0
Я попытался скачать с оффсайта Quality Center. Там еще и DashBoard в инсталляшке. Оно мне надо или не надо? Я бы не спрашивал, но файлик оказался битый. У меня не халявный интернет, что бы по второму разу 100 мб качать. Я засомневался, то ли это, что мне нужно? А нужно управление тестами, багтрек и управление требованиями в одном флаконе.

TD и QC это что-то вроде "говорим Ленин - подразумеваем партия". Я уже на форуме один раз объяснял в чем разница и почему часто возникает путаница. Если интересно - поищите. Вкратце. Качаете QC. Dashboard вам не нужен. Это красивая примочка, которая позволяет наглядно показывать большим начальникам состояние дел с тестированием тех или иных проектов, которые ведутся в TD.

P.S. Соглашусь с Ra. Контора, присматривающаяся к QC, и ограничивающая траффик для сотрудника, занимающегося скачиванием триальных версий, со стороны производит диковатое впечатление.

[Case]

Хинт: некоторые используют тестовые сценарии вместо требований и довольно успешно.

Вы имеете в виду, что под требованиями выступает по-сути описание test-case'a, успешное выполнение которого свидетельствует о работоспособности функционала? Этакий вариант Test-Driven Development'a, когда мы описываем как должно быть, а потом уже реализуем и проверяем, ну вполне логично, если я правильно понял...

Угу.

[Case]

Пример.
Есть 2 параллельные ветви разработки одного и того же продукта. Разошлись они совсем недавно из-за отличий в тонкостях ТЗ для двух разных заказчиков. Со временем ветви обязательно объединятся. Тест определенной функциональности немного отличается в деталях для одной ветви относительно другой. Мало того, сначала это был один тест, а теперь необходимо вести две его ветви. Можно бы сделать 2 теста - каждый на свою версию тестируемого приложения. Но т.к. отличия минимальны, а сам тест достаточно объемен, то удобнее вести 2 параллельные версии одного теста.

Вот другой аспект применения версионности тестов.

Ветки это не версии. "Версионность" это история изменения одного и того же теста со временем: скажем вам надо через месяц поднять версию теста месячной давности. Две ветки это бранчи, а не версии. То что вы рассказали это просто два разных теста, а не версии одного и того же теста. Другие примеры есть? :)

[YuP]

Ветки это не версии. "Версионность" это история изменения одного и того же теста со временем: скажем вам надо через месяц поднять версию теста месячной давности. Две ветки это бранчи, а не версии. То что вы рассказали это просто два разных теста, а не версии одного и того же теста. Другие примеры есть? :)

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

Ну не стоит ведь утверждать, что два бранча одного и того же сишного исходника - это уже два разных исходника.. Или что это "не версии" одного и того же исходника.. А что же это тогда?
Или то, что применима к файлам кода оказывается не применимо к тестам? :)