порекомендую как и Эдуарду начать с описания Вариантов использования на основании тех знаний, которые вы можете получить у людей "которые  что-то знают"

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

Будет ли форма тестового случая = форме варианта использования с нанизанными на нее тестовыми данными и ожидаемыми результатами
или
она совершенно не будет равна и будет иметь другое формообразование?

спасибо

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

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

Будет ли форма тестового случая = форме варианта использования с нанизанными на нее тестовыми данными и ожидаемыми результатами или она совершенно не будет равна и будет иметь другое формообразование?

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

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

Давайте подумаем немного.
Ситуации бывают такие:
1. Грамотно организованный процесс рзработки, где в основу положен ВИ. ВИ здесь и фрейм предметной области и промежуточный продукт для получения других: постановки задачи на проектирование, написания инструкций по использованию, разработке тестовых случаев
2. Нет ничего подобного пункту 1. В этом случае ВИ скорее получают из того как работает система глазами пользователя, те.е ВИ = инструкции того как использовать систему, чтобы получить то что желательно.
В этом случае мне думается пробем понимания вообще не будет. Все же видят систему и более менее знают как с ней работать, только такое описание дает более четкое представления.
Т.е. по сути я пишу ВИ с точки зрения реального интерфейса. Есть бизнес-задача - например оформление документов по коммерческой поставке, и я составляю описание того как это делается. По сути я описываю некоторый сценарий - скорее всего типичный и любые альтернативные, указывая где и какие кнопочки нажимать. Единственное что, я не указываю какие данные при этом выбирать. А вот когда указываю эти данные то получается по сути тестовый сценарий.
Хотя в стандарте IEEE нет понятия сценария.
Насколько я понимаю тестовый случай - это по возможности нечто атомарное - например: проверить что сумма счета при создании счета выставляется корректно.
Я из описания ВИ знаю какие действия я делаю, чтобы получить этот самый счет,в нем возможно отражены правила, которые влияют на эту сумму счета, зная которые я подбираю данные. Причем если внимательно подумать, то по сути целью будет не просто проверка суммы счета, а влияние некоторых параметров (количества товаров, цены на текующую дату, скидки и т.п.) на конечную сумму счета.
При этом у меня есть несколько возможностей:
1. сформировать влияющие правила последовательно и посмотреть как формируется счет
2. найти клиента с некоторым набором нужных мне правил - и создать счет и убедиться, что сумма корректна
В зависисмости от возможности - я могу организовать два разных сценария: один будет например таков - выбрать
1.создать-выбрать клиента , задать ему такие-то правла, сформировать счет и убедится или не убедится что сумма корректна
или
2.клиента № такойто(и я заранее знаю его набор правил), сформировать счет и сравнить с ожидаемым


При наличии исходных данных 2 сценарий проще и быстрее - он легче и программируется, да и в ручную меньше манипуляций.

Хотя в 1 случае мы еще можем проверить и сам факт установки и применимости этих правил

Вообще м дело творческое и сильно зависит от ситуации.
В любом случае ВИ являясь некоторой законченной целостной функциональностью, дает больше возможностей для выделения тестовых случаев.

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

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

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

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

1. Грамотно организованный процесс рзработки, где в основу положен ВИ. ВИ здесь и фрейм предметной области и промежуточный продукт для получения других: постановки задачи на проектирование, написания инструкций по использованию, разработке тестовых случаев

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

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

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

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

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

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

(ну все, сейчас меня побьют ногами юзкейсшаманы и прочие апологеты религии "юзкейсы это наше все")

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

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

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

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

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

5. как уже показал анализ написанных ВИ - проверка их работоспособности часто покрывается одинаковыми тестовыми скриптами. Скажем в случа оформления коммерческой поставки - через исполнение биллинга проверяется влияние схемы поставки.

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

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

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

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

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

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

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

Здравствуйте. Спасибо за интерес к теме.

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

Не буду с вами спорить. Хотя это наверное цель верификации, в которой одним из инструментов является собственно тестирование, как инструмент выявления дефектов программы или системы

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

Нет я, конечно же, не говорил об этом серьезно. Такой подход наверное вполне подходящий к проектам Open Source, где продукт бесплатен. А когда ты продаешь за серьезные деньги продукт, то пользователь ожидает, что он может выполнять свои задачи, а не задачи разработчика по тестированию Более того я в шутке скрываю свое сожаление по этому поводу.

Вопрос.
Какова стоимость или время разработки Test Case?
Каковы должны быть причины , чтобы не разрабатывались Test Case в компании?

Вопрос.
Какова стоимость или время разработки Test Case?

Не зная контекста задачи, сказать очень сложно. Это все равно, что вопрос "А сколько будет стоить написать ТЗ?" без указания конкретики о системе.

Каковы должны быть причины , чтобы не разрабатывались Test Case в компании?

Хм. обычно такой вопрос не возникает, так как исторически ситуация складывается наоборот. Если без тескейзов жили и программа продавалась, зачем начинать их писать? Это ж в любом случае затраты.
В такой ситуации вопрос будет звучать так: "Каковы должны быть причины, чтоб начинать разрабатывать Test Case?"
Или это какая-то совершенно другая ситуация?

Вопрос иначе задам.
Да правильно заметили, если успешно все продавалось , то зачем их писать.
Зачем Test Case нужны?Вот какая польза?Вообще для чего они изобретены?

Вопрос иначе задам.
Да правильно заметили, если успешно все продавалось , то зачем их писать.
Зачем Test Case нужны?Вот какая польза?Вообще для чего они изобретены?

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

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


В конечном итоге разработка тест-кейсов позволяет экономить главный ресурс - время. Без них просто неизбежны потери времени на повторное  тестирование и доработки уже выпущенной версии. Важно ещё то, что разработка тест-кейсов и проверка по ним включается в план работ и позволяет более-менее адекватно оценивать свои возможности. А авральные переделки и перетестирования всегда оказываются внеплановыми, выполняются за счёт каких-то других (плановых) действий и с большой эмоциональной перегрузкой ("как же достал этот бардак!") и обычно вызывают появление новых ошибок.

....Зачем Test Case нужны?Вот какая польза?Вообще для чего они изобретены?

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

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

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

Третье - документирование того что будет проверяться/проверялось во время тестирования.

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