В библиотеку добавлена статья Андрея Козлова "Составление функционального тест-плана на основе сценариев использования".

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

Читать статью...

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

Ух ты! Это в каком первоисточнике такая терминология используется? Я встречал только "акторы", "актёры" и "действующие лица" :)

barancev
Да вот в самой статье которую приводят http://ru.wikipedia.org/wiki/%D0%A1%D1%86%...%BD%D0%B8%D1%8F сам не знал что так называют :) Поэтому и в кавычках :)

Кстати озвученный "тест план" в статье это скорее набор тестов (Test Suite). Тест план имеет скорее производственный характер, кто, когда, что и т.д.

А я вот не понял в чем полезность/ценность данной модели! Автор говорит: "... помогает существенно снизить риски неадекватного планирования". Отсюда вопросы: Что такое риски неадекватного планирования? Как их оценить? В чем существенно разница/выгода между составлением тест-планов на основе требований и сценариев (пока увидел только в названии, можно и требования назвать, как требование к добавлению записей и требования к фильтрации, а содержание останется прежним)?

Цитата : "Суть её сводится к выделению сценариев использования приложения и наполнению их конкретными данными." Аналогично: Выделим группы требований. Добавим в тест-план тест-кейсы разбитые по группам.

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

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

Но автор вначале упоминает, что "Тест-план – в нашем узком смысле, – это список юз-кейсов и тест-кейсов с расставленными приоритетами. Всего того, что касается оформления плана и подготовки тестовой среды мы касаться не будем."

Такой себе thin test-plan (IMG:style_emoticons/default/dirol.gif)

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

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

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

Наиболее полезно про сценарное тестирование прочитать эту статью.

Наконец-то нашлось немного времени зайти на форум :)


мда термин на французском ограниченно используемый в лингвистике... Раньше ссылались на словари Даля, БЭС и т.д. теперь на Википедию...

По поводу статьи:
1. Использование английских слов написанных русскими буквами.
2. Использование термина test plan не в общепринятом значении (да я знаю что некоторые его так употребляют, но зачем потворствовать этому).
3. "Я предлагаю модель, которая помогает существенно снизить риски неадекватного планирования." По первой части предложения - это что какая-то новая модель? (собственно и описания какой-либо модели я не увидел). По второй части - за счет чего она снизит риски?


P.S. по поводу "азов для новичков" - ни в коем случае нельзя давать такое читать новичкам.

P.P.S. Надеюсь все написанное выше будет воспринято как конструктивная критика. Для того чтобы научиться что-нибудь делать нужно как минимум это делать затем смотреть на результаты и делать это лучше с каждым разом.

Выделение мое. Источник http://alexlobach.ru/2008/09/03/artefakty-...-testirovaniya/ .

Плохой совет в статье:


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

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

Так же излишняя конкретика плоха и в описании тестовых случаев. Напишите "‘//>&<$test#”" - и поверьте, 90% тех кто будет это тестировать введут именно эту строку. Напишите в задании "введите несуществующее в базе имя животного" - каждый будет немного думать. Здесь это не очень показательный пример, но случалось находить баги там, где их никто не находил годами(!), потому что делали именно то что написано. Если написаны конкретные инструции, то люди склонны их выполнять. Дайте небольшую свободу в описании тестов - пускай человек выполняющий тестирование думает, ищет, изучает, а не тупо выполняет придуманные кем-то и когда-то шаги.

Не делайте, так же, и привязку к вполне конкретным специфицированным вещам. Лучше дать ссылку на спецификацию, чем дублировать ее в описании теста. Например, в имени животного запрещены символы ""!";%:?" - не надо их перечислять в тестовых случаях, т.к. они могут измениться, а у вас останется никому ненужный тест. Проще написать: "Попытайтесь добавить животное в имени которого ипользуются запрещенные символы (см. спеку)-> должно появиться соотв. сообщение об ошибке, запись не должна быть добавлена", чем: "введите 'мурка @^&$!' в поле 'имя' -> должен появиться MessageBox с сообщением об ошибке 'некорректное имя животного 'мурка @^&$!''"

Oldman

3. Не давайте читать это новичкам. Я не против :) Лично я давал, помогало.
2. Как только дойдут руки, я напишу статью про тест-планы в целом.
1. Тут ничего даже возразить не могу. Выстрел прямо в сердце.

LeshaL

Я подумаю над вашим предложением. Может, и дам людям свободу выбора. А может и не дам. Я ведь в душе тиран, что вы должны были понять из статьи..

Pryanik

Спасибо! Статью не читал, не видел, и вообще всё писал сам (честно). Хотя статья хорошая. Хоть я ничего нового и не почерпнул. Но, глядишь, найдутся те, кто узнает что-то, чего не знали. И тогда мир станет чуть-чуть лучше :)

Тестировщика зачем нанаяли - думу думать или тесты тестировать? ;)



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



Хорошим тоном является давать ссылку на спецификацию, которой у тестировщика под рукой нет. Или есть, в шести томах на шестистах страницах.

"Ну и что? 30.03.2009 19:07 Баранцев Алексей
> Навскидку, по крайней мере в двух шаблонах нет ни слова об этом:
> Test Plan Template RUP
> Test Plan Template IEEE 829

Ну и что, что там этого нет? (я не проверял, поверю на слово :) )
Разве это означает, что так нельзя делать?

(заходите в форум, там удобнее обсуждать. ссылка в самом низу статьи)"

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

Однако разговор о другом. О том что если вы решили опубликовать статью, приведите ее хотя бы в соответствие со Standard glossary of terms used in Software Testing (International Software Testing Qualifications Board).

И просто, для интереса, как будет называться такой документ:

A document describing the scope, approach, resources and schedule of intended
test activities. It identifies amongst others test items, the features to be tested, the testing
tasks, who will do each task, degree of tester independence, the test environment, the test
design techniques and entry and exit criteria to be used, and the rationale for their choice,
and any risks requiring contingency planning. It is a record of the test planning process.
[After IEEE 829]

Если то, что описано в статье будет называться тест планом.

каюсь грешен :)

@garald

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

Наиболее полезно перед чтением наиболее полезной статьи почитать ее критику: http://it4business.ru/forum/topic4452.html

Повторить что ли свой тренинг с трейнингЛабс по составлению тестов? Будут желающие?

Каюсь, не заметил самого главного. Перефразирую.

ps. Не давайте читать это новичкам. Я не против :) Лично я давал, помогало.
3. Нет конечно. Она как и всё в мире ведёт своё существование со времён Платона. Помогает тем, что подход прост и удобен.