Ну, блин, печатаю заново:

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

Как проверить работоспособность нового релиза типовой конфигурации?

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

Другой вариант - отслеживать изменения, вносимые в типовую конфигурацию. Безусловно, специалист, знающий типовую конфигурацию наизусть сможет выявить все вновь внесенные ошибки и фичи нового релиза. Для этого достаточно режима объединения конфигуратора. Однако затрачивать N-е количество (пропорциональное количеству внесенных изменений) часов работы высококлассного специалиста для многих мелких франчайзи, фикси и фри не является возможным. Тем более, с современными типовыми конфигурациями с большим объемом функционала, большая часть которого не используется.

В связи с вышесказанным, предлагаю на обсуждение следующую технологию «1С-рекордер» сопровождения типовых конфигураций:
1. Тестирование функционала новых релизов типовых конфигураций выполняется в режиме 1С:Предприятие с демо-базой
2. Тестирование представляет собой автоматизированный, ручной, или полуавтоматизированный цикл выполнения тестовых заданий.
3. Каждое тестовое задание - это последовательность выбора пунктов меню, ввод данных в реквизиты форм, нажатие кнопок. Результатом тестового задания является результирующая таблица некоторго отчета. Результирующая таблица  тестового задания может в автоматизированном режиме сравниваться с результатами выполнения теста на предыдущем релизе.
Выполняемые действия записываются с привязкой к внутренним идентификаторам интерфейсных объектов, таким образом, что выполняемое тестовое задание будет работать на релизах конфигураций, несильно отличающихся интерфейсом.

Тестовые задания должны записываться с минимальным отвлечением программиста. Например – нажал кнопку записи в окне «1С-рекордера», и начал в режиме 1С-Предприятие в тестовую базу вводить документы, проводить их. Некоторые действия комментировать (с клавитауры или даже голосом с микрофона). После того как сформировался отчет с контрольными числами по тестовому заданию, нажал кнопку «Закончить запись», указал mxl с отчетом, и дал название записаному тестовому заданию.

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

Для простоты переделки каждое действие задания должно представляться в читаемом виде – «Ввел 01.02.2004 в ДатаПо, Нажал кнопку Выполнить, и т.д.».
Результаты выполнения тестового задания – mxl файлы должны наглядно сравниваться.

Вопрос к публике: Ваши соображения по поводу, уважаемые.

                                                                     Пролд

П.С. Прошлая версия статьи погибла из-за флейма, так что попрошу…
ВСЕМ МОЛЧАТЬ !!!(с)Ржевский

Ответ однозначный - всё руками...

(0) Поищи по форуму, тема уже обсуждалась.
Кроме того, желательно также ознакомиться с технологией тестировани программных продуктов.
Неплохо бы также почитать популярную литературу... вроде "Искусство тестирования программ..."
PS: Я думаю, догадался за что удалили ту ветку.

(2) Поискал. Нашел:
В ветке Диагностика новых 1с-релизов высказаны общие представления о необходимости и принципах и практике тестирования новых релизов.

Я предложил достаточно конкретный МЕХАНИЗМ тестирования продуктов фирмы 1С в отдельной ветке.

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

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

П.С. Борис, а я и не спрашивал, за что удалили мою ветку. Ответ без вопроса?

(4) Механизма тут нет. Есть \"изобретение велосипеда\" при полном отсутствии понимания предмета вопроса.

Вспомнил анекдот.
"Лягушки, станьте ёжиками"(с) Мудрая сова.

(5) Про изобретение велосипеда, подробнее пожалуйста.

Вопрос, который я взялся решать звучит так:
"Как можно избавиться мелким фра, фри и фикси от обнаружения пользователями грубых ошибок в типовых конфигурациях ВПЕРЕД программиста"

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

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

(8)
Вопрос, который я озвучил, как раз мой. И сам наступал на эти грабли, и сотрудники фра на них наступают постоянно.

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

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

(9) Давай о фра и регламенте доступа к указанной конференции здесь не говорить. Может мы имеем в виду разную технологическую информацию? ;-)
Если фра, задай вопрос во франчевой конференции, если нет, не стОт о них говорить.
А теперь подумай над вопросом, прежде чем что-то писАть.
Если 1С успешно работает на таком количестве предприятий, может в консерватории что поправить надо, а не вопить...

(10) Не взлетит. ;-) Для этого нужно хорошо понимать технологию тестирования программ.

Я бы сказал "Для этого надо понимать влияние наличия продвинутой технологии тестирования на сроки выпуска релизов и стоимость продукта".
Что-то ты агрессивен, Борис. Видать тестирование - больное место... ;)

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

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

(10)
Реалии таковы, что отчет, ранее формировавшийся, на новом релизе перестает формироваться.

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

И о воображении тестировщика. Оно тут не причем. Источником тестов, по большей части будут практические ситуации о работе программы, решаемые программистом.

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

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

1. Какая разница, это "воображение тестировщика" или "воображение программиста"? Уверяю тебя, реалии гораздо интереснее.
  Своей системой "автоматизации функционального тестирования" ты отловишь только самые явные баги. Причем ты еще  будешь решать "разница в 0,01 в строке N отчет это глюк этого релиза отчета, глюк прошлого релиза отчета, глюк в тестовых данных или глючит программа тестирования" а я уже локализую этот глюк на реальных данных и напишу ТЗ своему штатному кодеру на его исправление.
2. Соответственно, вводя такую систему тестирования ты снимаешь ответственность за сроки предоставления обновлений с 1С и берешь её на себя. Причем ты всегда будешь опаздывать относительно остальных франчей. Зачем мне безглючная  отчетность, срок сдачи которой прошел позавчера? Я предпочту глючную, но вовремя. Благо недостатка в людях, которые мне исправят обнаруженные мной баги, нету.

(17)пункт 1: Я буду знать о разнице. Посмотрю в документацию к релизу, посмотрю в код, на форуме посмотрю, и решу как и когда исправлять это глюк.

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

2. Наличие информации о глюках никак не взаимоувязано с обязательствами по договорам на сопровождение.


П.С. (17)пункт 2: "Я предпочту глючную, но вовремя" :)))

18
не путай.
клиент - это я.
поэтому и говорю, что для своего прелприятия предпочту глючную но вовремя.

(1) Идея хорошая почти как манифест строителя коммунизма. А конкретно как ты себе представляешь «1С-рекордер»? Ты уверен что его можно сделать?
Мнение BorisG понятно у него есть связь с разработчиками, значит и у всех остальных проблемы борьбы с багами в типовых конфигурацях нет.

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

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

БорисГ мудрый человек, но у него нет капли юношеского задора и идиотизма :)

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

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

(21) Что-то ты не вкуриваешь. Пишешь "...поэтому тебе придется ловить и править все глюки, а мне только в тех "местах", которые реально используются на предприятии."

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

(23) Затраты на обращение в Хотлайн могут быть сопоставимы с затратами разработку примочки по тестированию.

Нот-лайн (Not-line). Хорошо звучит. Внушаить. ;)

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

(22) Я не в том возрасте, чтобы заниматься идиотизмом ;-)

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

Ну и не забудь... 70-80% изменений типовой - это изменения в законодательстве. Посему и должна меняться постановка задачи для системы тестирования.

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

(25) А сколько раз хоть туда обращался?

(27) Я не вижу беды в том, что можно тестировать весь функционал для удовлетворения потребности всех клиентов. А можно и отдельно по клиентам. Главное что-бы было нужно.

И вообще, ты чего такой сердитый?

30
я? это ты меня сердитого не видел. когда я сердитый меня даже Товарищ Майор боиться.
А почему тестировать в ходе эксплуатации часть функуионала и тестировать в ходе тестирования весь функционал быстрее и дешевле я уже написал.

(28) Мне как раз и нужно ловить конкретные глюки при выполнении конкретных операций с конфигурацией. Чем (неизвестная мне) технология тестирования от фирмы 1С помешает мне ловить конкретные глюки в конкретных ситуациях?

А тем более если этих ситуаций можно смоделировать 100 штук и запустить пакетом?

Расхождения в результатах выполнения тестов, вызванные изменением законодательства тоже имеют определенную ценность.

Изменить постановку задачи в наборе тестов - убрать ненужный тест, добавить новый подкорректировать изменившийся - это обычная работа при ознакомлении с новым релизом, которая выполняется всегда, при ЛЮБЫХ методах тестирования - что здесь плохого, если эта работа не пропадет зазря, а будет записана, и отчасти даже формализована?

" если хочешь угрохать деньги на разработку системы которая в лучшем случае не заработает, а в худшем - заработает и создаст тебе же проблемы, то я тебе не советчик. ты сам всё решил"
(с) @LoNg. 21-й пост. Позледний абзац.

(28) "И есть еще один аспект... сколько у тебя доведенных до исправления сообщений об ошибках в любой конфигурации 1С, обнаруженных именно тобой? И есть ли среди них сложные методические вопросы?
Если нет, говорить не о чем"

Гы :)))) У меня *иська явно короче:).

Лично мной обнаружено с десяток грубых ошибок, опечаток. Причем обнаружены через проблемы у клиентов. Часть уже исправлены фирмой 1С, часть еще нет.

На решение методических проблем со своей примочкой-тестилкой я и не претендую :)

(29) И тут у меня короче...(грустно)... Но когда я работал у франча...и тут короче...(еще грустнее)

Ну и... Это все?
Просто ошибки ошибкам рознь...
Не повезло тебе с франчем... мог бы и ознакомить с технологией взаимодействия с 1С. Такой каши в голове у тебя не было бы.

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

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

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

Похоже... закончили бесплодную дискуссю.

ААА !!! Такую ветку пропустил !!!

Есть, есть уже такой инструмент автоматического тестирования !!! Блин, кто же так ищет-то, а?
http://www.yandex.ru/yandsearch?rpt=rad&text=%E0%E2%F2%EE%EC%E0%F2%E8%F7%E5%F1%EA%EE%E5+%F2%E5%F1%F2%E8%F0%EE%E2%E0%ED%E8%E5+1%D1
Первая ссылка, вашу мать...