Тестирование данных: требования и уровни



    Меня зовут Алексей Чумагин, я тестировщик в Provectus. В этой статье я расскажу, как формируются требования к качеству данных и какие могут быть уровни тестирования данных.


    Upd:
    В статье речь идет о больших (или не очень) данных, на основе анализа и агрегации, которых строятся разные процессы, выводятся закономерности для использования в дальнейшем анализе или для принятия решений. Данные могут быть собраны под конкретный проект с нуля, либо могут использоваться базы, собранные ранее для других проектов либо в коммерческих целях. Источники этих данных разнообразны и включают не только ввод операторами, но и автоматизированные и/или автоматические измерения, сохраняемые в базы системно или бессистемно (кучей, “потом придумаем что с этим делать”).

    end-of-upd.


    Почему тестирование данных важно


    Данные играют все большую роль в принятии решений как в повседневной жизни, так и в бизнесе. Современные технологии и алгоритмы позволяют обрабатывать и хранить огромные массивы данных, преобразуя их в полезную информацию.

    Что это за данные? Например, история вашего браузера, транзакции по вашей карте, точки перемещения какого-то девайса. Они обезличены, но эти данные все равно принадлежат определенному устройству. Если их собрать и обработать, то можно получить довольно интересную информацию о хозяине этого девайса. Например, куда он любит ходить, какой у него пол и возраст. Так постепенно мы «очеловечиваем» устройство и наделяем его какими-то характеристиками.

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

    Всё это базируется на тех данных, которыми владеют разные компании и люди. Для эффективного использования этих данных нужно, чтобы они были достоверными и мы знали, что именно этому аккаунту принадлежат эти транзакции.

    Так как данных становится очень много, их хранение требует значительных ресурсов. Очистка данных — отдельная задача, которую надо решать. Мы хотим хранить только те данные, которые нам действительно нужны. И не хотим, чтобы у нас в базе данных хранились дубликаты или записи, которые не соответствуют нашим критериям. Например, записи с пустыми полями. Поэтому возникают требования к качеству данных и встает вопрос об их тестировании.

    Что такое качество


    Мне нравится такое определение: качество продукта — это мера удовлетворенности пользователя. Понятно, что всё зависит от контекста использования продукта. Если вы пользуетесь каким-нибудь известным продуктом, например, Facebook или Skype, то у вас одни требования к качеству. Вы будете мириться с какими-то ошибками, но всё равно продолжите пользоваться этим продуктом. А если вы являетесь заказчиком какой-то программы и заплатили за нее деньги, то требования к качеству будут выше. Вы будете придираться, смотреть какие-то мелочи. У разных людей разные представления о качестве, и у разных программ тоже свои требования к качеству.

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

    Определение этих требований — непростая задача. Обычно требования к ПО формирует бизнес, и если мы спросим у бизнеса, какими должны быть данные, то можем получить ответ, что данные должны быть хорошими и чистыми. Задача тестировщика — выяснить или уточнить, что это за данные и по каким критериям мы определяем их качество и чистоту. Эти критерии нужно формализовать и зафиксировать, сделать измеряемыми.

    Как формируются требования к качеству данных


    Тестировщик начинает выяснять, что ему непонятно и что он хотел бы узнать об объекте тестирования. Тестировщик составляет список вопросов и начинает брать «интервью» у заказчика. Он, по идее, должен знать, какими должны быть данные. Например, я спрашиваю: допустимы ли пустые ячейки или повторяющиеся строки.

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

    Дальше мы начинаем спрашивать о формате данных в определенной ячейке. Например, в номере телефона должно быть 12 цифр, в номере банковской карты — 16. У нас может быть критерий, что не всякая последовательность этих знаков является номером банковской карты. Или мы понимаем, что в фамилии могут быть только буквы. У нас может возникнуть много вопросов по поводу формата данных. Таким образом, мы выясняем всё, что нам нужно знать о предмете тестирования.

    Что такое качественные данные


    Качественные данные должны обладать несколькими характеристиками.

    • Полнота — в записях нет пропусков, все ячейки должны быть заполненными. Данные должны нести как можно больше информации.
    • Уникальность — среди данных не должно быть одинаковых записей.
    • Достоверность — ради этого всё и затевается. Никто не хочет работать с данными, которым нельзя верить. Ячейки таблиц с качественными данными содержат то, что и должны содержать: IP-адрес, номер телефона и т.д.
    • Точность. Если говорить о цифровых данных, то должно быть точное количество знаков. Например, 12 знаков после запятой. Данные должны быть близки к какому-то среднему значению.
    • Согласованность — данные должны сохранять значения, независимо от способа их измерения.
    • Своевременность — данные должны быть актуальны, особенно если они периодически обновляются. Например, каждый месяц количество данных должно увеличиваться. Данные не должны устаревать. Если мы говорим о банковских транзакциях, то нам интересно, чтобы они были, например, за последние полгода.

    Уровни тестирования данных


    Мы можем сгруппировать данные по так называемым слоям — здесь работает хорошая аналогия с пирамидой тестирования. Это распределение по количеству тестов на разных уровнях приложения.

    • Unit-слой — это когда тестируется один модуль программы, чаще всего это одна функция или метод. Таких тестов должно быть больше всего. Unit-тест для данных — это когда мы определяем требования для каждой ячейки. Нет смысла тестировать дальше, если у нас есть ошибки на уровне ячеек. Если, например, в фамилии содержатся цифры, то какой смысл проверять что-то дальше? Возможно, там должны быть буквы, похожие на эти цифры. И тогда нам нужно всё исправлять и проверять следующий уровень, чтобы у нас всё было в единственном числе и не было дубликатов, если так сказано в требованиях.
    • Integration-слой — это когда несколько кусков программы тестируются вместе. Слой API для данных — это когда мы говорим о всей таблице. Допустим, у нас могут быть дубликаты, но не больше ста штук. Если у нас город-миллионник, то на одной улице не может жить миллион человек. Поэтому если мы сделаем выборку по улице, то количество адресов должно быть десять тысяч или тысяча — это надо определить. А если у нас миллион, то с данными что-то не так.
    • System-слой — это когда вся программа тестируется полностью. В случае с данными этот слой означает, что тестируется вся система. Здесь включается статистика. Например, мы говорим, что у нас не может быть больше 30% мужчин, рожденных после 1985 года. Или мы говорим, что 80% данных должны быть одного типа.

    В заключение скажу, что тестирование данных — это сфера, которая предоставляет много возможностей для творчества и развития. Серебряной пули здесь нет: к тестированию данных можно применять разные подходы. Истина, как всегда, где-то посередине.
    • –1
    • 2,7k
    • 8
    Поделиться публикацией

    Комментарии 8

      0
      Полезная статья! Спасибо!
      0

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


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


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


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


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


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


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

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

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

            0
            Спасибо за ваш комментарий. Я добавил update в статью
              0
              Спасибо за апдейт. Теперь понятно, что это не связано с тестированием программного обеспечения. А относится к анализу / проверке входящей информации, которая еще не дошла до непосредственного использования в ПО. Я бы даже переименовал статью в «Подходы к анализу больших данных» и поменял бы раздел, так как сейчас раздел «тестирование IT систем».
            0
            Спасибо, все так и есть.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое