Pull to refresh

Comments 8

Как-то всё это очень странно.


По моему мнению, данные являются следствием работающего бизнес-процесса. Бизнес процесс — это люди и технические средства, объединенные в граф последовательностей.


Если люди могут вставлять в фамилию цифры — это говорит о том, что бизнес процесс непроработан до конца, это означает, что проблема совсем не в данных, а в качестве процесса выявления требований. То есть, "бага" на самом деле возникла при общении с заказчиком, когда было разрешено вставлять любые символы в фамилию. Когда требования уточняются или меняются и это затрагивает данные пользователей, нужно запустить процесс миграции данных, то есть, в случае с фамилией, заставить пользователей до определенной даты поменять свои данные на корректные. Пример можно найти в госуслугах — ты вводишь свои паспортные данные и далее неизвестно как, может быть даже руками людей, эти данные валидируются, они никак не попадают сразу в категорию валидных данных.


Как мне кажется, статья больше вводит в заблуждение, чем даёт какую-то пользу.


Что касается реального тестирования данных — то этот термин относится к тест дизайну, а точнее к одному из видов тест дизайна — анализу значений.


Например, что будет, если ввести в поле возраста 150 лет, или что будет, если ввести фамилию на двух разных алфавитах. Объект тестирования при этом не данные, а интерфейс пользователя. И это самый обычный тест.


Вот как-то совсем не зашло.

Речь о данных в более масштабном контексте, за рамками какого-то атомарного процесса типа заполнения формы. Данные собираются в базы, и уже на их основании потом строятся какие-то процессы. Или из них выводятся какая-то вторичная информация. В этом смысле плохие данные могут привести к заведомо ошибочным решениям при проектировании приложения или отличиям результатов его работы от предполагаемых. А если говорить о машинном обучении — то там данные решают вообще все, и ошибку предсказаний модели вырастающей из некачественных данных при обучении или в продакшне часто вообще не видно, пока она не распространится на последующие процессы и не пройдет время, когда потери бизнеса уже очень неприятных размеров.

Полагаю, тогда в статье нехватает контекста. Чтобы статья воспринималась в должном смысле. Надо объяснить так, чтобы стало понятно, почему бизнес процесс допускает попадание в бд невалидных данных.

Спасибо за ваш комментарий. Я добавил update в статью
Спасибо за апдейт. Теперь понятно, что это не связано с тестированием программного обеспечения. А относится к анализу / проверке входящей информации, которая еще не дошла до непосредственного использования в ПО. Я бы даже переименовал статью в «Подходы к анализу больших данных» и поменял бы раздел, так как сейчас раздел «тестирование IT систем».
Only those users with full accounts are able to leave comments. Log in, please.