Тестирование в 365

[axm2017]

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

Но тут сталкиваюсь с проблемой слабой освещенности темы и официальных рекомендаций.

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

Какие последние официальные тренды на авто тестирование (в том же MS, если кто обладает информацией)?

Обязательно/желательно ли реализовывать через ATL и если да то почему?
Или поф и в том же MS фигачат как и раньше?

Об ATL
https://docs.microsoft.com/en-us/dyn...e-test-library

Есть ли смысл писать сложные сценарии в тестах?
Где взять тесты на стандарт если очень хочется и поф на красоту кода?

Ну и вообще кто что думает.

ЗЫ и кто использовал
https://docs.microsoft.com/en-us/dyn.../rsat-overview
полезная ли вещь?

[brome]

RSAT осваиваю сейчас.
Есть ограничение, работает только в облачной версии. И в DevBox.

[axm2017]

Цитата:

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

RSAT осваиваю сейчас.
Есть ограничение, работает только в облачной версии. И в DevBox.

Как понимаю речь идет о
https://docs.microsoft.com/en-us/dyn.../rsat-overview
И как успехи?

[trud]

Я бы смотрел на ATL если говорить о тестировании как процессе поиска ошибок.
RSAT тоже нормально, но это о другом, т.е. в моем понимании RSAT это автоматизацию базовых проверок перед отправкой решения в PROD(т.е. то что ключевые формы открываются, какие-то простые процессы не валятся)
Microsoft вроде бы пишет тесты для всех багов
https://kashperuk.blogspot.com/2021/...s-on-test.html
Как правило проблема на проекте это то, что часто разработчик не может сам полностью протестировать функционал(т.е. к примеру есть трудности с созданием исходных данных или настроек) или сложности с воспроизведением целиком процесса. Это еще одна проблема которую надо решать перед введением автотестов

[fed]

Цитата:

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

Microsoft вроде бы пишет тесты для всех багов
https://kashperuk.blogspot.com/2021/...s-on-test.html

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

Возникает вопрос - будет ли эта чудо-схема с автоматизированным тестированием работать, если исключить из нее бесплатное тестирование пользователями ?

[axm2017]

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

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

Atl не очень осознаю пока в чем бонус в сравнении с обычными тестами.

Понятно что такой подход накладывает отпечаток на архитектуру: её надо делать с расчетом под тесты. Отсюда в том числе и микросервисы становятся актуальнее.

[Stitch_MS]

Цитата:

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

Atl не очень осознаю пока в чем бонус в сравнении с обычными тестами.

Про бонусы и вообще про ATL можно узнать тут:

https://youtu.be/0ASFuw-kQ94

[fed]

Цитата:

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

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

Atl не очень осознаю пока в чем бонус в сравнении с обычными тестами.

Понятно что такой подход накладывает отпечаток на архитектуру: её надо делать с расчетом под тесты. Отсюда в том числе и микросервисы становятся актуальнее.

Не сомневаюсь, что это работает для MS. Даже если клиент недоволен тем, что его как бесплатного тестера используют, остановить идущий проект на D365 и заменить систему на SAP или что-то подобное - очень тяжело.
Вопрос - будет ли подобная схема работать в ситуации внедряющей фирмы ? Поменять одного внедренца на другого не очень тяжело. Особенно если внедренец сначала выставляет дополнительные счета на разработку автоматизированного тестирования, потом пользователи в ручную ошибки ищут, а потом еще внедренец выставляет счета на доработку автоматических тестов...

[axm2017]

Цитата:

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

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

На самом деле по моему мнению это могло бы взлететь и на внедренце: особенно при условии что MS дали бы свои десятки тысяч тестов и внедренец, как минимум спал бы спокойнее, зная что его функционал не ломает стандарт по крайне мере по тестам. Качество кода тестов если честно при этом лично меня не сильно пугает: знаю что в MS работают люди и они могут всякое.

Если внедренец покрывает тестами свою модель и функционал то исправление ошибки с новым тестом гарантирует что она не повторится и в общем то рост расходов на разработку в рамках 10-20% на создание простых автотестов на мой взгляд можно как то оправдать и перед клиентом.

В подобной статье (нарыл по гуглу) на мой взгляд указаны нормально доводы +-:
https://quality-lab.ru/blog/%D0%BA%D...8%D0%BC%D1%83/
О необходимости автоматизации тестирования говорят такие факторы:

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

[mazzy]

Цитата:

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

Как понимаю MS, закрыл часть тестов по причине...

В тестах нет магии.
Тест предполагает, что:
1. есть некое зафиксированное начальное состояние.
2. в этом начальном состоянии выполняется некий функционал
3. в тесте явно написан ожидаемый результат. и этот ожидаемый результат сравнивается с тем, что получилось в результате шага 2.

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

Как следствие: чтобы использовать майкрософтовские тесты, клиент должен проводить тесты на тех же начальных данных, что и майкрософт.
И это НЕ клиентские данные.

Цитата:

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

Вопрос - будет ли подобная схема работать в ситуации внедряющей фирмы ?

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

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

Пока очень понятно что хочет получить Майкрософт с этим тестированием. И совершенно непонятно зачем ЭТО нужно клиенту? Да, клиенту нужен результат. Но как этот результат будет получен - задача вендора. А вендор пытается переложить свои косты на клиента. Как и в остальных архитектурных решениях по Аксапте в последнее время.

Цитата:

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

Если внедренец покрывает тестами свою модель и функционал то исправление ошибки с новым тестом гарантирует что она не повторится и в общем то рост расходов на разработку в рамках 10-20% на создание простых автотестов на мой взгляд можно как то оправдать и перед клиентом.

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

В случае с DFO365 вопрос вовсе не в технологии.

[fed]

Цитата:

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

В
Пока очень понятно что хочет получить Майкрософт с этим тестированием. И совершенно непонятно зачем ЭТО нужно клиенту? Да, клиенту нужен результат. Но как этот результат будет получен - задача вендора. А вендор пытается переложить свои косты на клиента. Как и в остальных архитектурных решениях по Аксапте в последнее время.

Смотри также

[axm2017]

Цитата:

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

В тестах нет магии.
...Как следствие: чтобы использовать майкрософтовские тесты, клиент должен проводить тесты на тех же начальных данных, что и майкрософт.
И это НЕ клиентские данные.
..

Кто мешает добавить пару компаний с клиентскими к списку USMF USRT, DEMF и прочему?

Цитата:

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

И даже это не конечный вопрос.
Вопрос - будет ли подобная схема давать хоть какие-то преимущества для клиента?
..

Будет. Авто тесты это стандарт для работы сложных систем. Можно привести массу аргументов за.

Цитата:

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

И совершенно непонятно зачем ЭТО нужно клиенту? Да, клиенту нужен результат. Но как этот результат будет получен - задача вендора. ..

Клиенту важно что в системе после исправления меньше ошибок и он меньше заплатит на жизненном цикле. Авто тесты могут это дать за меньшее время и деньги.

Цитата:

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

В случае с DFO365 вопрос вовсе не в технологии.

И в этом тоже. Тестировщиков в MS сейчас нет. И продукт развивается иначе чем 12 ка. Сам подход к разработке спринты и прочее без автотестов имеют крайне слабое прикрытие. Собственно это причина уборки тестировщиков - они оказались тормозом при выпуске функционала.

[mazzy]

Цитата:

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

Кто мешает добавить пару компаний с клиентскими к списку USMF USRT, DEMF и прочему?

кто должен добавить пару компаний?
почему вы решили, что майкрософт тестирует на USMF USRT, DEMF?

даже теряюсь в догадках кто мешает... и КТО?

Цитата:

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

Будет. Авто тесты это стандарт для работы сложных систем. Можно привести массу аргументов за.

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

вы для Аксапты или DFO365 в текущих условиях расскажите.

[axm2017]

Цитата:

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

..
даже теряюсь в догадках кто мешает... и КТО?

Никто.

Цитата:

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

вы для Аксапты или DFO365 в текущих условиях расскажите.

Рассказать что?
Автотесты работают и худо бедно как видим 365 живет без тестеров.