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

[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 живет без тестеров.