Меня зовут Алексей Чумагин, я тестировщик в Provectus. В этой статье я расскажу, как формируются требования к качеству данных и какие могут быть уровни тестирования данных.
Upd:
В статье речь идет о больших (или не очень) данных, на основе анализа и агрегации, которых строятся разные процессы, выводятся закономерности для использования в дальнейшем анализе или для принятия решений. Данные могут быть собраны под конкретный проект с нуля, либо могут использоваться базы, собранные ранее для других проектов либо в коммерческих целях. Источники этих данных разнообразны и включают не только ввод операторами, но и автоматизированные и/или автоматические измерения, сохраняемые в базы системно или бессистемно (кучей, “потом придумаем что с этим делать”).
end-of-upd.
Почему тестирование данных важно
Данные играют все большую роль в принятии решений как в повседневной жизни, так и в бизнесе. Современные технологии и алгоритмы позволяют обрабатывать и хранить огромные массивы данных, преобразуя их в полезную информацию.
Что это за данные? Например, история вашего браузера, транзакции по вашей карте, точки перемещения какого-то девайса. Они обезличены, но эти данные все равно принадлежат определенному устройству. Если их собрать и обработать, то можно получить довольно интересную информацию о хозяине этого девайса. Например, куда он любит ходить, какой у него пол и возраст. Так постепенно мы «очеловечиваем» устройство и наделяем его какими-то характеристиками.
Потом эту информацию можно использовать для таргетированной рекламы. Если вы женщина, то с большой долей вероятности можно сказать, что вас не интересует реклама бритвенных станков для мужчин. Вам нужно показывать рекламу, связанную с вашими интересами. Качество таргетирования рекламы может быть повышено благодаря тому, что известно о девайсах, на которых её показывают. Вам показывают рекламу, которую вы хотите видеть. Значит, вы будете на нее кликать. Люди, которые показывают вам эту рекламу, будут получать за это деньги, а заказчик рекламы получит профит от того, что вы узнаете о его продукте.
Всё это базируется на тех данных, которыми владеют разные компании и люди. Для эффективного использования этих данных нужно, чтобы они были достоверными и мы знали, что именно этому аккаунту принадлежат эти транзакции.
Так как данных становится очень много, их хранение требует значительных ресурсов. Очистка данных — отдельная задача, которую надо решать. Мы хотим хранить только те данные, которые нам действительно нужны. И не хотим, чтобы у нас в базе данных хранились дубликаты или записи, которые не соответствуют нашим критериям. Например, записи с пустыми полями. Поэтому возникают требования к качеству данных и встает вопрос об их тестировании.
Что такое качество
Мне нравится такое определение: качество продукта — это мера удовлетворенности пользователя. Понятно, что всё зависит от контекста использования продукта. Если вы пользуетесь каким-нибудь известным продуктом, например, Facebook или Skype, то у вас одни требования к качеству. Вы будете мириться с какими-то ошибками, но всё равно продолжите пользоваться этим продуктом. А если вы являетесь заказчиком какой-то программы и заплатили за нее деньги, то требования к качеству будут выше. Вы будете придираться, смотреть какие-то мелочи. У разных людей разные представления о качестве, и у разных программ тоже свои требования к качеству.
Поэтому перед разработкой и тестированием люди обычно определяют, что будут считать качественным продуктом. Все это можно описать формально. Например, мы будем считать наш продукт качественным, если в нем не будет критических ошибок. Или если он проработает две недели без сбоев.
Определение этих требований — непростая задача. Обычно требования к ПО формирует бизнес, и если мы спросим у бизнеса, какими должны быть данные, то можем получить ответ, что данные должны быть хорошими и чистыми. Задача тестировщика — выяснить или уточнить, что это за данные и по каким критериям мы определяем их качество и чистоту. Эти критерии нужно формализовать и зафиксировать, сделать измеряемыми.
Как формируются требования к качеству данных
Тестировщик начинает выяснять, что ему непонятно и что он хотел бы узнать об объекте тестирования. Тестировщик составляет список вопросов и начинает брать «интервью» у заказчика. Он, по идее, должен знать, какими должны быть данные. Например, я спрашиваю: допустимы ли пустые ячейки или повторяющиеся строки.
Пример требований — если у нас есть список людей, то имя, фамилия и отчество могут повторяться. Но вся совокупность строк повторяться не может. По одной ячейке могут быть допустимы повторения, а по целой строке или по совокупности нескольких ячеек — уже нет. Полного совпадения не должно быть.
Дальше мы начинаем спрашивать о формате данных в определенной ячейке. Например, в номере телефона должно быть 12 цифр, в номере банковской карты — 16. У нас может быть критерий, что не всякая последовательность этих знаков является номером банковской карты. Или мы понимаем, что в фамилии могут быть только буквы. У нас может возникнуть много вопросов по поводу формата данных. Таким образом, мы выясняем всё, что нам нужно знать о предмете тестирования.
Что такое качественные данные
Качественные данные должны обладать несколькими характеристиками.
- Полнота — в записях нет пропусков, все ячейки должны быть заполненными. Данные должны нести как можно больше информации.
- Уникальность — среди данных не должно быть одинаковых записей.
- Достоверность — ради этого всё и затевается. Никто не хочет работать с данными, которым нельзя верить. Ячейки таблиц с качественными данными содержат то, что и должны содержать: IP-адрес, номер телефона и т.д.
- Точность. Если говорить о цифровых данных, то должно быть точное количество знаков. Например, 12 знаков после запятой. Данные должны быть близки к какому-то среднему значению.
- Согласованность — данные должны сохранять значения, независимо от способа их измерения.
- Своевременность — данные должны быть актуальны, особенно если они периодически обновляются. Например, каждый месяц количество данных должно увеличиваться. Данные не должны устаревать. Если мы говорим о банковских транзакциях, то нам интересно, чтобы они были, например, за последние полгода.
Уровни тестирования данных
Мы можем сгруппировать данные по так называемым слоям — здесь работает хорошая аналогия с пирамидой тестирования. Это распределение по количеству тестов на разных уровнях приложения.
- Unit-слой — это когда тестируется один модуль программы, чаще всего это одна функция или метод. Таких тестов должно быть больше всего. Unit-тест для данных — это когда мы определяем требования для каждой ячейки. Нет смысла тестировать дальше, если у нас есть ошибки на уровне ячеек. Если, например, в фамилии содержатся цифры, то какой смысл проверять что-то дальше? Возможно, там должны быть буквы, похожие на эти цифры. И тогда нам нужно всё исправлять и проверять следующий уровень, чтобы у нас всё было в единственном числе и не было дубликатов, если так сказано в требованиях.
- Integration-слой — это когда несколько кусков программы тестируются вместе. Слой API для данных — это когда мы говорим о всей таблице. Допустим, у нас могут быть дубликаты, но не больше ста штук. Если у нас город-миллионник, то на одной улице не может жить миллион человек. Поэтому если мы сделаем выборку по улице, то количество адресов должно быть десять тысяч или тысяча — это надо определить. А если у нас миллион, то с данными что-то не так.
- System-слой — это когда вся программа тестируется полностью. В случае с данными этот слой означает, что тестируется вся система. Здесь включается статистика. Например, мы говорим, что у нас не может быть больше 30% мужчин, рожденных после 1985 года. Или мы говорим, что 80% данных должны быть одного типа.
В заключение скажу, что тестирование данных — это сфера, которая предоставляет много возможностей для творчества и развития. Серебряной пули здесь нет: к тестированию данных можно применять разные подходы. Истина, как всегда, где-то посередине.