"Новые" методологии

[fed]

Цитата:

Сообщение от axm2013

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

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

Цитата:

Сообщение от fed

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

Ну это у гуру все так легко

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

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

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

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

Цитата:

Сообщение от fed

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

Согласен с тем что порой опять же имхо при доработке напильником и топором стандарта очень не достает тестов. И не очень понятно почему микрософт их не сделало: там же тысячи индусов.

Цитата:

Сообщение от Ivanhoe

По сути - это просто дорого получается, заказчик не готов, как правило, за это платить.

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

Цитата:

Сообщение от Morpheus

Часть бизнес логики реализовано на формах или классах вызываемых из форм. Результатом работы кода являются созданные или измененные записи в разных таблицах. Поэтому задача написать и поддерживать актуальными тесты для создания журналов (ГК, склад, заказ на покупку или продажу) и контроля их разоски является не тривиальной.

Формы меньшая часть проблем. Классы же можно тестить только в путь а по идеологии весь функционал уже +- содержится в них.
Узнать что проводки появились к примеру не проблема. Проверить что они правильные по части параметров тоже Покрывать все 100% случае имхо не требуется.

[R.Safianov]

Цитата:

Сообщение от axm2013

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

И вам, добрый день!

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

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

Или вы пытаетесь мне преподать уроки TDD, BDD и их использование в распределенных системах на разных платформах? Не забывайте, реальная ERP-это давно уже не монолитный продукт, а TDD и BDD заточены под монолитные системы и перестают работать в сложных распределенных комплексах.

Цитата:

Сообщение от R.Safianov

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

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

Цитата:

Сообщение от R.Safianov

Или вы пытаетесь мне преподать уроки TDD, BDD и их использование в распределенных системах на разных платформах?

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

Цитата:

Сообщение от R.Safianov

TDD и BDD заточены под монолитные системы и перестают работать в сложных распределенных комплексах.

Почему? Как это соотносится с Dynamics Ax?

[R.Safianov]

Цитата:

Сообщение от axm2013

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



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


Почему? Как это соотносится с Dynamics Ax?

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

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

3) Потому что есть принцип системотехники: "Сложность системы управления сопоставима со сложностью объекта управления". Создавая систему автоматического тестирования, вы проектируете систему управления для системы управления. Цель которой: Поддержание работоспособности в установленных границах.
Если вы проектируете систему управления, которая масштабируемая, легко настраиваемая и т.д., то вы проектируете систему тестирования, которая тоже будет сопоставима по сложности. А при попытке создать универсальную систему сложность вырастет в разы. Если рассматривать DAX, как монолитный единый продукт, то можно использовать. Если рассматривать как комплекс интегрированных средств, то систему автоматизированного тестирования построить будет практически невозможно. Философствовать можно на эту тем сколько угодно. Можно даже почитать про "новые" методологии на хабре http://habrahabr.ru/company/piter/blog/262807/

Цитата:

Сообщение от R.Safianov

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

Уф опять реклама.
Если что это не мой опыт, а ваших коллег. "Очень сложное ТЗ, проще объяснить устно" - типичное ТЗ по интеграции одного консалта.

Цитата:

Сообщение от R.Safianov

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

Подробности будут?

Цитата:

Сообщение от R.Safianov

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

Вы не проектируете всю систему. Она уже есть и работает. Ваша задача лишь слегка модифицировать отдельные бизнес-процессы. Соответственно от вас требуется тестить ровно конкретные бизнес-процессы (их обязаны тестить в любом случае консультанты-тестировщики). И о 100% покрытии понятно речи не идет.

[R.Safianov]

Цитата:

Сообщение от axm2013

Уф опять реклама.
Если что это не мой опыт, а ваших коллег. "Очень сложное ТЗ, проще объяснить устно" - типичное ТЗ по интеграции одного консалта.


Подробности будут?


Вы не проектируете всю систему. Она уже есть и работает. Ваша задача лишь слегка модифицировать отдельные бизнес-процессы. Соответственно от вас требуется тестить ровно конкретные бизнес-процессы (их обязаны тестить в любом случае консультанты-тестировщики). И о 100% покрытии понятно речи не идет.

1) Интересная у вас "религия".
2) Нет.
3) По пунктам:
//Вы не проектируете всю систему.
Если все есть, то конечно не проектируем.

//Она уже есть и работает.
Случается и такое.

//Ваша задача лишь слегка модифицировать отдельные бизнес-процессы.
В масштабах всей системы конечно слегка.

//Соответственно от вас требуется тестить ровно конкретные бизнес-процессы (их обязаны тестить в любом случае консультанты-тестировщики). И о 100% покрытии понятно речи не идет.

Требуется и не только это. То, что вы написали про тестирование реальной системы - это 10% от всех мероприятий связанных с тестированием. Вот расскажите мне про TDD в интеграционных тестах системы следующего плана:
-Инсталяция DAX учетной системы.
-Инсталяция WMS.
-Инсталяция IIS для процессинга карт лояльности.
-Инсталяций POS.
-Инсталяция mPOS.
-Инсталяция мобильных ТСД.

Мы же когда произносим Dynamics AX все это подразумеваем? Или мы все таки говорим о тестировании монолитных кусков и говорим: Кусочки протестированы -> система в целом должна работать? Если так, то это глубокое заблуждение.

[gl00mie]

Цитата:

Сообщение от axm2013

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

У вас занятное представление о тестировании модификаций. Допустим, нужно слегка модифицировать закупку товара у поставщика: запретить создавать строки заказа на покупку с одинаковыми комбинациями кода номенклатуры и аналитик продукта (часто встречающееся ограничение, к слову сказать). Будете ли вы после реализации такой модифы тестировать, к примеру, реализацию в системе бизнес-процессов сводного планирования?

Цитата:

Сообщение от axm2013

И о 100% покрытии понятно речи не идет.

Да-да, только толку тогда от этих тестов? Они - как кусок забора посреди поля.

Цитата:

Сообщение от axm2013

Уф опять реклама. Если что это не мой опыт, а ваших коллег. "Очень сложное ТЗ, проще объяснить устно" - типичное ТЗ по интеграции одного консалта.

Это - проблемы ваших мифических знакомых из консалтинга и их клиентов.

Цитата:

Сообщение от axm2013

Подробности будут?

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

Цитата:

Сообщение от Ivanhoe

axm2013 с вами тяжело вести диалог, вы все к своему сводите. Чтобы понимать контекст, сколько проектов вы сделали?