Что есть план тестирования и зачем он нужен

Как вы понимаете, что такое план тестирования?
Зачем он нужен?
Когда его нужно использовать?
Какую пользу мы можем извлечь, имея на руках план тестирования?
А не является этот план всего лишь бумажкой, отпиской, которую просто нужно сделать?
Получается, что мы намечаем себе план о том, что и когда будем тестировать, каким способом. Спрашивается, зачем?
Не будет ли план тестирования перечислением всех функций разрабатываемой системы с указанием того, когда мы должны проверить определенную часть системы, функцию?

Помогите разобраться, посоветуйте литературу

План может быть для галочки, а может быть и для пользы.

Польза:
* Возможность проанализировать риски и заранее их митигировать
* Возможность обосновывать что-либо руководству
* Возможность заранее подумать "о, тут будет задница, как бы это лучше сделать?"
* Возможность бронировать ресурсы, железки, договариваться с людьми
* Возможность согласовывать свои действия с другими группами, обычно и разработчики и РМы и аналитики, глядя в ТП, дают массу дельных советов/комментариев, влияющих на последующую работу
* Возможность в лобой момент посмотреть на статус и определить, нужно ли нам что-то корректировать

Ну и естественно, самый важный пункт - последний. Планирование - это не результат в виде плана, это ЕЖЕДНЕВНАЯ деятельность. Смотреть на план, медитировать, обмозговывать причины отклонения от плана и решения для них. Если план пишется, выкладывается куда-то и забывается, то это в лучшем случае 5% результата. Если он каждый день используется для корректировки движения, оценки статуса, нацеленности на результат, то он приносит мнооооого пользы :)

Как вы понимаете, что такое план тестирования?
Зачем он нужен?
Когда его нужно использовать?
Какую пользу мы можем извлечь, имея на руках план тестирования?
А не является этот план всего лишь бумажкой, отпиской, которую просто нужно сделать?
Получается, что мы намечаем себе план о том, что и когда будем тестировать, каким способом. Спрашивается, зачем?
Не будет ли план тестирования перечислением всех функций разрабатываемой системы с указанием того, когда мы должны проверить определенную часть системы, функцию?

Помогите разобраться, посоветуйте литературу

Первый день после каникул...Голова и моск в состоянии .

А потому тупо лезем в ГОСТ Р 51904-2002(ага, зря что ль люди писали?).
Смотрим.
1. Процесс планирования разработки ПО. Куда входит и процесс планирования интегральных процессов. Сиречь - и План тестирования тоже разрабатывается в ходе этого процесса.
Ну значит -- коли все ПО без плана разрабатывается, то вряд ли сам по себе план тестирования будет полезен ))). Т.е. чтоб польза была - надо увязать с Планами разработки ПО.
Собираем-ищем-узнаем все знания про план разработки ПО. У ПМ, у программистов, у начальства...
Ну исходя из этих знаний начинаем писать План тестирования.
По личному опыту - пока нормально управление конфигурацией не будет спланировано -- ну... с планом тестирования вряд ли что путевое выйдет.

2. Смотрим далее - что пишем в плане тестирования (верификации, квалификационного тестирования -- ну как там конкретно у Вас принято выделять и называть? ):
- Организация;
- Методы;
- Среда;
- Критерии;
- и тыпы.
Так вроде -все эти моменты определить надо? Да? Вроде логично? Ну значит и план нужен и логичен. И вроде как - всегда определяете?
Как-то прикидываете? Ну вот - а если написать все -- так и будет План тестирования.


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

Спасибо за ответ, Natalya!

Правильно ли я понимаю:

План тестирования представляет собой документ, подверженный постоянным изменениям. Он включает в себя информацию о том, что, когда и как будет тестироваться. Наличие рисков мы определяем тем, насколько опеределенная часть разрабатываемой системы протестирована (если неверно, то поправьте, пожалуйста).
Если, как вы указали, мы изменяем его каждый день ("Планирование - это не результат в виде плана, это ЕЖЕДНЕВНАЯ деятельность"), то будет ли он отличаться от ежедневного планирования (stand-up meeting) для тестировщиков?

Что значит "Возможность в лобой момент посмотреть на статус"? Это оценка того, какие части системы протестированы, а какие нет?

И наверное самое главное, с какого этапе развития проекта считается необходимым составлять планирование? С первых дней работы над проектом?

Можете ли вы посоветовать ресурс, где можно ознакомиться так сказать с эталонным вариантом плана?

План может быть для галочки, а может быть и для пользы.

Польза:
* Возможность проанализировать риски и заранее их митигировать
* Возможность обосновывать что-либо руководству
* Возможность заранее подумать "о, тут будет задница, как бы это лучше сделать?"
* Возможность бронировать ресурсы, железки, договариваться с людьми
* Возможность согласовывать свои действия с другими группами, обычно и разработчики и РМы и аналитики, глядя в ТП, дают массу дельных советов/комментариев, влияющих на последующую работу
* Возможность в лобой момент посмотреть на статус и определить, нужно ли нам что-то корректировать

Ну и естественно, самый важный пункт - последний. Планирование - это не результат в виде плана, это ЕЖЕДНЕВНАЯ деятельность. Смотреть на план, медитировать, обмозговывать причины отклонения от плана и решения для них. Если план пишется, выкладывается куда-то и забывается, то это в лучшем случае 5% результата. Если он каждый день используется для корректировки движения, оценки статуса, нацеленности на результат, то он приносит мнооооого пользы :)

Пример прямо из "сейчас". Я лопухнулась, да. Новый релиз ПО чтоб протестить нужен Новый Кабель (такая куча проводов соединенная вместе), чтоб подключить всякие имитаторы. В старом кабеле то ли двух, то ли трех проводов не хватает (((. Ну ... да, я осознала, что кабель новый нужен, на бумажках (сиречь в Плане) не записала, вовремя не озадачилась. Результат -- сидю, ждю кабеля из цеха , умничаю тут про планирование... А релиз между прочим стоит, а программисты ворчат.....

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

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

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

Правильно ли я понимаю:

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

Да, именно так.

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

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

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

будет ли он отличаться от ежедневного планирования (stand-up meeting) для тестировщиков?

Не у всех внедрена подобная практика
Чем занимаетесь на стенд-апах вы?
Обычно там три вечные вопроса "что я делал вчера? Что сделаю сегодня? Какие проблемы возникли?"

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

Что значит "Возможность в лобой момент посмотреть на статус"? Это оценка того, какие части системы протестированы, а какие нет?

И это тоже - сколько протестировано, сколько еще осталось?

И наверное самое главное, с какого этапе развития проекта считается необходимым составлять планирование? С первых дней работы над проектом?

Именно! Тестируем ТЗ и пишем\рисуем план :)

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

Риски - неотъемлимый атрибут плана. Если верить PMBoK'у, то с них и начинается планирование.
"А что, если нам железо вовремя не дадут?"
"А что, если сборка будет нерабочая и мы не сможем тестировать?"
"А что, если поменяется дизайн, а у нас уже автотесты по текущему интерфейсу бегают?"

И т.д. И заранее думаем, что с этими рисками делать, как не допустить, как уменьшить негативное влияние и т.д.

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

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

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

мм.м.. вопрос не в том, что за тема развивается.
То, что план пишется в т.ч. и для прикидок по трудозатратам - это ммм... очевидно.

Вопрос другой - какие риски?
Что имеется в виду под рисками во фразе "Возможность проанализировать риски и заранее их митигировать"?

лучше б на примере.

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

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

Если, как вы указали, мы изменяем его каждый день ("Планирование - это не результат в виде плана, это ЕЖЕДНЕВНАЯ деятельность"), то будет ли он отличаться от ежедневного планирования (stand-up meeting) для тестировщиков?

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

Что значит "Возможность в лобой момент посмотреть на статус"? Это оценка того, какие части системы протестированы, а какие нет?

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

Мы часто говорим "тут мы опаздали потому, что сборки вовремя не было", или ещё ищем отмазки.
Камон! Это наша ответственность, учитывать такие риски и готовиться к ним.

И наверное самое главное, с какого этапе развития проекта считается необходимым составлять планирование? С первых дней работы над проектом?

С первых, да. Только не надо пытаться писать тонны мукалатуры, хороший тест-план должен быть маленьким, чтобы и редактировать было удобно, и наглядно статус отражал, и чтобы его точно все могли дочитать до конца. Причём желательно минут за 5 :)

Можете ли вы посоветовать ресурс, где можно ознакомиться так сказать с эталонным вариантом плана?

У меня раньше были школа тест-менеджеров и целый тренинг по планированию, там мы настоящие тест-планы писали, но пока их нет. Вот здесь я очень поверхностно что-то выписала и добавила шаблоны тест-планов: http://wiki.software...u/Тест-план_(NR)

Скажу честно, мне шаблонные ТП не нравятся, они слишком большие, в них много бесполезной воды. Всё хочу выложить свой шаблон и всё не хватает времени :))

Спасибо всем за активное участие в обсуждении!

Правильно ли я понимаю:

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

Нет, не правильно.

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

Определение: План есть декомпозиция конечной цели на промежуточные результаты
Если хотите более академическое определение:

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

Написание плана всегда следует начинать с формулировки конечной цели (смотри "Базовые термины"). Достаточно понятным языком процесс планирования изложен в блоге Влада Балина http://gaperton.livejournal.com/

Навскидку рекомендую эти статьи:
http://gaperton.live...ление проектами

Очень важный момент. В отличии от "расписания", "план" (в том числе план тестирования) весьма статичная вещь. Очень даже может быть, что план не изменится в течении всего проекта. В отличии от расписания, которое меняется каждый день.

Еще немного линков:
http://gaperton.live....com/25093.html
http://gaperton.live....com/30325.html
http://gaperton.live....com/48196.html

Ну и:
http://blog.shumoos.com/archives/251

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

Риски - неотъемлимый атрибут плана. Если верить PMBoK'у, то с них и начинается планирование.
"А что, если нам железо вовремя не дадут?"
"А что, если сборка будет нерабочая и мы не сможем тестировать?"
"А что, если поменяется дизайн, а у нас уже автотесты по текущему интерфейсу бегают?"

И т.д. И заранее думаем, что с этими рисками делать, как не допустить, как уменьшить негативное влияние и т.д.

РМ - не ПДД. Сиречь не догма.
В общем и целом -- SALar все толково разложил.

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

Ну залезла еще в ГОСТ РВ 0019-001-2006 г.
Сей труд предлагает отдельным пунктом выделять План-график, где идентифицируются контрольный точки и "временной график их выполнения".
Риски тоже предлагается в отдельном пункте выделить.

Опять - ГОСТ, как и РМ -- не ПДД (сиречь не догма). На мой вкус -- SALar логичней расписал.

Т.е. - риски - отдельным документом. Сроки - отдельным расписанием.
Так оно более работоспособно!

Отличия между planning, scheduling и estimation очень хорошо описал Макконел в своей книге о планировании (в значении estimation) софтверных проектов.
Когда люди пытаются планировать без скедулинга и эстимейшна, получаются мечты, выписанные на бумаге.

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

Ну залезла еще в ГОСТ РВ 0019-001-2006 г.
Сей труд предлагает отдельным пунктом выделять План-график, где идентифицируются контрольный точки и "временной график их выполнения".
Риски тоже предлагается в отдельном пункте выделить.

Опять - ГОСТ, как и РМ -- не ПДД (сиречь не догма). На мой вкус -- SALar логичней расписал.

Фрося, лучше грыздь не ГОСТ-ы (они просто не успели за развитием науки управления), а разработки группы Щедровицкого. В частности, рекомендую Анисимов О.С. Основы методологии. – М., 1994.
PMBOK, на мой скромный взгляд, так же отстает (примерно на четверть века) от наработок советской школы управления. Единственная проблема - уровень сложности материала там зашкаливающий.

PS.
www.fondgp.ru
http://akmeolog.narod.ru/price.html

PSS. И ни в коем, ни в коем случае не путайте и не смешивайте "planning", "estimation" и "scheduling".

Отличия между planning, scheduling и estimation очень хорошо описал Макконел в своей книге о планировании (в значении estimation) софтверных проектов.
Когда люди пытаются планировать без скедулинга и эстимейшна, получаются мечты, выписанные на бумаге.

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

ээ... Топик стартер спрашивал о конкретном документе - План тестирования.

А сроки и исполнителей пофамильно можно расписывать в отдельном плане-графике. Ок?
Так просто удобней)).

Фрося, лучше грыздь не ГОСТ-ы (они просто не успели за развитием науки управления), а разработки группы Щедровицкого. В частности, рекомендую Анисимов О.С. Основы методологии. – М., 1994.
PMBOK, на мой скромный взгляд, так же отстает (примерно на четверть века) от наработок советской школы управления. Единственная проблема - уровень сложности материала там зашкаливающий.

PS.
www.fondgp.ru
http://akmeolog.narod.ru/price.html

PSS. И ни в коем, ни в коем случае не путайте и не смешивайте "planning", "estimation" и "scheduling".

Я их (ГОСты ) не грызу. Я в соответствии с ними продукцию военпреду представляю ))).
Ну те, что я привела - не так уж устарели. Чай, этого века ))).

За ссылки - спасибочки. Гляну.

PSS. И ни в коем, ни в коем случае не путайте и не смешивайте "planning", "estimation" и "scheduling".

ай. У меня попросту - все расписано ))).
В ГОСтах - в смысле ))).
Типа - есть документ "План верификации программного обеспечения".
В каковой входит
п. 6.2 Распределение ответственности
п. 6.3 План график и контроль его выполнения
п. 6.4 Риски и непредвиденные ситуации.

Причем пункты сии можно выносить в отдельный документ - - не запрещено)).

ээ... Топик стартер спрашивал о конкретном документе - План тестирования.

А сроки и исполнителей пофамильно можно расписывать в отдельном плане-графике. Ок?
Так просто удобней)).

Как скажете, но и IEEE и RUP содержат график (schedule) с оценками затрат (estimations) как часть тест-плана, ГОСТ тоже... Видимо, это не просто так?