Видео с конференции SECR-2018 — Аналитика на 100млн. данных. Краткий ликбез для системных интеграторов, Татьяна Бунто.
Статья на хабре на ту же тему — Миграция данных в кровавом энтерпрайзе: что анализировать, чтобы не завалить проект
Таня рассказала пример из реальной жизни, как тестировать персональные данные — ФИО, ИНН, адреса, паспорта, телефоны...Если ваша система получает такие данные от какой-то другой, не мешает проанализировать, что вы вообще забираете. Таки да, данные тоже надо тестировать!
Обычно этим занимаются аналитики, безусловно. Причем аналитики из системного интегратора. Потому что именно интеграторы обычно делают ETL-процесс (extract, transform, load), который берет данные из одной системы и кладет их в другую.
Мы делаем "другую" систему-приемник. Сначала забираем «сырые» данные из исходных систем, а потом делаем из них конфетку. Данные нам обычно передает сам заказчик. У него есть разработчики, с которыми мы согласовываем формат первичной выгрузки. И все равно стоит протестировать, что конкретно нам навыгружали. Все мы люди, все мы человеки, может, что-то забыли или выгрузили телефон вместо ИНН...
А если есть еще какое-то третье лицо, если ETL делают отдельные люди, то тем более надо проводить тестирование! По крайней мере, если ваша система работает с качеством данных. Ведь если в нашей системе каких-то данных нет, а в источнике есть — то придут именно к нам: «Вы не забрали данные», или «Вы не смогли их обработать». Так что начинаем тестирование.
Конечно, это работа аналитика. Недаром видео называется «аналитика данных». Тестировщик всегда может сказать, что это вне его компетенции. Однако, если отдельного аналитика нет, это все равно придется делать вам
Или если в компании у вас люди-швейцарские ножи, которые умеют делать и то, и другое. В общем, если вам интересно узнать, как тестировать данные (не систему, не gui, а сами данные) — велкам на vimeo, смотреть Танин доклад. Кстати, шикарная подача материала! Я прям заслушалась, интереснее сериала было!
Пара заметок от меня:
Что анализируем:
Статья на хабре на ту же тему — Миграция данных в кровавом энтерпрайзе: что анализировать, чтобы не завалить проект
Таня рассказала пример из реальной жизни, как тестировать персональные данные — ФИО, ИНН, адреса, паспорта, телефоны...Если ваша система получает такие данные от какой-то другой, не мешает проанализировать, что вы вообще забираете. Таки да, данные тоже надо тестировать!
Обычно этим занимаются аналитики, безусловно. Причем аналитики из системного интегратора. Потому что именно интеграторы обычно делают ETL-процесс (extract, transform, load), который берет данные из одной системы и кладет их в другую.
Мы делаем "другую" систему-приемник. Сначала забираем «сырые» данные из исходных систем, а потом делаем из них конфетку. Данные нам обычно передает сам заказчик. У него есть разработчики, с которыми мы согласовываем формат первичной выгрузки. И все равно стоит протестировать, что конкретно нам навыгружали. Все мы люди, все мы человеки, может, что-то забыли или выгрузили телефон вместо ИНН...
А если есть еще какое-то третье лицо, если ETL делают отдельные люди, то тем более надо проводить тестирование! По крайней мере, если ваша система работает с качеством данных. Ведь если в нашей системе каких-то данных нет, а в источнике есть — то придут именно к нам: «Вы не забрали данные», или «Вы не смогли их обработать». Так что начинаем тестирование.
Конечно, это работа аналитика. Недаром видео называется «аналитика данных». Тестировщик всегда может сказать, что это вне его компетенции. Однако, если отдельного аналитика нет, это все равно придется делать вам
Или если в компании у вас люди-швейцарские ножи, которые умеют делать и то, и другое. В общем, если вам интересно узнать, как тестировать данные (не систему, не gui, а сами данные) — велкам на vimeo, смотреть Танин доклад. Кстати, шикарная подача материала! Я прям заслушалась, интереснее сериала было!
Пара заметок от меня:
Чек-лист тестирования данных
Что анализируем:
- Заполненность полей или null-значения
- Длину полей в БД
- Распределение значений по длине
- Распространенность или популярность
- Наличие справочников и классификаторов
- Консистентность
- Адекватность данных
Примеры «багов» в данных
Выгрузили 100 млн данных, а все ДР — пустые. Как так? Оказывается, функция декода не отработала в ETL, поэтому к нам данные не попали.
Или "язык" заполнен только у 4 тысяч. Почему? А потому что в базе классификатор, про который никто не знал. Надо функцию забора данных подправить...
Когда самые популярные данные — явно тестовые, это ооооочень подозрительно. Почему так много имен «Тест»? Может, тестировщики путают контура для нагрузок? Или это нормально? Но тогда вам не надо эти данные забирать, зачем вам тестовые записи источника?
Или если вы видите ДР "01.01.1900" — это вполне может быть косяк исходной системы или ETL, неправильно выгружают и ой.
И таких примеров в докладе еще много)) Так что настоятельно рекомендую к просмотру, пусть даже для саморазвития. А там... Мало ли, когда это пригодится! 
Я вообще за то, чтобы тестировщик хотя бы иногда проводил такую аналитику. Хотя бы ради того, чтобы трезво оценивать свои тесты и их нужность.
Я вообще за то, чтобы тестировщик хотя бы иногда проводил такую аналитику. Хотя бы ради того, чтобы трезво оценивать свои тесты и их нужность.
Комментариев нет:
Отправить комментарий