ну если формат постоянно меняется -- о качественном сервисе и речи не может быть. Постояний 500 Internal Server Error

То есть нет backward compatibility

Она тупо меняется

Ребята, вы не слышите меня - есть формат данных, и есть сами данные, а когда данные еще исторические, то это еще хуже

тем более когда собранные с бумаги данные заливаются в БД вручную))

Про чистоту данных я имею в виду следующее. Что например в документации сервиса сказано, если значение поля А равно 1, то значение поля B равно 2. А в действительности поле B иногда имеет значение 3. И связанно это может быть с тем, что допустим до 01.01.2019, в системе источнике присваивали значение полю B равное 3, но с 01.01.2019 этому полю присваиюват значание 2. И нигде в xsd это отражено не будет. Будет огромным плюсом, если где-то в документации или какой-нибудь разработчик вспомнит про это и это поможет вашей системе, но в виду того что многие системы в разные годы поддерживались и сопровождались разными фирмами - то забудьте про эту информацию

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

Теперь понял

С документацией  во многих местах проблема

В компаний где я работал в 2013-14 году -- тоже была такая хрень. Хотя компания зарубежная. Постоянно меняется спеки -- постоянно что то не работает. Хотя была целая команда QA. И не понимал почему?  Сейчас думаю -- вот такие выше проблемы могли свести к минимуму выстроив правильный процесс внутри команды или лучше в компаний. То есть юнит тесты, e2e тесты и мониторинги -- нафиг нужны были эти QA. Я к тому что правильно автоматизированные  процессы  и использование разных методологий (у нас был тогда кроме daily standup ничего не было и то кажется потому что  по Agile-у) -- могут улучшить и выявить серьезные косяки.

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

не, QA нужны -  у них голова думает не так как у разработчиков, тебе могут придумать такой кейс о котором никто не задумывался, и он может оказаться сценарием, которым будет пользоваться не менее допустим 20% пользователей

rational rose помог бы? хотя старая уже технология

QA без спеки твоего сервиса ничего не создаст. Поэтому его работу мог бы выполнить и ты. И да если голова не так думает -- можно было бы использовать TDD для создания тестов.

ну не знаю,  QA в силу опыта и без спеки может набахать юзкейсов о которых разраб даже не подумает

Если ты про безопасность и перехитрить систему -- то это задача пентестеров. И для таких целей лучше нанять outsource. Они точно то и не будут знать

нене, я имею в виду именно юзабилити

где то не прикрутили валидацию на уровне интерфейса где то например

на фронте

самый банальный пример