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

[yamayka80]

И еще надо заметить, что вопрос был "Зачем и для кого нужен тест-план?".
Как мне кажется, ответ получен.
Как то: сказано, что такое тест-план, для чего он нужен, что содержит, и что разные его части предназначены для разных членов команды, в том числе и для заказчика.

[barancev]

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

Не устаю ссылаться на стандарт IEEE 829 -- см. http://forums.softwa...?showtopic=2675, последний пост.

[SALar]

Сергей, тема очень интересная - я пользуюсь РУП-ом ибо нет ничего подробнее и ничего обширнее. Беру РУП и отсекаю ненужное... то бишь адаптирую.

А вот в остальном - "давайте разбираться" :)

Обсуждение вышло за рамки темы, поэтому вынес ответ в отдельную ветку .

[vitc]

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

Не устаю ссылаться на стандарт IEEE 829 -- см. http://forums.softwa...?showtopic=2675, последний пост.

Хотел бы добавить, что хотя IEEE 829 весьма актуальный документ, он довольно таки старый - 1998 год, и довольно тяжеловесный. Не стоит пытаться реализовать весь объем документации, приведенный в стандарте, только ради соответствия ему.

Несмотря на достаточно однозначное определение тест-плана на wiki и в IEEE 829, он может преследовать разные цели. По крайней мере две: первая - как самостоятельный продукт, который передается заказчику. Во втором - как внутреннее средство для организации и качественного выполнения тестирования программного продукта компании. Очевидно, что в каждом случае требования к тест-плану будут различными.

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

Есть так же мнение, что при правильной организации процессов разработки, многие, если не все, секции тест-плана могут быть сгенерированы автоматически из остальной документации/данных проекта.

[Plut]

.... Структура и содержание тест-плана должны соответствовать процессу и методологии тестирования, принятым в компании.

Есть так же мнение, что при правильной организации процессов разработки, многие, если не все, секции тест-плана могут быть сгенерированы автоматически из остальной документации/данных проекта.

Все абсолютно верно имхо.

[Case]

Есть так же мнение, что при правильной организации процессов разработки, многие, если не все, секции тест-плана могут быть сгенерированы автоматически из остальной документации/данных проекта.

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

[Plut]

Есть так же мнение, что при правильной организации процессов разработки, многие, если не все, секции тест-плана могут быть сгенерированы автоматически из остальной документации/данных проекта.

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

Под автоматически генерацией надо понимать следующее: Вы берете соответствующий материал из Функциональных Спецификаций или из Дизайна - и создаете тест-план.
Причем создатель Тест Плана может "взятый материал" ЧУТЬ - ЧУТЬ творчески переработать либо оставить вообще неизменным.


p.s: а что за система трекинга требований ?

[Case]

Под автоматически генерацией надо понимать следующее: Вы берете  соответствующий материал из Функциональных Спецификаций или из Дизайна - и создаете тест-план.

Я _как человек_ беру текст спецификации и делаю тест план? Где тут автоматизация?

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

Причем создатель Тест Плана может "взятый материал"  ЧУТЬ - ЧУТЬ творчески переработать либо оставить вообще неизменным.

Вопрос тот же - создатель это тул или человек?

p.s: а что за система трекинга требований?

Да любая, не суть важен производитель.

[SALar]

> Зачем нужен тест-план?, происки подлых бюрократов? :)
На маленьких проектах (до человекогода) тест-план НЕ НУЖЕН. Как правило. Не нужно бюрократию разводить.

[KaNoN]

Под автоматически генерацией надо понимать следующее: Вы берете  соответствующий материал из Функциональных Спецификаций или из Дизайна - и создаете тест-план.

Я _как человек_ беру текст спецификации и делаю тест план? Где тут автоматизация?

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

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

[KoPBuH]

тест план может быть и не нужен(на маленьких проектах), но если он есть, то клиенту приятно :-) и часто именно клиент запрашивает всю возможную документацию

[Case]

На маленьких проектах (до человекогода)  тест-план НЕ НУЖЕН. Как правило. Не нужно бюрократию разводить.

Почему это бюрократия сразу? :) План проекта тоже не нужен? Требования фиксировать?

[Case]

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

Генератор чего-то в принципе не проблема, а вот генератор тест-плана, проблема. Подозреваю что вы говорите о генерации наборов тестов, а не о тест плане - верно?

Задача сводится к распарсиванию строк, извлечению нужных данных в нужные структуры и вывод всех накопленных данных в необходимом формате. По такому принципу в Яве хелп генерится стандартными средствами.

Блин :) KaNoN, и вы туда же? :)

Давайте с конкретными примерами, а?
http://software-test...esting_news.htm вот, например, Алексей Баранцев показал для конкретного маленького проектика он делал бы тест-план. Расскажите, а ещё лучше покажите мне - как надо строго-строго описать приведённые требования и сгенерировать машинно какой-то из разделов тест-плана?

[KaNoN]

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

Генератор чего-то в принципе не проблема, а вот генератор тест-плана, проблема. Подозреваю что вы говорите о генерации наборов тестов, а не о тест плане - верно?

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

Задача сводится к распарсиванию строк, извлечению нужных данных в нужные структуры и вывод всех накопленных данных в необходимом формате. По такому принципу в Яве хелп генерится стандартными средствами.

Блин :) KaNoN, и вы туда же? :)

Давайте с конкретными примерами, а?
http://software-test...esting_news.htm вот, например, Алексей Баранцев показал для конкретного маленького проектика он делал бы тест-план. Расскажите, а ещё лучше покажите мне - как надо строго-строго описать приведённые требования и сгенерировать машинно какой-то из разделов тест-плана?

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

Тот же перечень тестируемых и нетестируемых модулей (Test Coverage/Scope) можно получить по следующему принципу. В тесткейсах где-то в заголовке завести (если не было) поле вроде Component, которое описывает ту часть приложения, которая затрагивается данным тесткейсом. На генератор ставится фильтр по компонентам. Соответственно, компоненты, которые по фильтру проходят в план, ставятся в перечень тестируемых компонентов, остальные - в перечень нетестируемых.

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

Специальные средства, как правило, можно зафиксировать либо предоставить выбор из списка.

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

Поставка - по шаблонам.

Требования к тестовому окружению собираются по всем тесткейсам. В тесткейсах обычно предусмотрено поле "Configuration". Если его содержимое заполняется в определенном формате (то есть четко выделяются поля для основных характеристик, как частота процессора, память, свободное место на диске, браузер и т.п.), то ничто не мешает получить всю совокупность требуемых характеристик (как правило они одинаковы для всех тесткейсов за исключением некоторой специфики, которая все равно попадет в совокупность).

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

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

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

[SALar]

тест план может быть и не нужен(на маленьких проектах), но если он есть, то клиенту приятно :-) и часто именно клиент запрашивает всю возможную документацию

Если клиент запрашивает какой то артефакт, то этот артефакт переходит из разряда "рабочий продукт" в разряд "конечный продукт". И далее разговор будет совсем другой.
--------------------------------------------------
- Так, клиент готов заплатить:
150 000$ за исходный код
700$ за стратегию тестирования
1200$ за тест план
43 400$ за дизайн тестов
- Каковы трудозатраты на тест план?
- 10-20 человеко-часов.
- В худшем случае получается 60 баксов в час. Делаем.
--------------------------------------------------
В этом примере есть натяжки.
* Обычно контракт идет одной суммой, а клиент обговаривает, что он хочет увидеть в поставке. Разбивку как правило не делают.
* Я полагаю, что тест план для внутреннего использования и тест план, как часть конечного продукта отличаются по цене.

Важно другое. Если в контракте прописана поставка некоего совершенно ненужного для разработки продукта артефакта, например, такого как "Описание информационной базы" по ГОСТ, то его придется делать. За это деньги платят. То, что этот артефакт может мешать разработке, с этим придется мириться.

А иногда: "Гарантии (документы) оставь себе. А мне дай нефть (продукт)".

[SALar]

На маленьких проектах (до человекогода)  тест-план НЕ НУЖЕН. Как правило. Не нужно бюрократию разводить.

Почему это бюрократия сразу? :) План проекта тоже не нужен? Требования фиксировать?

План проекта довольно часто не нужен.
Требования фиксировать тоже иногда не нужно.

Только вот отличить ситуацию "когда нужно", от "когда не нужно" не так просто.

Не, ну это же классика кун-фу:

Сначала ты не знаешь, что нельзя делать то-то
Потом знаешь, что нельзя делать то-то
Потом ты понимаешь, что иногда таки можно делать то-то
Ну а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться желаемого, и все из них практически равноправны.
Когда тебя спрашивают "как мне добиться желаемого", ты быстро перебираешь в уме эти шестьдесять шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: "вообще-то, главное — гармония."
На вопрос обиженных учеников: "а как ее добиться?", ты говоришь: "никогда не делайте то-то".

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

Кроме того, в РУПе совершенно отсутствуют люди.

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

PS. Заметим, что Алексей говорит:

Честно признаться, для таких маленьких задач я никогда не пишу план тестирования. Во-первых, потому что его легко держать в голове и потому нет необходимости фиксировать на бумаге. Во-вторых, потому что для маленьких задач времени и сил на написание плана уйдёт едва ли не больше, чем на все остальные работы по тестированию. Наконец, потому что по таким задачам нет строгой отчётности, и никто не спросит меня, выполнил ли я план.

И он таки прав.

[Plut]

Под автоматически генерацией надо понимать следующее: Вы берете  соответствующий материал из Функциональных Спецификаций или из Дизайна - и создаете тест-план.

Я _как человек_ беру текст спецификации и делаю тест план? Где тут автоматизация?


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

Причем создатель Тест Плана может "взятый материал"   ЧУТЬ - ЧУТЬ творчески переработать либо оставить вообще неизменным.

Вопрос тот же - создатель это тул или человек?

p.s: а что за система трекинга требований?

Да любая, не суть важен производитель.

Если документация на проект хорошо сделана(т.е есть например хорошая Функциональная спецификация[ФС]\Спека), то для составление тест Планов можно делать так: брать цитаты из ФС и заносить их в какую-нибудь систему(Ворд, Эксель, корпоративную систему трекинга, и.т.д)
Группировать такие тест Планы можно по разделам из ФС.
Т.е труд - минимальный, необходимо лишь разобраться с самой ФС.

Именно это я имел ввиду, когда соглашался с QUOTE.

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

[KaNoN]

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

Другое дело, что не всегда на эти задачи найдется время и люди.

[vitc]

Долго не заходил, удивился, какой отклик вызвала идея об автоматизации тест-плана :) Спасибо KaNoN за развитие этой идеи - во многом я полностью согласен.

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

Согласен с этим утверждением. Как я понимаю, в этом контексте мы говорим о test specification - документе, перечисляющем все тесты, требующиеся для конкретного набора тестируемых компонент. Если есть атрибуты, грамотно расставленные на тестах, можно генерировать хорошо структурированные спецификации, причем, даже с разной структурой под разные задачи. Что существенно упрощает поиск дыр в тестовом покрытии.
Дальнейшее развитие этой идеи могло бы быть таким: если в проекте используется инструментарий вроде SpecSharp, то можно сгенерировать сами тесты.

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

Тот же перечень тестируемых и нетестируемых модулей (Test Coverage/Scope) можно получить по следующему принципу. В тесткейсах где-то в заголовке завести (если не было) поле вроде Component, которое описывает ту часть приложения, которая затрагивается данным тесткейсом. На генератор ставится фильтр по компонентам. Соответственно, компоненты, которые по фильтру проходят в план, ставятся в перечень тестируемых компонентов, остальные - в перечень нетестируемых.

Лучше фильтровать содержимое билда приложения, а не на тесты. Тогда можно будет сравнивать test plan и test spec на предмет покрытия первого вторым. И, опять же, находить дыры в тестировании.

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

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

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

[melan]

В самом простом случае тестплан представляет собой несколько тест кейсов с общей функциональностью.

если я когда-нибудь найду человека, который первым пустил эту утку

Тест план есть артефакт определющий стратегию тестирования: кто,что, когда, но не *как*. Как описывается в тест кейсах.

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

И взять, например, Rational TestManager. Там под тест-планом подразумавается тоже совсем не то, что мы тут описываем.

У нас в компании есть 2 документа создаваемые последовательно: тест план и тест сет. Тест план - это план планом: с описанием областей тестирования, сроков, рисков, расписания и прочего. Тест сет - набор тесткейсов. По текущим инструкциям тест сет создается после появления тест плана и содержит тесты необходимые для выполнения задач поставленных в плане. И никакой путаницы