3706

Варианты Использования (Use Case) / Re: Вариант использования или ... ?

« : 15 Декабря 2008, 23:15:43 »

Эд,

Если ты прочитал внимательно наш разговор с Павлом, то я сказал, что можно описывать ф-ции Системы в виде сценария, но нельзя называть из ВИ НИ В КОЕМ СЛУЧАЕ.

Прости, Саша, не понял выпада?
Я просто человеку пытался указать на ошибки. А ВИ тут писать можно и даже может быть нужно...

3707

О Сайте и Форуме / Re: Снова о логотипе

« : 15 Декабря 2008, 23:14:01 »

Еще одна идея

а внизу - Я ТЫ ОНА - вместе дружная семья

3708

Варианты Использования (Use Case) / Re: Вариант использования или ... ?

« : 15 Декабря 2008, 15:11:54 »

PPPt - разрабатываемая Система, на которую пишется ТЗ.
NT - сторонняя Система.

Хм. На интеграцию? Данная разработка направлена на внедрение разрабатываемой Системы в уже существующую систему (это телеком). То есть разрабатываемая Система использует другие части большой системы.

Подскажите, это интеграция? 


Предствленное выше описание, я попытался переложить таким образом:
Функция: Подключение услуги
 
Основной сценарий
1. Система получает запрос от NT на регистрацию услуги. Формат запроса приведен в Приложении 2.

Use case должен начинаться с действий основного действующего лица, инициирующего процесс. Т.е. с действий NT

2. Система проверяет регистрацию пользователя (наличие профайла пользователя в Системе).
3. Система проверяет наличие у пользователя услуги.
4. Система в профайле пользователя регистрирует услугу с указанием даты регистрации.
5. Сценарий завершен.

Здесь нет диалога, тут монолог. Действует разрабатываемая система, действий внешних систем нет.

Альтернативные сценарии
Альтернатива 2.1
1. Система обнаружила, что пользователь не зарегистрирован (отсутствует профайл абонента).
2. В Системе формируется сообщение об автоматической регистрации пользователя.
3. Производится регистрация пользователя.
4. Возврат в п.3 основного сценария.

Альтернатива 2.2
1. Система обнаружила, что пользователь уже подписан на услугу.
2. В Системе формируется формируется сообщение о наличии услуги у пользователя.
3. Сценарий завершен.[/i]

Опять монолог, нет ДИАЛОГА, неясны действия внешних систем-акторов

3709

Тестирование / Re: Test Case & Test Analyst

« : 14 Декабря 2008, 19:50:22 »

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

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

Ситуация:
Тестовый случай - создание счета на поставку по схеме А
Если написать просто: выберите клиента 1, создайте счет на поставку по схеме А. Результат счет создан.

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

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

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

3710

Книги, статьи и ресурсы / Re: UML 2 и Унифицированный процесс: практический ООА и ООП, 2-е издание

« : 12 Декабря 2008, 17:52:45 »

А сама книга как? Что нравится, а что нет??

Ну в целом книга написано хорошо. Хотя перевод иногда хромает, но понять можно. Тут я не могу оценить на 100%, поскольку слишком много знаю .
Я только начал читать, и сказать пока сложно о впечатлении. Однако, книга очень подробно описывает аспекты UML 2.0 и при этом затрагивает практические вопросы его использования в рамках UP.

Я читаю моделирование прецедентов. Все таки считаю этот термин весьма не удачным. Тем более переводчик использует для Use case Термин прецедент, но иногда в кавычках применяет и "вариант использования". Часто терминология несогласована. В одном абзаце матрица трассировки названа переведена несколькими разными терминами (счас точно не помню кроме одного матрица прослеживания)

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

Что подкупает, это скрупулезное описание когда что и почему надо использовать. Например есть описание трех видов альтернативных потоков:
1. замещающих основной
2. образующихся в определенном месте
3. образующихся в любом месте

В общем, еще почитаю и свое мнение выскажу

3711

Тестирование / Re: Test Case & Test Analyst

« : 12 Декабря 2008, 17:42:08 »

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

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

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

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

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

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

Потому нужно определится со стратегией: как что когда зачем.

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

Время затрат на разработку теста весьма различно. Простой тест - если описание разработать можно очень быстро. Даже если писать скрипт, то тоже не слишком долго, пр определенном навыке. Больше времени уходит на объединение, оптимизацию и интеграцию. Но в среднем удается сделать 4 теста, или меньше (правда я беру только 4-5 часов)

3712

Книги, статьи и ресурсы / Re: UML 2 и Унифицированный процесс: практический ООА и ООП, 2-е издание

« : 11 Декабря 2008, 22:44:07 »

Я сейчас читаю эту книгу. По книге авторами создан интернет-ресурс, который может быть использован как дополнение. Сайт ресурса: http://www.umlandtheunifiedprocess.com/ - это вики-ресурс, содержащий более полные примеры из книги, а также массу других полезных моментов. В частности по материалам книги создан элективный курс. Он коммерческий, но как я понял для вузов существует бесплатная версия

3713

Тестирование / Re: Test Case & Test Analyst

« : 11 Декабря 2008, 16:11:50 »

Спасибо за ссылки статей. Довольно интересно

3714

Тестирование / Re: Test Case & Test Analyst

« : 09 Декабря 2008, 18:29:12 »

А есть утилитки которые могут помочь в генерации Test Case?

Андрей, что значит утилитки? И что значет помочь в генерации?

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

Если на уровне тестирования интерфейса, функционального тестирования черного ящика, то есть множестов систем захвата и воспроизводства. В частности Test Complete (http://automatedqa.com).
Он помогает записывать ваши действия с тестируемым приложением. Обычно потребуется некоторая правка полученного макроса.
В TestComplete входят типа утилит программы рекодеры, но только в профессиональной редакции.

3715

ПО Аналитика / Re: IBM Rational Requirements Composer

« : 08 Декабря 2008, 18:20:21 »

По управлению требованиями я не встречал продукта лучше RequisitePro, это ИМХО

Некоторые компетентные товарищи говорят, что DOORS много лучше

3716

Тестирование / Re: Test Case & Test Analyst

« : 08 Декабря 2008, 18:18:02 »

Можно я тоже выскажусь.

Сейчас в компании, в которой я работаю, я как раз отвечаю за это самое тестирование.

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

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

Простой пример: у меня сейчас сделано не так много тестов, но некоторые направления более или менее покрыты. Например нужно посмотреть работает биллинг или нет. Как обычно поступает аналитик(он же по совместительству тестер). Запускает билинг, выбирает каких-то двух трех клиентов и смотри - о все окей.
Как я поступил - во-первых я выбрал 50 разных клиентов (т.е. с разными начальными условиями). Я написал ОДНУ процедуру проверки и запустил ВСЕХ 50 клиентов на проверку. Из них 10 клиентов не прошли.Причем как выяснилось проблема не в алгоритме биллинга, а некоторых предварительных действиях. Вот этих 10 клиентов при старом подходе мы бы пропустили, а так удалось найти ошибки совершенно другого характера.

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

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

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

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

3717

Книги, статьи и ресурсы / Re: Книга. Карл Вигерс, Разработка требований к программному обеспечению.

« : 07 Декабря 2008, 23:12:24 »

Эд,
Не переживай Лучшее спасибо это счетчик скаченных страниц.

Да не, я, так, придуриваюсь

3718

Книги, статьи и ресурсы / Re: Книга. Карл Вигерс, Разработка требований к программному обеспечению.

« : 05 Декабря 2008, 23:48:37 »

Вот так всегда. Делаешь делаешь - хуть бы кто спасибо сказал

3719

Книги, статьи и ресурсы / Re: Feedback Request: Книга «Идеальное ТЗ». Что внутри?

« : 05 Декабря 2008, 23:38:44 »

Эд, я просил сообщить, о чём интересно услышать, а не спрашивать у меня %(

Прости, Денис.

Хотя

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

Опалубка и сваи - это часть КОНСТРУКЦИИ - физической реализации. А Код - это чертеж, по которому будет что-то создано. Чертеж результант проектной деятельностию.

Но не будем об этом...

Насчет идеального ТЗ. Может начать с сначала?

1. Что такое идеальное ТЗ и почему его не бывает. Есть ли единое идеальное ТЗ или есть идеальные точки зрения на ТЗ: т.з. заказчика, т.з. менеджера проекта, т.з. аналитика, т.з. проектировщика, т.з. программиста, т.з. тестеровщика

2. Что нужно делать чтобы приблизиться к идеальному ТЗ?

3. Какое оно бывает идеальное ТЗ: опыт поколений на пути к совершенству...

4. Как ТЗ используется в процессе создания ПО, ИС, Web-ПО? (правда предварительно хотелось бы услышать, а чем собственно принципиально отличаются эти группы, почему их следует разделять)

5. Нужно ли тратить силы на совершенство ТЗ? Если нужно то в каких случаях, только ли в масштабных проектах?

6. ТЗ по ГОСТ - это плохо? Или мы "Не умеем его готовить"?

3720

Идеи и мозговой штурм / Re: Кто-нить знает какое-нить издание чтобы написть про АСУС?

« : 05 Декабря 2008, 17:50:22 »

Приемная Путина