Зачем нужен тест-план?

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

В описаной ситуации - уже есть тесты на 100% покрывающие функционал и есть время прогонять их на каждом билде - тест план наверно не нужен (хотя имхо описана волшебная ситуация).
Обычно он нужен для 2х основных вещей:
- понять что, как, когда будет/не будет проверяться (составить календарный план, определится с инструментарием и тд.)
- донести эту информацию до продюсера/команды
Так что нужен он и тестировщику, и продюсеру. Заказчик с вероятностью 90% всё равно ничего не поймёт, ему он нужен только для наивной уверенности, что мы знаем что делаем :)

Если ситуация выглядит реально, как вы описали, а тест план требуют - ну опишите там например: типы тестов, график работ на итерацию и формат отчётных документов.

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

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

Судя по всему, под "тест-планом" мы подразумеваем очень разные вещи :)
В моём случае тест-план не содержит ни одного документа уровня тест-кейса или чек-листа. Это просто план производства работ. Практически Technical Design Document от тестирования (что и как) + production schedule (когда) в одном флаконе.

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

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

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

В моём случае тест-план не содержит ни одного документа уровня тест-кейса или чек-листа. Это просто план производства работ.

+1!

Из книги Ромы Савина "Тестирование Dot Com"
"... Что такое тест-план? Если вы спросите тестиировщиков разных компаний о том, что идет под именем 'тест-план' в их компаниях, то ответ часто будет варьироваться:
- иногда тест-планом называют тест-комплект,
- в других случаях тест-планом называют пару мыслей о тестиировании,набросанных на полях журнала 'Playboy',
- в третьих случаях тест-планом называют текстовый документ, содержащий выдержки из спека, глядя на которые и проводиться тестирование(такое тоже бывает сплошь и рядом),
- есть еще и четвертые , и пятые случаи."

>В моём случае тест-план не содержит ни одного документа уровня тест-кейса
>или чек-листа. Это просто план производства работ. Практически Technical >Design Document от тестирования (что и как) + production schedule (когда) в >одном флаконе.

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

Ок все верно, но у нас в компании так сложилось что написание тестпланов пошло двумя путями:
1 - это судя по вышесказаному вовсе не тестпланы это документы excel с набором тест кейсов;
2 - некий гибрид он содержит в себе стратегию - кто, что, когда + набор тест кейсов определенной функциональности к примеру некий olympic - деинсталяция/инсталляция, простейший workflow.
Последний путь оказался достаточно эффективным для тех целей которые я описал раньше

Это не только у вас, более того это иногда даже удобно, главное не путать как что называется, иначе обсуждение будет вестись как на разных языках.

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

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

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

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

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

коллеги, зачем спорить. Есть разные определения тест-плана в разных стандартах - это могут быть сценарии тестирования, это может быть также календарный план, а также стратегия. Вообще очень странный вопрос о том что есть тест-план. На этот вопрос надо в каждом проекте отвечать и ответ зависит от следующих вещей:
1. процесс тестирования в компании или подразделении (как например оформляются стратегические и тактические планы по тестированию)
2. персонал (есть ли например стажеры -тестировщики)
3. проработанность требований и участие заказчика (может заказчик хочет посомтреть на план до начала тестирования - тогда требования к нему определяет он сам)
4.сложность и новизна объекта тестирования
и т.п.

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

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

В зависимости от обстановки тест планы могут быть формальными и неформальными. Чем выше критичность проекта (life critical или mission critical) тем больше доля формализма. В подобной обстановки планы обычно пишуться под как-то стандарт и форма их определена.

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

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

----
Best Wishes,
Vladimir

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

Если не сложно - приведите определения, в какойметодологии тест план подразумевает набор тестов? Пару раз слышал упоминание, но пока не встречал.

http://en.wikipedia....are_development
http://www.klariti.c...-Template.shtml
http://www.sqatester...estplansmpl.htm

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

...зачем нужен тест-план? и для кого он делается? для тестировщика, босса, заказчика? или просто потому что так надо? :)
интересуют как общие мысли на тему так и примеры из личной практики. Спасибо.

Часто он не нужен. Еще чаще его невозможно написать. Дело втом, что тест план должен базироваться на планах разработки требований, построения архитектуры и плане кодирования. И нужен он для разработки "плана разработки ПО", который кроме вышеперечисленного опирается на планы подготовки документации пользователя, подготовки контента и план развертывания. Иначе получается диалог глухого со слепым:
- Что вы будете делать 25 апреля?
- Ну так, это, тестировать будем.
- А какой модуль вы будете тестировать и какие виды тестов вы будете проводить?
- Ну так, это, что дадут.
- А что дадут?
- Так программисты сами не знают.
- А кто знает?
- ...
Часто, этого не знает никто.
Ну, и зачем план? Чтобы его не выполнять? Тогда пишите что хотите.

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

Вот здесь я не согласен. "Стратегия тестирования" вполне может быть самостоятельным документом, на основании которого делается тест план.
Пример тест плана:

Иванов  12.04 - 17.04 проводит объемное тестирование модуля биллинга
Петров    10.04 - 20.40 проводит функциональное тестрование модуля "Личный кабинет"

Пример стратегии:

* Тестирование целостности данных проводится только после завершения позитивных функциональных тестиов.
* Объемное тестирование должно быть проведено в начальной стадии проектирования.
* Одновременно с функциональными тестами проводятся тесты юзабилити.
* В качестве способов обеспечения применяются: ...

Вот примерно так.

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

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

... сужденья черпают из забытых газет, времен Очаковских и покоренья Крыма.

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

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

С чем ты не согласен, Сергей? Да пусть будет хоть пачка документов, суть артефакта не меняется.

Об остальном - отдельным постом.

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

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

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

1. В чём ошибочен РУП?
2. В чем устаревшесть модели прецендентов РУПа? Что сейчас не работает или работает совсем не так или не может работать как описано?
3. Какие именно связи между артефактами нарушены или требуется их переадресация?
4. Что с инструментами?

Мне в самом деле интересна тема, я далеко не адепт РУПа, во многом он меня устраивает как структирурованная Библиотека проектных проктик,во многом не устраивает, но лучше я пока не видел и с тем что ты говоришь не согласен.

С чем ты не согласен, Сергей? Да пусть будет хоть пачка документов, суть артефакта не меняется.

Об остальном - отдельным постом.

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

Просто в голове нужно держать, что это немного разные вещи. И сугубо IMHO:
Вместо стратегии тестирования более разумно написать стратегию обеспечения качества продукта, в коей глава о тестировании займет свое законное место. А вместо "плана тестирования" имеет смысл создать план проекта.

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

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

... сужденья черпают из забытых газет, времен Очаковских и покоренья Крыма.

Вы зря ругаетесь!
Моя фраза про RUP совершенно не высказывает ни моей приверженности к нему, ни антипатии. Это просто констатация факта того, что нас путает, и почему под тест-планом порой понимают тест-кейсы.

А вместо "плана тестирования" имеет смысл создать план проекта.

А если компания занимается исключительно обеспечением качества, ей-то зачем план проекта?

Стратегия и план график - это разные артефакты. Они содержат разные вещи, готовятся в разное время, и, возможно, разными людьми.

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