Кто-нибудь может привести мне пример сабжа?

1. Берём в руки программу.
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.

Алексей, алгоритм неполный.
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".

Я это подразумевал во втором пункте. А Вы что имеете в виду, говоря о "требованиях", а?

Алексей, я соглашусь с JimR.
Требования это одно, а поставленная задача это другое.
Например есть простейший калькулятор, к нему есть куча требований, но будет стоять задача проверить лишь одну функцию сложения двух простых чисел в пределах [1, 100]...

Вот

Мы говорим об "обобщённом алгоритме тестирования вообще" или о "постановке задачи тестировщику на следующую неделю"? Откуда берётся постановка задачи? Что за высшие силы её ставят?

Чую сейчас начнется холивор. Можно запросто и без требований тестировать, разве нет? По use cases или user story. Или, вообще, по наитию (типа exploratory), так сказать (в самом простейшем случае). Что хочется сказать - обобщенного алгоритма нет. Есть много подходов к тестированию и каждый из них хорош в определенных условиях.

Уже начался (IMG:style_emoticons/default/crazy.gif)

А use cases и user story - это что, не требования?

Поэтому я и написал -- "Узнаём каким-нибудь образом требования". По наитию -- это частный случай :)

Я где-то видел замечательное высказывание, что требования делятся на три части -- 1) зафиксированные, 2) выявленные но не зафиксированные, 3) невыявленные.
Но все три класса -- это требования, они есть, их не может не быть.

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

"Как-то так" у Вас вообще никакого алгоритма не получится ;)
Нельзя объять необъятное (с) Козьма Прутков

Моделирование только потому и имеет право на существование, что модель проще моделируемой сущности. Иначе модель просто не нужна.

Вы спросили откуда берется постановка задачи :)

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

А то вы сами не знаете? Если user story с натяжкой ещё можно назвать требованиями, то use case лично у меня язык не поворачивается.

Я считаю, что "например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее"" -- это требование. Вы считаете, что это постановка задачи. На этом и сойдёмся :)

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

Юзкейсы - не требования?!
Щаз я сюда на разборки всю братву приведу с uml2.ru (IMG:style_emoticons/default/new_russian.gif)

:)

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

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

(IMG:style_emoticons/default/lazy.gif)
если бы, да кабы, да например...
а я вот ещё аллегорию употреблю: бульдозер и болид формула-1 не средства передвижения?

Приведу то что я представляю под этим обобщенным алгоритмом, кто как его подкрутить поправит может - думаю тут вообще очень много чего править надо)
и так:
1. Взяли прогу, требования по функционалу, требования на качество ПО(тут может кто то распишет подробнее какие качества ПО можно выделить, например время отклика или еще что то)
2. Составить тест-требования - что же надо тестировать(то это должен делать? и полностью ли это соответствует требованиям по функционалу и качеству ПО)
3. Составление тест-плана - когда и что тестируем
4. разработка тестов
5. тестирования
6. отчет о тестировании

5. ???
6. Профит

Приведу свой вариант общего алгоритма:

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


А касаемо Use Cases, все зависит от их качества, в моей практике были просто замечательные, и использовались командой как требования :)