Цитата:
Сообщение от
axm2017
Как понимаю MS, закрыл часть тестов по причине...
В тестах нет магии.
Тест предполагает, что:
1. есть некое зафиксированное начальное состояние.
2. в этом начальном состоянии выполняется некий функционал
3. в тесте явно написан ожидаемый результат. и этот ожидаемый результат сравнивается с тем, что получилось в результате шага 2.
ключевой момент - для успешного теста просто жизненно необходимо, чтобы начальное состояние было. и чтобы оно было одинаковым.
Как следствие: чтобы использовать майкрософтовские тесты, клиент должен проводить тесты на тех же начальных данных, что и майкрософт.
И это НЕ клиентские данные.
Цитата:
Сообщение от
fed
Вопрос - будет ли подобная схема работать в ситуации внедряющей фирмы ?
И даже это не конечный вопрос.
Вопрос - будет ли подобная схема давать хоть какие-то преимущества для клиента? На клиенте есть человек (или группа людей), которые должны принять решение - ок, мы оплачиваем эти работы, потому что эти работы дадут нам то-то и то-то...
И тут даже не важно кому пойдет оплата - внедряющим фирмам, разработчикам собственной команды или напрямую в Майкрософт.
Пока очень понятно что хочет получить Майкрософт с этим тестированием. И совершенно непонятно зачем ЭТО нужно клиенту? Да, клиенту нужен результат. Но как этот результат будет получен - задача вендора. А вендор пытается переложить свои косты на клиента. Как и в остальных архитектурных решениях по Аксапте в последнее время.
Цитата:
Сообщение от
axm2017
Если внедренец покрывает тестами свою модель и функционал то исправление ошибки с новым тестом гарантирует что она не повторится и в общем то рост расходов на разработку в рамках 10-20% на создание простых автотестов на мой взгляд можно как то оправдать и перед клиентом.
вообще говоря, сама технология тестирования создавалась, чтобы снизить расходы на разработку
В случае с DFO365 вопрос вовсе не в технологии.