Тестирование качества данных (Data Quality Testing)
Качество данных (data quality): Атрибут данных, показывающий их корректность согласно некоторым предопределенным критериям: бизнес-ожиданиях, требованиям по полноте данных или их непротиворечивости. (ISTQB)
Сегодняшний мир переживает очередную технологическую революцию, одним из аспектов которой является использование всевозможными компаниями накопленных данных для раскрутки собственного маховика продаж, прибылей и пиара. Представляется, что именно наличие хороших (качественных) данных, а также умелых мозгов, которые смогут из них делать деньги (правильно обработать, визуализировать, построить модели машинного обучения и т. п.), стали сегодня ключом к успеху для многих. Естественно, это потребовало технической организации этого процесса - подсоединиться к источнику данных, выкачать их, проверить, что они загружены в полном объёме и т. п. Количество таких процессов стало расти, и на сегодняшний день мы получили огромную потребность в Data Quality инженерах - тех, кто следил бы за потоком данных в системе (data pipelines), за качеством данных на входе и на выходе, делал бы выводы об их достаточности, целостности и прочих характеристиках. Обязанности Data Quality инженера не ограничиваются только рутинными ручными/автоматическими проверками на «nulls, count и sums» в таблицах БД, а требуют глубокого понимания бизнес нужд заказчика и, соответственно, способностей трансформировать имеющиеся данные в пригодную бизнес-информацию.
Data Quality - один из этапов Data Management и первый пункт плана управления данными (data management plan).
Аспекты качественных данных (dimensions):
Точность (Accuracy): насколько хорошо информация отражает реальность?
Полнота (Completeness). Соответствует ли вашим ожиданиям от того, что является всеобъемлющим?
Согласованность (Consistency): соответствует ли информация, хранящаяся в одном месте, релевантным данным, хранящимся в другом месте?
Своевременность (Timeliness): доступна ли ваша информация тогда, когда она вам нужна?
Срок действия, соответствие (Validity aka Conformity): имеет ли информация определенный формат, тип или размер? Соответствует ли она бизнес-правилам / передовой практике?
Целостность (Integrity): можно ли правильно объединить разные наборы данных, чтобы отразить общую картину? Хорошо ли определены и реализованы отношения?
Сам процесс тестирования не подразумевает строгое копирование этих признаков в тест-кейсы и их проверку. В Data Quality, как и в любом другом виде тестирования, необходимо прежде всего отталкиваться от требований по качеству данных, согласованных с участниками проекта, принимающими бизнес-решения.
Пример самого обобщенного перечня активностей Data Quality инженера:
Подготовить тестовые данные (валидные\невалидные\большие\маленькие) через автоматизированный инструмент.
Загрузить подготовленный набор данных в исходный источник и проверить его готовность к использованию.
Запустить ETL-процессы по обработке набора данных из исходного хранилища в окончательное или промежуточное с применением определённого набора настроек (в случае возможности задать конфигурируемые параметры для ETL-задачи).
Верифицировать обработанные ETL-процессом данные на предмет их качества и соответствие бизнес-требованиям.
При этом основной акцент проверок должен приходиться не только на то, что поток данных в системе в принципе отработал и дошёл до конца (что является частью функционального тестирования), а по большей части на проверку и валидацию данных на предмет соответствия ожидаемым требованиям, выявления аномалий и прочего.
Источники + доп. материал:
Last updated