Я не думаю, что у нас есть четкий предмет для спора. У вас системный подход, сверху и донизу, тут вообще никаких нет вопросов. И я думаю, что 1С тоже делает тоже всё по стандартам, по критериям, и цифровые показатели покрытия у них на высоте. Тут как раз всё четко и понятно, а не понять, о чем вы пишите – невозможно. Другой вопрос — это не всегда работает. При всем богатстве методик и численных оценок, остается неудобный вопрос – почему тестирование на коленке, выявляет проблемы быстрее и раньше, чем тестирование по науке. Не подумайте, что я анархист какой-то, я тоже вижу порядок через игру по правилам, просто этот вопрос призван акцентировать внимание не только на методике по всей цепи, а и задуматься над тем, как происходит процесс разработки тестов, как организована сама рутина.
P.S. Спасибо за мою положительную оценку. Компанию ТехноНиколь я не знаю.
Спасибо за развернутый комментарий!
Но самое важное из всего сказанного я вижу здесь:
показанный вами сценарий с оплатой мы делали за 40 минут для ERP 2 и Бухгалтерии 3.0, но на мой взгляд это совсем не показатель.
Вот именно в этом месте я думаю наши точки зрения и расходятся, потому что это как раз и показатель, и это очень важно. Видимо, у нас разная выборка проблем. Стандарты, методики, терминология – это всё полезная информация. А вот ситуация, что в часы не вкладывают тестирование, это факт, который практически никак не подвержен изменениям под влиянием вышеуказанных знаний. Расшифрую: вы сколько угодно долго можете убеждать программиста пилящего обработку для инфостарта (выражения взято из ваших роликов) что тестирование – это эффективно, и ему воздастся за это, но в тоже самое время, утверждаете, что время потраченное на разработку теста – не показатель. Я против той точки зрения, что 1с-программисты такие вот «тёмные» люди, стандартов не читавшие, а вот если прочтут, то спустится на них озарение.
И совершенно неважно, как вы называете руководителя тестирования, QA-инженером или еще как-то, но если инструментарий не позволяет делать работу эффективно, все остальные процессы становятся неинтересными.
У вас есть много роликов и по часу, и по полтора. Если есть возможность сделать ролик на 40 минут, где в реальном времени создаётся указанный мной выше библиотечный тест – вы сделаете большой шаг навстречу обычному программисту.
Под качеством тестов понимаются очень конкретные вещи, но формат общения, в виде комментариев на тему, не предназначен для детальных выкладок. Приведенный вами скриншот, особой ясности также не добавляет. Своим сообщением, я хотел обратить внимание автора на эту тему с тестированием, потому что она упоминалась и в прошлых статьях, надеюсь, информация дошла по назначению.
На счет Ванессы, к сожалению принцип записи тестов там такой же, как в сценарном тестировании, поэтому я и мои коллеги довольно сдержанно относимся к этому продукту.
Если у вас есть возможность продемонстрировать, на примере ERP2 (демо), создание теста за часа три-четыре: Приход / Расход / Оплата, с анализом/проверкой проводок каждого документа, формированием/проверкой отчетов и затем переиспользование этого теста для организации другой цепи сценария, с другими товарами/услугами/валютой/контрагентами внутри, тогда это бы полностью закрыло все вопросы, говорю честно, не только для меня, но и для многочисленных 1С программистов. Из всего, что я видел по ванессе, выступления и другие ролики, содержат по большей части методику и технику развертывания.
У системы Тестер, с которой вы наверняка знакомы, очень мало инструментов по формированию отчетов по результатам тестирования, и других аналитических возможностей с дружественным интерфейсом, но с одной задачей он справляется хорошо — возможность быстро и коллективном режиме создавать тесты, не только как описал заказчик в тех задании, но и насколько качественно хочет это сделать сам разработчик или руководитель тестирования, покрывая всевозможные отклонения, нажатие кнопок, которые могут генерировать или задавать лишние вопросы и другое. На своей практике, именно этот момент мы считаем ключевым, и именно прогон таких тестов не раз показывал наличие ошибок в платформе.
Жаль, что для типовых конфигураций тестов еще маловато, похоже, и они не выносятся в общий доступ для возможности их расширения всей сетью партнеров и пользователей.
Я очень ценю, что делает 1С, но позволю себе немного жесткой критики.
После продолжительного использования сценарного тестирования своей разработки, есть основание серьёзно задуматься на счет глубины проработки таких тестов в самой 1С. Другими словами — качество, а не количество этих тестов.
В объекте ТестируемоеПриложение, были ошибки (и частично еще остались), которые делали практически невозможным анализ ошибок клиента тестирования. И это выявляется сразу, при прогоне тестов, почему этого не заметили внутри 1С — я думаю потому что разработчик сценарного тестирования (конфигурации) не не был осведомлен о проблеме.
Давайте на чистоту, Петр пишет, что сценарное тестирование проводится, но при этом:
1. Когда я на партнерсах спросил разработчика конфигурации сценарное тестирование 3, используется ли эта разработка внутри 1С, я получил ответ — спросите у разработчиков.
2. Собственный опыт разработки тестов, не раз выявлял ошибки в платформе. Вопрос: почему внутри 1С, их сценарные тесты для типовых конфигураций проходят?
Я думаю, как минимум, на заметку 1С нужно взять то, какого качества эти тесты, что они проводят (я про типовые конфигурации). Например, даже в последней 8.3.9, если тестом заполнять табличную часть у которой последняя колонка автовыбор незаполненного — платформа начинает забивать табличную часть новыми строками, пока не завершит работу аварийно, нет возможности проверить ошибки, выдаваемые в модальных окнах, нет возможности нажимать на ссылки в декорациях, что, например, делает невозможным прогон тестов объектов, где это используется (например, в ERP2 справочник Виды номенклатуры, там невозможно нажать на Тип номенклатуры).
Вот и застряла мысль, вроде как тесты делаются, но насколько они качественные? Очень хочу ошибаться, но видимо все эти тесты сделаны на базе записи прокликиваний на коротких дистанциях.
ИМХО разработчикам бизнес-приложений «вся мощь современных языков» скорее вредит, чем помогает.
К сожалению, эта мысль очень сильно укоренилась в 1С, и сама по себе тоталитарна, уж простите. Ведь таким образом, вы решаете за разработчика, что ему будет лучше с одной стороны, но при этом утверждать, что выражении x++ хуже чем x = x + 1, никак нельзя.
Прикладное программирование, конечно, не имеет дело с регистрами процессора или прямой работой с памятью, но оно от этого не перестало быть программированием, мы просто решаем другие задачи.
Я думаю сильно не ошибусь, но уже более 10 лет язык 1С не развивается. Наверное, нет ни одной типовой конфигурации 1С, где кол-во строк кода было бы меньше 100 тысяч. И к чему приводит эта «простота»? Загляните в модуля, посмотрите, что там происходит, многословные префиксы и суффиксы, ни к чему не обязывающие попытки описания интерфейсов через #Область, имена общих модулей и идентификаторов длиною под 100 символов (Пример: ЭлектронныйДокументооборотСКонтролирующимиОрганамиОбновлениеИнформационнойБазы), огромные процедуры с кучей параметров, проверки внутри проверок.
Развитие языка как раз для того и нужно, чтобы писать код было проще, но почему в 1С решили, что чтобы писать код проще – нужно остановить развитие языка, просто непонятно.
Армия разработчиков 1С почти всегда голосует против нововведений по очень простой причине:
1) не хочу никого обидеть, но разработчиков на 1С как таковых не так уж и много, подавляющее большинство, занимается доработками уже созданных решений
2) Люди устали, они просто только-только свыклись с управляемыми форми, тока поняли, как переделывать всё под асинхронность, тока-тока нащупали стабильные релизы, а тут какие-то умники заряжают про интерфейсы, классы и другое в 1С. Многим, когда 500 рыл в базе, звонки каждую минуту и другой головняк, подобные заявления кажутся «несерьёзными».
Никто не говорит про ООП, но ребята, ёлы-палы, давайте что-то делать с языком, хотя бы начать с namespace-ов каких-то, ну это же уже не дело.
понимаете, тут просто смысл в том, что после того, как открыли дверь, повышается вероятность той двери, которая осталась, и если каждый раз её и выбирать, по вероятности, там чаще окажется машина.
Всё верно сказано (правда на счет тролинга не знаю, это моя первая тут статья), единственно дополню, что еще одной из задач этой системы было решение проблемы программиста «оставаться в фокусе». Ведь кроме всего прочего, фокус часто теряется при выполнении рутины, при должном усердии, данный подход позволяет очень четко организовать ветвь самого процесс разработки. В половине проектов – это работает, в другой половине, таки да, тесты пишутся после.
да-да, конечно, перед тем как начать писать свое, прошлись по всему что было. Возможно я не знаю в деталях, как обстоят дела в последних версиях, но на тот момент мы точно определили, что запись-воспроизведение сценария, или использование геркина, нам не подходит. Тут ведь еще как, некоторые схватывают на лету, а некоторым просветление приходит через руки, вот мы из второй группы :-)
есть просто такой общий клиентский модуль Test, его дизайнер и показывает, конечно, переопределить общий модуль программно нельзя, но и данное присвоение сделано только для try/except
простите, я не понял два сообщения выше. Вся работа с числами происходит на стороне клиента, и представлена менеджеру тестирования в виде строк, таким образом, если нужно проверить что Цена 5 * Кол-во 20 будет равно 100, в зависимости от места запуска клиентского приложения, результат может быть «100.00» или «100,00». Тоже касается и присвоения полям значений.
XMLString () на тонком клиенте недоступен.
P.S. Спасибо за мою положительную оценку. Компанию ТехноНиколь я не знаю.
Но самое важное из всего сказанного я вижу здесь:
Вот именно в этом месте я думаю наши точки зрения и расходятся, потому что это как раз и показатель, и это очень важно. Видимо, у нас разная выборка проблем. Стандарты, методики, терминология – это всё полезная информация. А вот ситуация, что в часы не вкладывают тестирование, это факт, который практически никак не подвержен изменениям под влиянием вышеуказанных знаний. Расшифрую: вы сколько угодно долго можете убеждать программиста пилящего обработку для инфостарта (выражения взято из ваших роликов) что тестирование – это эффективно, и ему воздастся за это, но в тоже самое время, утверждаете, что время потраченное на разработку теста – не показатель. Я против той точки зрения, что 1с-программисты такие вот «тёмные» люди, стандартов не читавшие, а вот если прочтут, то спустится на них озарение.
И совершенно неважно, как вы называете руководителя тестирования, QA-инженером или еще как-то, но если инструментарий не позволяет делать работу эффективно, все остальные процессы становятся неинтересными.
У вас есть много роликов и по часу, и по полтора. Если есть возможность сделать ролик на 40 минут, где в реальном времени создаётся указанный мной выше библиотечный тест – вы сделаете большой шаг навстречу обычному программисту.
На счет Ванессы, к сожалению принцип записи тестов там такой же, как в сценарном тестировании, поэтому я и мои коллеги довольно сдержанно относимся к этому продукту.
Если у вас есть возможность продемонстрировать, на примере ERP2 (демо), создание теста за часа три-четыре: Приход / Расход / Оплата, с анализом/проверкой проводок каждого документа, формированием/проверкой отчетов и затем переиспользование этого теста для организации другой цепи сценария, с другими товарами/услугами/валютой/контрагентами внутри, тогда это бы полностью закрыло все вопросы, говорю честно, не только для меня, но и для многочисленных 1С программистов. Из всего, что я видел по ванессе, выступления и другие ролики, содержат по большей части методику и технику развертывания.
У системы Тестер, с которой вы наверняка знакомы, очень мало инструментов по формированию отчетов по результатам тестирования, и других аналитических возможностей с дружественным интерфейсом, но с одной задачей он справляется хорошо — возможность быстро и коллективном режиме создавать тесты, не только как описал заказчик в тех задании, но и насколько качественно хочет это сделать сам разработчик или руководитель тестирования, покрывая всевозможные отклонения, нажатие кнопок, которые могут генерировать или задавать лишние вопросы и другое. На своей практике, именно этот момент мы считаем ключевым, и именно прогон таких тестов не раз показывал наличие ошибок в платформе.
Я очень ценю, что делает 1С, но позволю себе немного жесткой критики.
После продолжительного использования сценарного тестирования своей разработки, есть основание серьёзно задуматься на счет глубины проработки таких тестов в самой 1С. Другими словами — качество, а не количество этих тестов.
В объекте ТестируемоеПриложение, были ошибки (и частично еще остались), которые делали практически невозможным анализ ошибок клиента тестирования. И это выявляется сразу, при прогоне тестов, почему этого не заметили внутри 1С — я думаю потому что разработчик сценарного тестирования (конфигурации) не не был осведомлен о проблеме.
Давайте на чистоту, Петр пишет, что сценарное тестирование проводится, но при этом:
1. Когда я на партнерсах спросил разработчика конфигурации сценарное тестирование 3, используется ли эта разработка внутри 1С, я получил ответ — спросите у разработчиков.
2. Собственный опыт разработки тестов, не раз выявлял ошибки в платформе. Вопрос: почему внутри 1С, их сценарные тесты для типовых конфигураций проходят?
Я думаю, как минимум, на заметку 1С нужно взять то, какого качества эти тесты, что они проводят (я про типовые конфигурации). Например, даже в последней 8.3.9, если тестом заполнять табличную часть у которой последняя колонка автовыбор незаполненного — платформа начинает забивать табличную часть новыми строками, пока не завершит работу аварийно, нет возможности проверить ошибки, выдаваемые в модальных окнах, нет возможности нажимать на ссылки в декорациях, что, например, делает невозможным прогон тестов объектов, где это используется (например, в ERP2 справочник Виды номенклатуры, там невозможно нажать на Тип номенклатуры).
Вот и застряла мысль, вроде как тесты делаются, но насколько они качественные? Очень хочу ошибаться, но видимо все эти тесты сделаны на базе записи прокликиваний на коротких дистанциях.
https://github.com/grumagargler
там три репозитория, с тестером, и самими тестами
К сожалению, эта мысль очень сильно укоренилась в 1С, и сама по себе тоталитарна, уж простите. Ведь таким образом, вы решаете за разработчика, что ему будет лучше с одной стороны, но при этом утверждать, что выражении x++ хуже чем x = x + 1, никак нельзя.
Прикладное программирование, конечно, не имеет дело с регистрами процессора или прямой работой с памятью, но оно от этого не перестало быть программированием, мы просто решаем другие задачи.
Я думаю сильно не ошибусь, но уже более 10 лет язык 1С не развивается. Наверное, нет ни одной типовой конфигурации 1С, где кол-во строк кода было бы меньше 100 тысяч. И к чему приводит эта «простота»? Загляните в модуля, посмотрите, что там происходит, многословные префиксы и суффиксы, ни к чему не обязывающие попытки описания интерфейсов через #Область, имена общих модулей и идентификаторов длиною под 100 символов (Пример: ЭлектронныйДокументооборотСКонтролирующимиОрганамиОбновлениеИнформационнойБазы), огромные процедуры с кучей параметров, проверки внутри проверок.
Развитие языка как раз для того и нужно, чтобы писать код было проще, но почему в 1С решили, что чтобы писать код проще – нужно остановить развитие языка, просто непонятно.
Армия разработчиков 1С почти всегда голосует против нововведений по очень простой причине:
1) не хочу никого обидеть, но разработчиков на 1С как таковых не так уж и много, подавляющее большинство, занимается доработками уже созданных решений
2) Люди устали, они просто только-только свыклись с управляемыми форми, тока поняли, как переделывать всё под асинхронность, тока-тока нащупали стабильные релизы, а тут какие-то умники заряжают про интерфейсы, классы и другое в 1С. Многим, когда 500 рыл в базе, звонки каждую минуту и другой головняк, подобные заявления кажутся «несерьёзными».
Никто не говорит про ООП, но ребята, ёлы-палы, давайте что-то делать с языком, хотя бы начать с namespace-ов каких-то, ну это же уже не дело.
таким образом определяется, доступен ли менеджер тестирования, другими словами, запущен ли тестер с флагом /TESTMANAGER
XMLString () на тонком клиенте недоступен.
p.s. парни из xUnitFor1C тоже большое дело делают, но у них чуть подход другой.