241

Тестирование / Re: Автоматизированное тестирование + и -

« : 24 Июля 2008, 12:57:48 »

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

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

242

Системный Анализ и Требования / Re: Чисто практический вопрос

« : 23 Июля 2008, 00:03:44 »

А если не устраивает? А если проблема в ранее принятом стиле работы, инерции, ошибках проблемах архитектуры? Хотя тут слышал такое высказывание: "да причем тут архитектура, не в архитектуре дело, у всех эти архитектуры одинаковые"

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

243

Обучение / Re: Статья: Создание эффективной инженерной документации

« : 22 Июля 2008, 15:01:13 »

Ну что ты так сразу! Мы читаем медленно...

244

Системный Анализ и Требования / Re: Чисто практический вопрос

« : 22 Июля 2008, 13:22:36 »

Все эти задачи не приносят дохода в краткосрочной перспективе. Но при этом требуют глубокой концентрации, а значит, много времени. И всё время оказываются оттеснёнными какими-то "более срочными" задачами.
А ему, по-моему, и не нужны эти планы. Он продавец, а цель продавца - получить свои комисионные. То есть ему нужно начать проект и показать заказчику что-то худо-бедно работающее, чтобы продать ему оборудование. А продолжение проекта, сопровождение, техническая поддержка - это только досадные помехи на пути к окучиванию новых заказчиков и новым продажам. В результате у нас с ним возникает огромное напряжение при назначении приоритетов: я считаю своим долгом в первую очередь выполнить обязательства перед существующими заказчиками, а для него важно как можно быстрее реагировать на бредовые гениальные идеи потенциальных заказчиков, звонящих ему ежечасно и обещающих купить 50 000 терминалов уже до конца этого года.

Подпишусь под каждым словом!
Пока при текущем процессе прибыль растет на десятки процентов, рост прибыли на 3-5% за счет оптимизации процесса производства владельцев бизнеса интересовать не будет.

245

Системный Анализ и Требования / Re: Чисто практический вопрос

« : 22 Июля 2008, 10:27:54 »

Цинично добавлю: очень многое зависит от руководства. Если руководство устраивает текущий процесс, то шансов что-то поменять столько же, как у христианского проповедника среди язычников, т.е. очень сильно зависит от харизмы проповедника и его умения лавировать в политическом море.
Если партию и правительство устраивает ситуация, в которой в случае ухода автора эссе/разработчика большая часть знаний о системе потеряется, значит, такой процесс останется. Зачем менять образ жизни курицы, если она и при текущем образе жизни несет золотые яица? А вдруг при изменениях что-то сломается?

Но стремиться к хорошему несомненно надо :-)

246

Системный Анализ и Требования / Re: Хорошие требования vs Сырые требования

« : 20 Июля 2008, 23:44:38 »

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

247

Сообщество Аналитиков / Re: [Конференция] ИТ анализ и требования (подготовка)

« : 14 Июля 2008, 14:27:40 »

Как-то очень резво писать 11 июля, что последний срок подачи тем докладов - 15 июля :-)

248

Тестирование / Re: Организация и управление процессом тестирования

« : 08 Июля 2008, 10:57:29 »

Насколько точным и подробным должен быть тест-сценарий?
Может ли тест-сценарий содержать "цель" шага тестирования, а не точное скурпулезное описание каждого действия.
Т.е. тест-сценарий - это аналог в какой-то степени руководства пользователя, только с точно заданной нагрузкой?

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

249

Сообщество Аналитиков / Re: Присоединение к Сообществу Аналитиков России

« : 07 Июля 2008, 19:30:38 »

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

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

250

Тестирование / Re: Организация и управление процессом тестирования

« : 07 Июля 2008, 19:22:38 »

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

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

251

Варианты Использования (Use Case) / Так UseCase функция или нет?

« : 06 Июля 2008, 21:55:33 »

На сайте появилась ссылка на статью группы товарищей, в т.ч. Золотухиной. http://www.interface.ru/home.asp?artId=16728
И что же мы там читаем?
"Модель "Use case Model" есть модель предполагаемых функций системы и ее окружения, и служит контрактом между клиентами и разработчиками. Модель используется как существенные входные данные в деятельности по анализу, проектированию и тестированию."
Таки вы согласны с этим, о уважаемые?

252

Sparx / Re: Реплицирование в Enterprise Architect

« : 05 Июля 2008, 01:17:30 »

Добавлю, что механизм репликаций работает только для EAP-файлов, т.к. основан на функциях MS Jet

253

Sparx / Re: Enterprise Architect: Практика использования

« : 04 Июля 2008, 15:56:13 »

Имеется в виду копирование диаграмм?
С помощью механизма профилей или копирования пакетов. Про профили недавно где-то здесь обсуждали

254

Sparx / Re: Enterprise Architect: Практика использования

« : 03 Июля 2008, 15:08:17 »

Да согласен - честное API конечно корректнее. Ну в принципе API предусматривать возможность insert update делать?

Есть. Смотрим хелп Extending EA-The Automation Interface-Reference-Code Samples-Add and Manage Elements

255

Sparx / Re: Enterprise Architect: Практика использования

« : 03 Июля 2008, 13:57:37 »

Ага тут кстати приходит в голову и обратный способ. Например у меня имеется список обьектов (классов) в экселе!!!!! Пишем скрипт - который загоняет все в аксесс...
Прокатывает такой вариант?

Не, не прокатывает. Ибо у меня селекты, а Вы хотите базу менять. Я бы базу меняла только честным API, используя честные команды вставки элемента. Он же там и идентификаторы по определенному принципу прописывает и т.д.