Сообщений в теме: 43

[Case]

Значит у всех всё ручками делается? :(

[Олешка]

AQdevTeam тоже не все может :(
Сейчас как раз нахожусь в поиске тула для test managementa. Хочется много всего, а нету...

[Green]

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

Первым делом создаем список тестовых точек (или требований). Для каждой тестовой точки определяем классы входных тестовых данных (а можно и конкретные тестовые данные). Соответственно, имеем еще одну таблицу - таблицу тестовых данных.

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

В итоге соеденяем тестовую точку с шаблоном и получаем конечный тест кейс. Множим его на количество входных тестовых данных и получаем конечный список возможных тестов.

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

Суммируем и получаем полный список тестов по проекту.

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

Очень хорошо было бы иметь возможность отслеживать характеристики тест кейсов: кем создан, сколько времени занимает его проведение, автоматизирован или нет, когда и кем был обновлен и т.п.

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

Эх, сам бы написал программу, если бы было время... :rolleyes:

[Green]

Кстати, может кто еще подскажет актуальные (на его взгляд) требования к системе?

[Олешка]

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

1. Постановка задачи
1.1. Возможные виды тестирования

• Входное тестирование общей работоспособности и стабильности системы перед выполнением прочих тестов.
• Валидация первого уровня - ввод неверных и опасных данных (по типу, размеру), мусора.
• Тестирование бизнес-функциональности - убедиться в том, что система делает то, что должна делать и ничего более.
• Валидация второго уровня - тестирование на соответствие бизнес-правилам.
• Нагрузочное тестирование.
• Тестирование производительности.
• Тестирование на соответствие стандартам.
• Тестирование Security.
• Регрессионное тестирование - выполнение всего пакета тестов для подтверждения работоспособности текущей версии системы.
• Приемочное тестирование – тестирование в условиях, определенных клиентом, и относящееся к специальным требованиям клиента.

Тестирование ведется на основе тестовых планов, или наборов тестов.

1.2. Категории тестовых планов

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

ВАЖНО: версии проекта и плана разные и ведутся по разному.

Как только с планом первый раз начали работу, начальная версия плану должна присваиваться автоматически.
Общие планы должны создаваться без привязки к конкретному проекту.
Специальные планы должны создаваться сразу под проект.
Из специальных планов сейчас очевиден один – для функционального тестирования.

1.3. Тестовые планы

Идентификатор тестового плана составляется из версии, дату последнего редактирования, категории, имени проекта.
Если нет имени проекта – это просто шаблон плана, если есть – это реальный план на проект.

Тестовый план - это таблица со списком тестов.
Тестовые планы заполняются тестировщиком.
Тестировщик придумывает тест, заносит его в базу данных и привязывает к определенному плану тестирования.

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

1.4. Описание теста

Одна запись в тестовом плане = один тест.

Запись для оформления теста должна иметь следующую структуру:

• Поле для записи открытого предположения (выставленного к системе требования)
• Поле для записи ожидаемых результатов
• Поле для записи полученных результатов
• Флажок прошел/не прошел
• Путь к файлу автоматического тестирования (если есть)
• Сопутствующий файл с результатами тестирования (может быть не один файл)
• Поле комментариев
• Поле Закрыт/Открыт

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

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

Тест 1

• Тест 1.0
• Тест 1.1
• Тест 1.2

Тест 2

• Тест 2.0
• Тест 2.1
• Тест 2.1.1

Если невозможно выполнить Тест 1, то тесты 1.0, 1.1, 1.2 так же не выполняются.

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

По умолчанию все новые тесты считаются закрытыми, когда план в состоянии INIT или DRAFT. При переходе в состояние READY все тесты автоматически переводятся в открытое состояние после запроса и согласия тестировщика.

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

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

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

Закрытые тесты не должны попадать в план тестирования, готовый к выполнению.
1.5. Состояния тестового плана
1.5.1 “INIT”

Исходное состояние плана - он имеет только название.
Таблица с тестами пуста.
Возможные переходы в это состояние - НЕТ.
Все только что созданные планы имеют состояние “INIT”.
“INIT” тестовый план не привязан ни к тестировщику, ни к проекту.

1.5.2 “DRAFT”

Вносятся изменения в описание тестов или добавляются новые тесты.
На этом этапе никто другой не может с ним работать или взять/отдать на выполнение. “DRAFT” тестовый план привязан к тестировщику для редактирования, и не привязан к проекту.
Возможные переходы в это состояние:
“INIT” в ”DRAFT” - тестировщик начал вводить описания тестов
“READY” в “DRAFT” - дополнительные изменения в тестах

1.5.3 “READY”

Тестер сохранил изменения.
План готов к использованию. Его могут забрать на выполнение.

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

“READY” тестовый план не привязан ни к тестировщику, ни к проекту.
Возможные переходы:
“DRAFT” в “READY” - сохранен после редактирования описаний тестов
“REPORT” в ”READY” - сохранен после отчета

1.5.4 “RUN”

Тестер забрал план и выполняет тесты.
Остальным тестерам должен быть закрыт доступ к этому плану для того же проекта, на который забрали план, до тех пор, пока тестер не сдаст отчет.
Для других проектов доступ к тому же плану открыт.
“RUN” тестовый план привязан к проекту и тестировщику для выполнения.
Возможные переходы:
“READY” в “RUN” - взят на выполнение после сохранения

1.5.5 “REPORT”

Тестер составляет отчет по выполнению тестов.
Отчет по выполнению теста идет на уровне прошел/не прошел.
Описание тестов должно быть нередактируемым, можно только расставить галочки прошел/не прошел и вписать полученные результаты в случае если тест не прошел.
Отчет сохраняется в системе и привязан к версии проекта и версии плана.
Могут быть написаны дополнительные отчеты - отчеты о проблемах.

“REPORT” тестовый план привязан к версии проекта и тестировщику для заполнения отчета.

Возможные переходы:
“RUN” в “REPORT” - отчет после тестирования

1.5.6 Общая схема смены статусов тестового плана

                  start
                    |
                  INIT
                    |
                  DRAFT<------------+
                    |                        |
                    |                        |
          +-->READY                | 
          |        |                        |
          |        |                        |
          |      RUN      CORRECTIONS
          |        |                        |
          |    REPORT                |
          |        |                        |
          Yes--is this plan OK?--No
                    |
                  end

1.6. Testing knowledge database

1.6.1 Справочные материалы

В системе должны поддерживаться справочные материалы:

• Формальный перечень часто обнаруживаемых ошибок. Этот перечень может пополняться менеджером тестировщиков и использоваться как справочный материал для создания тестов на другие проекты.
• Формальный список компонент плана тестирования. (подробно см. [ ])
• Формальный список классов эквивалентности по типам данных
• Формальный список граничных значений по типам данных
• Формальная процедура тестирования, принятая в компании, и все сопутствующие ей шаблоны документов.

1.6.2 Оборудование тестовой лаборатории

В оборудование тестовой лаборатории входят как hardware часть (компьютеры, сетевое оборудование, периферийные устройства и т.д.), так и software часть.

[Олешка]

2. Тестирование проекта
2.1. Исходные данные

Тестирование проекта начинается с присвоения ему названия, начальной версии
и ввода информации об изменениях. Для начальной версии изменения записываются как "First draft".
2.2. Команда проекта

На проект назначается группа работников с ролями:
разработчик(и)
тестировщик(и)
менеджер проекта
менеджер группы тестирования

Команда проекта обменивается документацией – отчетами о проблемах и тестовыми планами.

Доступ к документации определяется по роли в проекте:

Разработчик может:

• получать отчеты о проблемах
• отчитываться по ним

Тестировщик может:

• редактировать тестовые планы, направленные ему
• готовить отчеты по выполненным тестовым планам

Менеджер проекта может то же, что и разработчик, плюс:

• просмотреть тестовые планы на проект
• закрыть несоответствующие тесты.
• получать отчеты по выполненным тестовым планам
• получать отчеты о проблемах
• получать сводные отчеты

Менеджер группы тестирования может то же, что и тестировщик, плюс:

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

В группу проекта могут также входить заказчики и высшее руководство компании.
Они могут то же самое, что и менеджер проекта.

2.3. Требования к Hardware/Software для тестирования проекта

До начала тестирования согласовываются и утверждаются требования к Hardware/Software.

Требования записываются в специальные тестовые планы

• HARDWARE
• SOFTWARE

Архитектура проекта может определить дополнительные требования к оборудованию. Все они должны заноситься в эти тестовые планы.

2.4. Этапы тестирования версии проекта

Надо фиксировать дату и время смены статусов проекта в ходе тестирования.

От Request к Open – время на подготовку проекта к тестированию менеджером проекта
От Open к Testplan - время на подготовку проекта к тестированию менеджером тестировщиков
От Testplan к Testing - время на написание тестового плана
От Testing к Reporting – время на выполнение тестов
От Reporting к Tested - время на написание отчетов по циклу тестирования
От Tested к Closed – время на просмотр отчетов менеджерами

2.4.1 “REQUEST”

Проект планирует тестирование. Менеджер знает, какая версия следующей будет отправлена тестировщикам и резервирует время, вводя исходные данные по проекту.

Система должна проверять присутствие всех необходимых данных и не переводить проект в состояние “OPEN”, до тех пор пока менеджер проекта не введет всю необходимую информацию.

2.4.2 “OPEN”

Проект готов к тестированию:

• Имеет версию
• Известно, что изменилось с предыдущей версии.
• Изменения перенесены из Fixed issues в специальный тестовый план FIXES.
• Зафиксированы требования к тестовым машинам. Требования должны подставляться из предыдущего плана, с возможностью редактирования.

Система должна автоматически присвоить статус “OPEN”, если есть все необходимые данные.

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

Система должна разослать два подтверждения - менеджеру проекта и менеджеру группы тестировщиков, о том, что проект готов к тестированию.

2.4.3 “TESTPLAN”

Менеджер группы тестирования назначает категории тестовых планов для тестирования проекта.

На один проект может быть открыто много тестовых планов.

Обязательными к выполнению являются планы FIXES,
CLIENT SOFTWARE/HARDWARE, SERVER SOFTWARE/HARDWARE

Тестировщик записывает запланированные тесты в планы.

Когда план сохранен в системе, надо разослать два сообщения – менеджеру проекта и менеджеру тестировщиков.

2.4.4 “TESTING”

Выполняются тесты.
Обязательными к выполнению являются планы (именно в таком порядке):

2.4.4.1 SERVER SOFTWARE/HARDWARE

Если версия установлена на окружение, не соответствующее требованиям по HARDWARE/SOFTWARE, тестирование останавливается до выполнения требований.

Тесты из этих планов могут быть выполнены повторно, до получения результата.

2.4.4.2 CLIENT SOFTWARE/HARDWARE

Тестировщик должен убедиться, что все выставленные требования по Client soft/hard выполнены, и обязан не начинать тестирование без этой проверки.

2.4.4.3 Приемочное тестирование тестовой группы

Приемочное тестирование выполняется для оценки общего состояния программы.

Если версия продукта не проходит приемочное тестирование, она возвращается команде проекта.

Автоматически генерируются отчеты по багам.

Тестирование по этой версии прекращается.

Для возобновления тестовых работ надо оформить запрос на тестирование новой версии с патчем.

2.4.4.4 BUG FIXES

2.4.4.5 Patches для версии

Выполнение тестов начинается, когда тестовый план находится в состоянии “RUN”,
а тестируемый проект в состоянии “TESTING”.

Выполнение тестов может занять не один день, поэтому тестировщик должен иметь возможность отчитаться по части тестов, но не переводить весь план в REPORT.

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

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

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

Оценка состояния проекта дает два варианта развития событий:

Проблемы настолько серьезные, что тестировать дальше нельзя:

Менеджер проекта закрывает тестирование версии N.
Разработчики проекта исправляют найденные ошибки.
Проект готовит патч 0.01 к версии N.
Менеджер проекта делает запрос на тестирование новой версии: Version N Patch 0.01.
В этом случае версия проходит обычный анализ в системе – см. Этапы тестирования версии проекта
Для новой версии начинается новый цикл тестирования.

Проблемы будут исправлены в следующей версии и тестировать дальше можно

Тестировщики продолжают работу и выполняют оставшиеся тесты на той же версии.

2.4.5 “REPORTING”

Пишется отчет о тестировании версии.

2.4.6 “TESTED”

Cоздан и сохранен отчет о тестировании версии/build.

Система должна разослать сообщения о создании отчета менеджеру проекта и менеджеру тестировщиков.

2.4.7 “CLOSED”

Версия проекта закрыта для тестирования менеджером тестировщиков после получения отчета.

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

2.5. Общая схема смены статусов тестирования проекта

                                    REQUEST
                                            |
                  +------------> OPEN (VERSION #n BUILD #m)
                  |                        |
                  |                  TESTPLAN
              (VERSION #n        |
                build #m+1)    TESTING
                  |                        |
                (FIXES)        REPORTING
                  |                        |
                  |                TESTED
                  |                        |
                  |                  CLOSED
                  |                      |
                  |                does next
                  |              version ready
                  +- Yes-------for testing?

2.6. Отчеты

2.6.1 По тестовым планам

Распечатать тестовые планы на проект как задание тестировщику

2.6.2 По проекту

План на тестирование версии проекта.

Может быть получен после перевода проекта в стадию TESTPLAN, когда все тестовые планы распределены по тестировщикам.

Отчет должен содержать следущую информацию:

• Название
• Версия
• SOFT/HARD требования к тестовым машинам,
• Изменения с последней версии
• План FIXES
• Группа тестирования
• Распределение тестовых планов по тестировщикам

Отчеты по результатам тестирования проекта:

• Состояние проекта
• Завершение цикла тестирования
• Акт о выпуске
• Список назначенных тестовых планов
• Список выполненных тестовых планов
• Развернутый список выполненных тестовых планов с результатами тестирования
• Список пустых тестовых планов
• Список не назначенных никому тестовых планов
• Список прошедших тестов
• Список провалившихся тестов

Сводный отчет по трудозатратам на тестирование. Должен содержать следующую информацию:

• Версия проекта
• Хронология тестирования версии проекта – смена статусов, время на прохождение каждого этапа, время работы каждого тестировщика проекта.

[Олешка]

3. Система отслеживания проблем

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

Есть два источника отчетов о проблемах:

• ручной отчет - написан членом группы проекта
• автоматический отчет - сгенерирован из непрошедшего теста.

Все отчеты о проблемах составляются в стандартной форме.

Для получения сводных отчетов служит генератор отчетов.

Сводные отчеты нужны:

• в произвольной форме - любые поля по выбору пользователя
• в форме отчета по итогам тестирования за период времени по циклу тестирования. Период определяется от начальной до конечной даты. Обе даты (date from и date to) должны явно прописываться в полях ввода. Данные за эти даты должны включаться в отчет.

[Олешка]

4. Обмен данными
4.1. Из системы тестовых планов в систему отслеживания проблем

По команде из системы тестовых планов:

Тесты, завершившиеся с результатом Fail, превращаются в отчеты о проблемах со статусом Open.

Каждый тест преобразуется в отчет.

При этом составляется описание проблемы из данных:
1. Test description
2. Expected results
3. Real results

Все отчеты направляются на менеджера проекта.
4.2. Из системы отслеживания проблем в систему тестовых планов

Отчеты о проблемах со статусом "Fixed", или "Fixed, need testing" только ПО ЗАПРОСУ ИЗ СИСТЕМЫ ТЕСТОВЫХ ПЛАНОВ передаются в специальный тестовый план FIXES на следующую версию проекта. При этом, если тестирование предыдущей версии еще не завершилось, т.е., она не CLOSED, должно выводиться сообщение об этом, и данные не передаются.

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

Менеджер проекта при подготовке проекта к тестированию должен сделать запрос по всем fixed отчетам и указать явно, какие из них все-таки НЕ вошли в поставку тестировщикам (если такие есть). Система предполагает, что все fixed вошли в поставку, но если это не так, менеджер должен иметь возможность указать, что реально не вошло.

Далее, менеджер проекта должен явно указать, какой номер версии присвоить не вошедшим в эту поставку fixed issues.

План FIXES адресуется менеджеру группы тестирования.

Связь между системой отслеживания проблем и системой тестовых планов - по версии проекта.

Версия проекта должна быть одна и та же в обеих системах.

[Green]

to Олешка:

Молодец! :)

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

Во-первых, слишком много информаци за один раз.
(Редкая птица долетит до середины... :P )

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

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

[Green]

Может быть начать обсуждение с чего-нибудь попроще?

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

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

Но при всем этом, повторюсь, задача достаточно проста, что увеличивает ее шансы на рождение.

[Green]

Отдельно стоит вопрос полезности системы учета тест кейсов (см пред. пост). B)

В соответствии с корпоративной практикой мы оформляем тест кейсы в виде Excel файлов. Это не очень удобно, но в Excel файле я могу организовать страницу шаблонов. Благодаря этому резко сокращается общее количество ОФОРМЛЯЕМЫХ тест кейсов.

Поясню на примере:

Имеется 100 категорий некоторого контента в CMS (Content Management System). С одним/двумя файлами каждой категории необходимо провести однотипные тесты: создать, просмотреть, отредактировать, удалить. Каждый тест проводится, как минимум, с входными тестовыми данными четырех классов (корректные, корректные граничные, некорректные, некорректные граничные).

- При оформлении тест кейсов в Test Directore (я раньше его использовал) мне необходимо оформить:

вариант а: 4ТестКейсОпераций * 100Категорий * 4КлВхДанные (не обязательный параметр) = 1600 ТК

вариант б: 4ТестКейсОпераций * 100Категорий = 400 ТК

В этом случая каждая связка (ТестКейс-Категория-(КлВхДанные)) будет различаться системой и по каждой такой связке будет вестись учет. Что собственно и требуется от системы.

- В случае оформления аналогичных тест кейсов в Excel файле, мне достаточно оформить ЧЕТЫРЕ тест кейса шаблона и одну консолидированную таблицу, которая будет содержать:
# идентификатор тест кейса;
# ссылку на шаблон тест кейса;
# название категории;
# ссылку на входные тестовые данные.
Все!

Для меня выгоды очевидны. 1600 тест кейсов против 4!

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

[Олешка]

to Олешка:

Молодец!  :)

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

Во-первых, слишком много информаци за один раз.
(Редкая птица долетит до середины... :P )

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

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

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

Уже решилось - выложим в виде статьи на сервере и дадим линк на форум.

Сообщение отредактировал Олешка: 28 октября 2003 - 16:57

[Олешка]

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

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

[Green]

имеем полное право сформулировать и выдвинуть свои требования

Председатель собрания:
- Итак, наши требования!
Во-первых, убрать один ноль ....

Реплика из задних рядов: "Лучше два или три!"

Председатель (кашляет):
- Во-первых, убрать два нуля из цены на программный продукт!
В противном случае...

Сидящий рядом (подсказывает шепотом):
- Мы напишим свой, в сто раз лучший.


Извини, Олешка, не удержался от искушения. :P

[Олешка]

Да все нормально :D

[Олешка]

А из цены лучше побольше нулей убрать B)