AXForum  
Вернуться   AXForum > Рынок > Методология внедрения
CRM
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.08.2015, 11:36   #1  
axm2013
Гость
 
n/a
"Новые" методологии
Просто интересная статья и обсуждение по TDD.
http://habrahabr.ru/post/206828/

В принципе, как понимаю, пока слабо распространено на уровне концепции для проектов Dynamics Ax, но все же интересно наравне с Agile-ом в сравнении с традиционным подходом.

Последний раз редактировалось axm2013; 24.08.2015 в 11:57.
Старый 24.08.2015, 14:02   #2  
vaavr is offline
vaavr
Участник
 
72 / 16 (1) ++
Регистрация: 07.06.2002
Про подход TDDничего плохого сказать не могу, как и прочие подходы он имеет свою область определения. Но вот автор явно находится под воздействием рекламы отеля Риксос. Много хвалебных слов, но полное отсутствие описание самого объекта.
Старый 24.08.2015, 16:14   #3  
axm2013
Гость
 
n/a
Их есть у меня.
http://18delphi.blogspot.ru/
думается автор просто накидывал примеры у себя в блоге и соответственно счел излишним вдаваться в подробности в интервью.
+ он как правило эмоционален (холерик?) http://18delphi.blogspot.ru/2013/03/blog-post.html
Просто некоторые выражения понравились +- типа
"Тесты — это «архивированная память», а также «документация» и «варианты использования». "

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

Зачастую при поддержке: бага по сути тест рождает дальнейшее тз и прочее.
В Ax в силу разных вещей почему то данный подход пока не прижился хотя хз почему.

Последний раз редактировалось axm2013; 24.08.2015 в 16:37.
Старый 24.08.2015, 16:40   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от axm2013 Посмотреть сообщение
[url]
Зачастую при поддержке: бага по сути тест рождает дальнейшее тз и прочее.
В Ax в силу разных вещей почему то данный подход пока не прижился хотя хз почему.
По одной очень простой причине: При разработке на Аксапте достаточно легко оттестировать разработанную функциональность. И очень нелегко оттестировать все те места в стандарте, которая эта функциональность может сломать. Писать свои собственные тесты для стандартной функциональности - не реально. Написать тесты для своей собственной функциональности можно, но будет ловить 10% ошибок (причем ошибок достаточно банальных - которые и руками не тяжело выловить).
За это сообщение автора поблагодарили: Михаил Андреев (1), AP-1055D (1).
Старый 24.08.2015, 17:07   #5  
Morpheus is offline
Morpheus
Участник
Аватар для Morpheus
Соотечественники
 
602 / 164 (7) ++++++
Регистрация: 30.03.2005
Адрес: Київ-København-Düsseldorf
Цитата:
Сообщение от axm2013 Посмотреть сообщение
В Ax в силу разных вещей почему то данный подход пока не прижился хотя хз почему.
Часть бизнес логики реализовано на формах или классах вызываемых из форм. Результатом работы кода являются созданные или измененные записи в разных таблицах. Поэтому задача написать и поддерживать актуальными тесты для создания журналов (ГК, склад, заказ на покупку или продажу) и контроля их разоски является не тривиальной.

Интересно, как в самрой MS проходит процесс тестирования? Как выявляют регрессии? Неужели этот процесс не автомаизирован?
За это сообщение автора поблагодарили: mazzy (2).
Старый 24.08.2015, 17:59   #6  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Вроде автоматизирован:
Цитата:
Сообщение от kashperuk Посмотреть сообщение
И да, мы используем SysTest для написания тестов. Точнее девелоперы. Мы пишем функциональные тесты с использованием других инструментов
PS. Также тестирование стандарта обсуждалось в теме есть ли желание сделать русский chanel 9?

Последний раз редактировалось gl00mie; 24.08.2015 в 18:08. Причина: PS
Старый 24.08.2015, 18:03   #7  
Morpheus is offline
Morpheus
Участник
Аватар для Morpheus
Соотечественники
 
602 / 164 (7) ++++++
Регистрация: 30.03.2005
Адрес: Київ-København-Düsseldorf
Цитата:
Сообщение от kashperyk Посмотреть сообщение
Мы пишем функциональные тесты с использованием других инструментов:
Каких инструментов? Почему эти инструменты недоступны партнерам и клиентам?
Старый 24.08.2015, 22:41   #8  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Соглашусь с fed. По сути - это просто дорого получается, заказчик не готов, как правило, за это платить.
__________________
Ivanhoe as is..
Старый 25.08.2015, 08:30   #9  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Morpheus Посмотреть сообщение
Каких инструментов? Почему эти инструменты недоступны партнерам и клиентам?
Рискну предположить что:
1. Все это написано на зоопарке систем (типа часть тестов иммитирует ручной ввод, часть тестов просто вызывают X++ классы, часть тестов иммитируют HTTP-взаимодействие) и синтегрировано при помощи make, powerscript и какой-то матери.
2. Даже если каким-то образом заинтегрировать по-человечески тесты из пункта 1, не факт что свободная раздача этих тестов партнерам и клиентам сильно поможет. В этом случае разработчику на внедрении придется не только разбираться что и в каких стандартных классах подправить для кастомизации, но и разбираться что и в каких тестах поменять чтобы потом исправленные тесты правильно работали. И потом еще исправленные тесты тестировать и отлаживать То есть - трудозатраты на разработку в этом случае вырастут раза в 2-3.
3. Клиенты не готовы платить за автоматизированное тестирование. В реальности все проекты, которые я видел, обходились достаточно поверхностным тестированием консультантами и прогоном основных бизнес-процессов пользователями во время тренингов перед запусками. Если чего-то ломалось - чинили на ходу. Реально дешевле оплатить 10-15-20 человеко-дней авралов на починку кода и исправление данных, чем просто заплатить не за 6 человеко-месяцев разработки, а за 12-15...
За это сообщение автора поблагодарили: macklakov (1), sukhanchik (2), Morpheus (3), gl00mie (2).
Старый 25.08.2015, 09:10   #10  
axm2013
Гость
 
n/a
Цитата:
Сообщение от Morpheus Посмотреть сообщение
Каких инструментов? Почему эти инструменты недоступны партнерам и клиентам?
SysTest*
https://msdn.microsoft.com/en-us/library/aa874515.aspx
?
Старый 25.08.2015, 10:40   #11  
axm2013
Гость
 
n/a
Цитата:
Сообщение от fed Посмотреть сообщение
По одной очень простой причине: При разработке на Аксапте достаточно легко оттестировать разработанную функциональность. И очень нелегко оттестировать все те места в стандарте, которая эта функциональность может сломать.
Ну это у гуру все так легко

Я же как средний разработчик наблюдал случаи, когда ломает порой даже не в стандарте а и в разработанной функциональности особенно если разработчиков много. В общем то с "хождением по граблям" сталкивался не сказать что часто но регулярно (с меньшим драматизмом чем у автора но все же).
Очень похоже описано у автора статьи:
"И я ОЧЕНЬ долго правил код "машины печати". И попадал в "программистские качели". Правишь тут - сломалось там.. правишь там - сломалось тут.. И так - БЕСКОНЕЧНО... Мозги готовы били вскипеть... Хотелось убить кого-нибудь рядом... Функционал - не сходился...

А ещё Группа Качества находила одну ошибку за другой.. Группа Качества была как Бич Божий!! Они находили ошибки БЫСТРЕЕ, чем я их исправлял...

Всё время находилась 150-я страница документа, или 300-я или 550-я.. Которая не печаталась.. Или на которой приложение тупо падало...."

Причем тут еще все хорошо так как он знал что ошибка есть.

Цитата:
Сообщение от fed Посмотреть сообщение
Писать свои собственные тесты для стандартной функциональности - не реально. Написать тесты для своей собственной функциональности можно, но будет ловить 10% ошибок (причем ошибок достаточно банальных - которые и руками не тяжело выловить).
Согласен с тем что порой опять же имхо при доработке напильником и топором стандарта очень не достает тестов. И не очень понятно почему микрософт их не сделало: там же тысячи индусов.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
По сути - это просто дорого получается, заказчик не готов, как правило, за это платить.
Не уверен что это дорого. Консультант в ходе тестирования полноценного делает мартышкину работу в сотни заказов к примеру: автоматизация процесса спасла бы десятки если не сотни часов. Вопрос лишь в том чо постановкой подобных задач занимается как правило консультант, а он в силу причин поднимаемых ранее (слабое описание функционала и развития на русском) не в курсе о возможностях автоматизированного тестирования + нет опыта (мало кто из консультантов смотрит что творится в сфере разработки порой) и страшно рисковать. Ну и конечно то что некоторые консалты (R.Safianov привет ) не рассматривают все внедрение в совокупности как единый проект, а лишь как набор отдельных проектов по стадиям и соответственно на стадии сопровождения продукта к примеру где тесты начинают играть очень важную роль ничего нет.

Цитата:
Сообщение от Morpheus Посмотреть сообщение
Часть бизнес логики реализовано на формах или классах вызываемых из форм. Результатом работы кода являются созданные или измененные записи в разных таблицах. Поэтому задача написать и поддерживать актуальными тесты для создания журналов (ГК, склад, заказ на покупку или продажу) и контроля их разоски является не тривиальной.
Формы меньшая часть проблем. Классы же можно тестить только в путь а по идеологии весь функционал уже +- содержится в них.
Узнать что проводки появились к примеру не проблема. Проверить что они правильные по части параметров тоже Покрывать все 100% случае имхо не требуется.

Последний раз редактировалось axm2013; 25.08.2015 в 10:46.
Старый 25.08.2015, 11:12   #12  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
396 / 478 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
Дали мне как-то фичу довести до ума, которую написал за несколько месяцев до этого фрилансер. Фичу эту никто не использовал, т.к. она просто не работала, и нужно было это дело исправить.

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

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

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

Очень рекомендую написать такой класс при малейших намеках на регулярные новые требования для одной и той же фичи.
Старый 25.08.2015, 11:17   #13  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
axm2013 с вами тяжело вести диалог, вы все к своему сводите. Коллеги с вами поделились мнениями, мнения плюс минус одинаковые, почему вы считаете, что вы правы, а оппоненты нет?
Чтобы понимать контекст, сколько проектов вы сделали?
__________________
Ivanhoe as is..
Старый 25.08.2015, 11:37   #14  
axm2013
Гость
 
n/a
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
axm2013 с вами тяжело вести диалог, вы все к своему сводите.
Возможно.
Работаю над тем чтобы было легче, если видите какие то спорные моменты буду рад если укажите проблемы.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Коллеги с вами поделились мнениями, мнения плюс минус одинаковые, почему вы считаете, что вы правы, а оппоненты нет?
Я поделился своим своим видением и сомнениями. И где при этом посчитал что коллеги не правы? Давайте не будем фантазировать.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Чтобы понимать контекст, сколько проектов вы сделали?
А вы?
И сколько раз вы лично использовали Unit test framework? Почему?
Старый 25.08.2015, 11:43   #15  
AlexeyS is offline
AlexeyS
Участник
 
404 / 339 (12) ++++++
Регистрация: 15.06.2004
Адрес: москва
целая коллекция методологий, познавательно
Fear Driven Development
Hope Driven Development
Debt-Driven Development
Ping Pong Development
http://blogerator.ru/page/bagopedija...rammista-sleng
Старый 25.08.2015, 14:51   #16  
axm2013
Гость
 
n/a
ЗЫ кстати
http://smart-talks.org/event/smart-talks-22/

"Построение приложения при помощи TDD. Часть 1. (Level 300)

Попробуем построить приложение используя TDD. Часть первая – вводная и постановочная. Пример будет основан на реально работающем приложении."

Если что к smart-talks отношения не имею
Старый 25.08.2015, 18:29   #17  
R.Safianov is offline
R.Safianov
Участник
Аватар для R.Safianov
MCBMSS
Columbus IT
Лучший по профессии 2014
 
110 / 118 (4) +++++
Регистрация: 25.06.2008
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Ну это у гуру все так легко
Ну и конечно то что некоторые консалты (R.Safianov привет ) не рассматривают все внедрение в совокупности как единый проект, а лишь как набор отдельных проектов по стадиям и соответственно на стадии сопровождения продукта к примеру где тесты начинают играть очень важную роль ничего нет.
И вам, добрый день!

Ну, раз пошла такая пьянка...

Не вижу противоречий и совсем не понимаю, как это относится к восприятию проекта. Вы опять пытаетесь "мягкое" назвать "теплым".
Если вы задаетесь целью создать по завершению проекта продукт, который является решением + тест скриптами, то что вам помешает это сделать даже выделив создание тест скриптов в отдельный проект?

Или вы пытаетесь мне преподать уроки TDD, BDD и их использование в распределенных системах на разных платформах? Не забывайте, реальная ERP-это давно уже не монолитный продукт, а TDD и BDD заточены под монолитные системы и перестают работать в сложных распределенных комплексах.
Старый 26.08.2015, 11:00   #18  
axm2013
Гость
 
n/a
Цитата:
Сообщение от R.Safianov Посмотреть сообщение
Если вы задаетесь целью создать по завершению проекта продукт, который является решением + тест скриптами, то что вам помешает это сделать даже выделив создание тест скриптов в отдельный проект?
Когда проекты разбиты на мелкие составные якобы независимые части то получаем на выходе:
планирование - внедрять не нам, так что о тестах думать не будем.
разработка: +- работать не нам + мы еще переделаем то что напланировали до нас
собственно запуск и поддержка: уже поздно что то менять + мы тут от случая к случаю.
Если что примеры такого знаю от ваших коллег. В итоге при всей необходимости автоматизированных тестов и вообще внимательном отношении к этому (сначала тест потом остальное к примеру) на выходе их не видим.


Цитата:
Сообщение от R.Safianov Посмотреть сообщение
Или вы пытаетесь мне преподать уроки TDD, BDD и их использование в распределенных системах на разных платформах?
А вы их использовали на практике?

Цитата:
Сообщение от R.Safianov Посмотреть сообщение
TDD и BDD заточены под монолитные системы и перестают работать в сложных распределенных комплексах.
Почему? Как это соотносится с Dynamics Ax?

Последний раз редактировалось axm2013; 26.08.2015 в 11:04.
Старый 26.08.2015, 11:26   #19  
R.Safianov is offline
R.Safianov
Участник
Аватар для R.Safianov
MCBMSS
Columbus IT
Лучший по профессии 2014
 
110 / 118 (4) +++++
Регистрация: 25.06.2008
Цитата:
Сообщение от axm2013 Посмотреть сообщение
Когда проекты разбиты на мелкие составные якобы независимые части то получаем на выходе:
планирование - внедрять не нам, так что о тестах думать не будем.
разработка: +- работать не нам + мы еще переделаем то что напланировали до нас
собственно запуск и поддержка: уже поздно что то менять + мы тут от случая к случаю.
Если что примеры такого знаю от ваших коллег. В итоге при всей необходимости автоматизированных тестов и вообще внимательном отношении к этому (сначала тест потом остальное к примеру) на выходе их не видим.



А вы их использовали на практике?


Почему? Как это соотносится с Dynamics Ax?
1) Мне искренне печально за ваш опыт. Ваша "бизнес-машина" внедрения не работает. У нас есть пайп-лайн клиенты, к которым я возвращаюсь даже через три года и там все работает как часы. Продукты создаются правильные, документация на высоком уровне. Передача знаний отрабатывает быстро.

2) Использовал. Я бы не говорил о том, чего не использовал.

3) Потому что есть принцип системотехники: "Сложность системы управления сопоставима со сложностью объекта управления". Создавая систему автоматического тестирования, вы проектируете систему управления для системы управления. Цель которой: Поддержание работоспособности в установленных границах.
Если вы проектируете систему управления, которая масштабируемая, легко настраиваемая и т.д., то вы проектируете систему тестирования, которая тоже будет сопоставима по сложности. А при попытке создать универсальную систему сложность вырастет в разы. Если рассматривать DAX, как монолитный единый продукт, то можно использовать. Если рассматривать как комплекс интегрированных средств, то систему автоматизированного тестирования построить будет практически невозможно. Философствовать можно на эту тем сколько угодно. Можно даже почитать про "новые" методологии на хабре http://habrahabr.ru/company/piter/blog/262807/
За это сообщение автора поблагодарили: Kabardian (3).
Старый 26.08.2015, 11:52   #20  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
;)
Цитата:
Сообщение от Morpheus Посмотреть сообщение
Каких инструментов?
SysTest + самописный фреймфорк для UI тестирования.

Цитата:
Почему эти инструменты недоступны партнерам и клиентам?
Они недостаточно продуктизированы, насколько я знаю.

P.S. UI - тесты медленные и хрупкие. Для хороших модульных тестов нужны хорошие модули.
За это сообщение автора поблагодарили: R.Safianov (2).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Вебинар "Qlik Sense: новые способы работы с информацией" 23 января 2015 года в 11.00 George Nordic Обучение 1 20.01.2015 10:29
rumicrosofterp: AX 2012 R3: Вебинар "Новые технологии управления проектами" Blog bot Microsoft и системы Microsoft Dynamics 4 02.12.2014 10:04
"МЕЛОМАН-MARWIN" создает единую систему управленческого учета по холдингу на базе Microsoft Dynamics AX с помощью готового решения "OmegaPlus: Бюджетирование и казначейство" N.Shmel Полезное по Microsoft Dynamics 0 29.07.2014 11:54
rumicrosofterp: AX 2012: Лабораторный класс "WHS Расширенное управление складом в AX 2012 R3. Новый модуль, новые возможности" Blog bot Microsoft и системы Microsoft Dynamics 2 16.05.2014 10:19
Мы ищем программиста AX 2009 Модули: "Расчеты с клиентами", "Производство", "Расчеты с поставщиками", "Управление запасами", "Основные средства", Москва MikhailK2 Рынок труда Microsoft Dynamics 0 11.12.2013 15:42
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:51.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.