Господа, доброго времени суток.

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

Спасибо.

Осталось только уточнить, что ты имеешь ввиду под планом тестирования.
Для меня это именно план.
Т.е. в него входит описание того что тестируем, когда, какими средствами,
какими методики планируется использовать и кто в вообще этим будет заниматься.
Т.е. туда НЕ входят сами тестовые ситуации (test cases).
Такой план — это вещь в целом стандартная и пишется один раз,
а потом просто слегка перерабатывается от проекта к проекту.

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

Что тебя действительно интересует?

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Господа, доброго времени суток.

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

ЩЕ>Спасибо.

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

Здравствуйте, AlikGut, Вы писали:

AG> ну план не план, а есть такая архиполезная вещь как smoke-test и ночной билд. эта штука должна проводиться с каждым новым билдом проекта и покрывать всю базовую функциональность по спецификации. в идеале это ночной автобилд — в конце дня, все кодеры заливают код куда-нибудь, и после этого проводится найтбилд, это какбы пульс жизни проекта — весь новый код вжился и подружился с остальным. то есть, если найтбилд собрался — это щастье.
AG> с утреца тестер проводит этот smoke-test и если он прошел, то это еще больше щастья — проект живет и дышит. баги которые валят smoke-test должны быть зафиксены немедленно. эти две вещи в купе — очень и очень полезны, особенно для выявления регрессов. можно еще проводить недельные смок-тесты — проявите немного фантазии, составте тесты, выявите идальное отношение по (времени на тест/покрытию функционала) и удачи!

Есть средства Continuous Integration, которые автоматом проверяют изменения в проекте (cvs, vss и т.п.), берут версию на сборку, собирают, производят Unit-тестирование (тоже самое, что и smoke-test?) и сразу выдают результат.

Я работаю с CruiseControl.NET. Можно поискать в интернете по словам Continuous Integration.

Здравствуйте, stasukas, Вы писали:

S>Есть средства Continuous Integration, которые автоматом проверяют изменения в проекте (cvs, vss и т.п.), берут версию на сборку, собирают, производят Unit-тестирование (тоже самое, что и smoke-test?) и сразу выдают результат.

нее. юнит-тест это далеко не смок-тест — абсолютно разные вещи. обратное тоже верно и даже более того, машина никогда не заменит тестера — потому как машина не может думать и ей не может повезти/не повезти в юзкейсе на дефект никак нельзя сравнивать эти тесты.

Здравствуйте, Щербатов Евгений, Вы писали:

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

Вот что меня всегда удивляет, так это то, что люди постоянно спрашивают, что такое план тестирования и как он выглядит, но ни разу не видел, чтобы кто-нибудь справшивал, что такое план разработки и как оформляется он. То ли все без плана работают, то ли про план разработки все всё понимают. Да одинаковые они! Только разные работы планируются, вот и вся разница.

План тестирования -- это план того, что, как, когда и какими силами предполагается тестировать. И составляет его руководитель группы тестирования, это план работы его группы. Как именно оформляет? В соответствии с принятыми в организации традициями -- в MS Project, или в MS Excel, или на листке бумаги, или просто в голове держит.

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

Вот и всё. План -- это просто план, даже если он план тестирования.

Очень часто планом тестирования называют сами тесты.
Потому такая путаница и возникает.

Здравствуйте, Аноним, Вы писали:

А>Осталось только уточнить, что ты имеешь ввиду под планом тестирования.
А>Что тебя действительно интересует?

Под планом тестирования я имелл ввиду именно описание тестовых ситуаций, а не то кто это будет делать и в какие сроки.

Здравствуйте, AlikGut, Вы писали:

AG>Здравствуйте, stasukas, Вы писали:

S>>Есть средства Continuous Integration, которые автоматом проверяют изменения в проекте (cvs, vss и т.п.), берут версию на сборку, собирают, производят Unit-тестирование (тоже самое, что и smoke-test?) и сразу выдают результат.

AG> нее. юнит-тест это далеко не смок-тест — абсолютно разные вещи. обратное тоже верно и даже более того, машина никогда не заменит тестера — потому как машина не может думать и ей не может повезти/не повезти в юзкейсе на дефект никак нельзя сравнивать эти тесты.
Если смок-тест является автоматизированным (с использованием стороннего тестирующего ПО), то это разновидность Unit-теста, в том числе и для интерфейса пользователя. Ну а Unit-тесты пишут люди, так что учесть все аспекты проблем не составляет. Периодически, при проявлении нестандартной ситуации, можно дополнить набор тестов для новой конкретной ситуации. В моем случае огромная часть труда тестировщика выполняется автоматизированно при сборке новой версии, а так же видно, какие изменения привели к фатальным результатам. Тестировщику иногда трудно вручную пройти весь набор тестов, а тут колоссальное избавление от рутинной работы.

А>>Осталось только уточнить, что ты имеешь ввиду под планом тестирования.
А>>Что тебя действительно интересует?

А>Под планом тестирования я имелл ввиду именно описание тестовых ситуаций, а не то кто это будет делать и в какие сроки.

Давайте тогда сначала немного проясним терминологию. И чтобы не быть голословными, возьмём за основу что-нибудь реальное, например, стандарт IEEE 829 Software Test Documentation and Test Plans.

Итак, что же предлагает этот стандарт? Трёхуровненвая организация артефактов:
— план тестирования (test plan)
— дизайн тестов (test design)
— тестовый вариант (test case)

Первый из перечисленных уровней — организационная документация, следующие два уровня — техническая документация.

К сожалению, действительно в русском языке происходит путаница из-за того, что часто test design переводится как тест-план. Надо как-то с этим бороться, но пока приходится с этим жить. Действительно, дизайн тестов -- не лучший перевод, он тоже не слишком интуитивно понятен.

Ну ладно, так что же говорит нам стандарт IEEE 829 о назначении указанных трёх типов документов?

План тестирования описывает область тестирования, подходы, ресурсы и график. В частности, в нём указывается: что тестируется (программные компоненты), что при этом проверяется (цели, objectives), выполняемые задачи (tasks), персонал и ответственности, риски.

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

Тестовый вариант, или простейший тест (test case) — это описание отдельной проверки из числа описанных в дизайне тестов.

Таким образом, в этой терминологии, требуется не план, а дизайн тестов. Вообще-то народ неохотно делится такого рода темплейтами и примерами, потому что начальство этого не одобряет. Но можно почитать обсуждение, из которого несложно составить представление о том, как это делают люди, здесь: http://forums.software-testing.ru/index.php?act=ST&f=68&t=1284

Здравствуйте, stasukas, Вы писали:

S>Если смок-тест является автоматизированным (с использованием стороннего тестирующего ПО), то это разновидность Unit-теста, в том числе и для интерфейса пользователя. Ну а Unit-тесты пишут люди, так что учесть все аспекты проблем не составляет. Периодически, при проявлении нестандартной ситуации, можно дополнить набор тестов для новой конкретной ситуации. В моем случае огромная часть труда тестировщика выполняется автоматизированно при сборке новой версии, а так же видно, какие изменения привели к фатальным результатам. Тестировщику иногда трудно вручную пройти весь набор тестов, а тут колоссальное избавление от рутинной работы.

стопики-стопики. может я чего-то не догоню, но можно ли заставить стороннее ПО (без соответсвующей поддержки таких фич в моем ПО — там всяких скриптов или т.п.) например открыть документ, применить какой-нибудь тул или выполнить какуб-нибудь команду, открыть свойства чего-нибудь и потом удалить/изменить свойство??
а уже о рутине ничего не поделать — прямая работа тестера — полчаса-час в день на смок-тест это не страшно. зато качество ПО будет принипиально на ином уровне...

Здравствуйте, AlikGut, Вы писали:

AG> стопики-стопики. может я чего-то не догоню, но можно ли заставить стороннее ПО (без соответсвующей поддержки таких фич в моем ПО — там всяких скриптов или т.п.) например открыть документ, применить какой-нибудь тул или выполнить какуб-нибудь команду, открыть свойства чего-нибудь и потом удалить/изменить свойство??

Короткий ответ: в большинстве случаев можно.

Здравствуйте, Alexei Barantsev, Вы писали:

AB>Здравствуйте, AlikGut, Вы писали:

AG>> стопики-стопики. может я чего-то не догоню, но можно ли заставить стороннее ПО (без соответсвующей поддержки таких фич в моем ПО — там всяких скриптов или т.п.) например открыть документ, применить какой-нибудь тул или выполнить какуб-нибудь команду, открыть свойства чего-нибудь и потом удалить/изменить свойство??

AB>Короткий ответ: в большинстве случаев можно.
Да, есть достаточно мощные средства произвести такое тестирование. Достаточно один раз записать последовательность действие пользователя и воспроизвети тестирование в дальнейшем. К сожалению, подобные системы от коммерческих производителей очень дороги. Свободных я не встречал (не поделитесь ссылками?).

Здравствуйте, stasukas, Вы писали:

S>Да, есть достаточно мощные средства произвести такое тестирование. Достаточно один раз записать последовательность действие пользователя и воспроизвети тестирование в дальнейшем. К сожалению, подобные системы от коммерческих производителей очень дороги. Свободных я не встречал (не поделитесь ссылками?).

Если речь идёт о record-n-play инструментах, могу назвать несколько бесплатных для Java:
http://marathonman.sourceforge.net/
http://abbot.sourceforge.net/
http://pounder.sourceforge.net/
Они зачастую менее стабильны, чем коммерческие, да и возможностей поменьше, но набрав обойму из нескольких можно получить практически всё, что необходимо.

Ещё больше таких, которые позволяют писать программы, эмулирующие действия с элементами графического интерфейса на весьма высоком уровне. Выбирать, например, здесь: http://tejasconsulting.com/open-testware/feature/gui-test-driver-survey.html

Здравствуйте, Alexei Barantsev, Вы писали:

AB>Если речь идёт о record-n-play инструментах, могу назвать несколько бесплатных для Java:
AB>http://marathonman.sourceforge.net/
AB>http://abbot.sourceforge.net/
AB>http://pounder.sourceforge.net/
AB>Они зачастую менее стабильны, чем коммерческие, да и возможностей поменьше, но набрав обойму из нескольких можно получить практически всё, что необходимо.

AB>Ещё больше таких, которые позволяют писать программы, эмулирующие действия с элементами графического интерфейса на весьма высоком уровне. Выбирать, например, здесь: http://tejasconsulting.com/open-testware/feature/gui-test-driver-survey.html

ну какбы где-то вроде... во-первых — ява, во-вторых — ГУИ тестирование. а каковы сообственно впечатления после несредственно юза таких тулов (если конечно юз фактически был)?? и для тех, кто на бронепоезде — можно ли такими тулами выловить такие например юзкейсы: при удалении последнего элемента в листе ХХХ на диалоге УУУ будет краш; не работает клавиша Кнтрл на туле ХХХ ??

Здравствуйте, Alexei Barantsev, Вы писали:

AB>К сожалению, действительно в русском языке происходит путаница из-за того, что часто test design переводится как тест-план. Надо как-то с этим бороться, но пока приходится с этим жить. Действительно, дизайн тестов -- не лучший перевод, он тоже не слишком интуитивно понятен.

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

AB>Таким образом, в этой терминологии, требуется не план, а дизайн тестов. Вообще-то народ неохотно делится такого рода темплейтами и примерами, потому что начальство этого не одобряет.

Так и есть. Любую техническую документацию в нормальных фирмах наружу выносить не принято.
Точно врядли кто сделает доступным реальные спецификации системы
или реальные примеры "из жизни" UML диаграмм.

B>Я бы скорее предположил, что в русский язык путаница пришла
B>видимо от наглоязычных коллег.

Хорошо я однако опечатался

Здравствуйте, AlikGut, Вы писали:

AG> ну какбы где-то вроде... во-первых — ява, во-вторых — ГУИ тестирование. а каковы сообственно впечатления после несредственно юза таких тулов (если конечно юз фактически был)?? и для тех, кто на бронепоезде — можно ли такими тулами выловить такие например юзкейсы: при удалении последнего элемента в листе ХХХ на диалоге УУУ будет краш; не работает клавиша Кнтрл на туле ХХХ ??

Просто я живу в Java world, поэтому и привёл примеры для Java, более сведущие в других технологиях люди могут подсказать больше.
Лично я предпочитаю не пользоваться record-n-play инструментами, а пишу GUI-тесты руками с использованием Jemmy (http://jemmy.netbeans.org). Потому что записанные автоматом тесты всё равно перерабатываются до неузнаваемости, так зачем и мучиться, лучше сразу написать руками то, что надо.

Для тех кто в бронепоезде: любой инструмент проверит только то, что ему велено, он же не знает, должна клавиша Cntrl работать или нет, а если должна, то как именно. А также он не знает, что есть краш, может быть то, что диалог после этого не открывается — это задуманная функциональность. Какие напишете проверки, такие и будут выполнены. А что касается возможности — да, можно написать такие проверки.

Что касается тестирования не GUI, а, например, API — тут вообще record-n-play нонсенс, тесты нужно разрабатывать руками. Мы пользуемся тем, что сами и делаем — UniTesK. Но для тестирования попроще как привило достаточно и JUnit'а.

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

Здравствуйте, Alexei Barantsev, Вы писали:

AB>Просто я живу в Java world, поэтому и привёл примеры для Java, более сведущие в других технологиях люди могут подсказать больше.
так они молчат!!

AB>Для тех кто в бронепоезде: любой инструмент проверит только то, что ему велено, он же не знает, должна клавиша Cntrl работать или нет, а если должна, то как именно. А также он не знает, что есть краш, может быть то, что диалог после этого не открывается — это задуманная функциональность. Какие напишете проверки, такие и будут выполнены. А что касается возможности — да, можно написать такие проверки.
в том-то и дело — ерунда все эти тесты. руками всеже надежнее

Здравствуйте, AlikGut, Вы писали:

AG> в том-то и дело — ерунда все эти тесты. руками всеже надежнее

Вопрос только в том, что именно делать этими руками.

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

Другое дело — руками писать тесты, которые затем выполняются автоматически. Это по сути обычное программирование, но с необычными целями. И тестировщик, посасывая кофе и наблюдая за тем, как всё само собой тестируется, наконец получает свою порцию удовольствия.

Но — для этого нужен тестировщик, который умеет программировать. А многие компании пытаются съэкономить на тестировании и нанимают для этой работы мартышек, чтобы кнопки тыкать.

Вот на этой их слабости и паразитируют многочисленные производители record-n-play инструментов. И не только они, я на одной выставке говорил с SEO американской сервисной компании, которая "помогает" другим доводить тесты до ума. Я сказал — хорошо бы вот так улучшить инструмент X, и ещё вот так, а то он весь кривой. А он мне и отвечает — это хорошо, что кривой, чем кривее, тем больше мы можем на этом денег заработать. Потому что у нас хорошие программисты, которым эта кривизна нипочём, а клиенту проще объяснить, что сам он не справится. Вот такой интересный бизнес.