Современный мир требует активной интеграции информационных технологий в повседневную жизнь. Жители города Москвы уже не помнят, как стоять в очереди в регистратуру больницы и забыли внешний вид своей медицинской карты. Чтобы попасть ко врачу, пациенту необходимо только записаться на примем через компьютер или личный девайс. Врач больше не записывает жалобы пациента на бумаге, все данные сохраняются в базе данных пациентов и уже никогда не потеряются. За всеми этими удобствами стоит Единая медицинская информационно-аналитическая система (ЕМИАС), одним из основных разработчиков которой является наша компания Solit-Clouds.
За каждым успешным решением стоит аналитика. Для таких целей, на базе ЕМИАС, созданы аналитические подсистемы, которые формируют данные в виде отчетов. В дальнейшем данные, предоставленные аналитической подсистемой (в дальнейшем АП), используются медицинскими организациями города Москвы для комплексного анализа и дальнейшего принятия решений. Большинство АП сформированы на базе продуктов платформы iDVP, куда входят: iDVP Analytics – универсальный инструмент для создания интерактивных отчётов и анализа данных, покрывает все требования, необходимые для отображения данных из различных источников и манипуляция ими. Речь идет о фильтрах, графиках, диаграммах, детализациях, выгрузке данных в Excel, PDF, CSV и многое другое.
Для формирования данных, которые будут отображены в iDVP Analytics, используется продукт iDVP Data - система управления данными. С помощью модуля Data возможно устанавливать соединения с внешним источником данных (это может быть база данных, файл или внешний сервис), выполнять преобразование данных с помощью языка SQL и далее формировать витрины, которые способны транслировать данные в iDVP Analytics. Так же функционал позволяет обновлять данные в удобное для пользователя время.
iDVP Admin - модуль для управления пользователями и организации доступа к функциям платформы. Позволяет устанавливать права, роли, уровни доступа и другие настройки.
Особенности погружения в тестирование BI систем (аналитических подсистем)
При выстраивании процесса тестирования BI системы, необходимо основываться на точности предоставления данных, удобстве использования, отсутствию функциональных дефектов. Это важный момент, т.к. предоставленные данные формируют определенный подход к различным ситуациям. Неправильно показанная цифра в отчете сформирует ошибочное представление и, что в последствие, приведет к неверным действия.
Одним из основных факторов успешности тестирования является качественная подготовка тестировщиков, которым предстоит проводить для каждого отчета не только функциональное тестирование и тестирование визуальных компонентов, но и проверять алгоритм расчета для каждой представленной цифры в отчете. Поэтому в нашей компании процесс адаптации и обучения тестировщиков основан не только на базовых компонентах hard skills и soft skills, но и на особенностях тестирования BI систем, о чем и постараемся рассказать в статье.
Приступая к процессу погружения новичка мы прежде всего стараемся рассказать и объяснить основную особенность в тестировании аналитических подсистем. И особенность эта заключается в тесной работе с данными. Ключевая цель тестирования – обеспечить корректность предоставляемых данных.
Для того чтобы достичь этой цели тестировщик должен провести несколько этапов тестирования данных. Новые сотрудники должны знать, понимать все этапы тестирования и по окончанию испытательного срока максимально самостоятельно тестировать алгоритмы формирования данных. Так же крайне важно, чтобы тестировщики могли критически осмысливать информацию, отображаемую в отчете, для этого им необходимо понимать весь поток данных от источника до отчетов. В плане адаптации для тестировщика обозначаем и закрепляем основные этапы тестирования данных, которые необходимо выполнять каждый раз при тестировании аналитических подсистем. Рассказываем про следующие этапы:
Проверка корректности источника данных. Как показывает практика, аналитические подсистемы при формировании данных используют не один источник, как правило данные предоставляются на основе нескольких источников. Так же могут существовать не актуальные, устаревшие источники, и это тоже необходимо учитывать при проверке источника данных. Упустив данный этап при проверке, тестировщик сталкивается с ситуацией, когда при верном алгоритме отбора, данные сформированы не верно.
Проверка наложенных условий. Хаотично наложенные условия так же формируют некорректные данные, следовательно, важно проверять не только сами условия, но и приоритетность условий.
Проверка корректности соединения таблиц. Корректность соединений зависит не только от корректно выбранных полей (существуют таблицы, которые можно связать разными способами и, в зависимости от этого, бизнес-смысл будет меняться), но и от правильного выбранного типа соединения.
Проверка корректности типа данных. Залог того, что код будет работать без сбоев и при обновлении данных не будет сюрпризов.
Проверка отсутствия лишних полей в запросе. Не всегда эта работа для настоящего времени, очень часто это работа на будущее. Добавленное поле в запрос, которое в дальнейшем не будет использоваться, увеличивает объем информации, а соответственно и нагрузку на систему. Нужно всегда учитывать тот факт, что количество данных, вероятно, будет расти, а значит и нагрузка на систему будет увеличиваться. Лишняя информация в лучшем случае увеличивает время обновления, а в худшем, не сможет выполниться обновление.
Отсутствие NULL при соединении таблиц. Присутствие NULL в запросе при соединении таблиц несет в себе те же риски, что были описаны в предыдущем пункте. Необходимо установить предельный допустимый уровень NULL при соединении таблиц, в таком случае запрос будет отрабатывать быстрее и можно не переживать о дальнейшем обновлении.
Проверка корректности обновления всех сущностей в коде. Заключительным этапом следует провести полное обновление данных, не пропустив при этом ни одной сущности в коде. Запустив обновление следует проводить мониторинг процесса, чтобы, в случае неудовлетворительного результата, быстро сигнализировать об ошибке.
Для того чтобы тестировщик смог на практике попробовать пройти все этапы проверки данных мы знакомим его с системой управления данными, фундаментом формирования аналитических подсистем, в нашем случае это iDVP Data. Нам важно, чтобы тестировщик свободно владел функционалом системы, понимал, как строится и формируется поток данных, знал виды и особенности создания сущностей, с помощью которых формируются данные. И в итоги умел самостоятельно строить SQL-запрос с учетом технического задания, для проверки данных. А для того, чтобы писать SQL-запросы, как минимум, необходимо разбираться в моделях баз данных. На этом этапе подготовки новичку наставник рассказывает про тонкости анализа модели данных, погружает в глоссарий с учетом специфики базы данных.
На основе нашего опыта, заметили, что при подготовке к тестированию аналитических подсистем, чаще всего трудности возникают именно с SQL. Закономерный вопрос: как достичь необходимого уровня знания SQL? Наш ответ: практика. Задачи с плавным повышением уровня сложности, которые основаны на спецификациях для отчетов в рамках аналитической подсистемы быстро и безболезненно выводят тестировщика на должный уровень владения SQL. Но, надо отметить, что недостаточно просто взять задачи из тренажера, хотя это и способствует отработке навыка владения SQL, необходимо самостоятельно подготавливать упражнения с учетом текущего уровня, постепенно усложняя их и разбирая сложные моменты с тестировщиком, пока не будет достигнуто полного понимания. При выполнении упражнений, созданных наставником на основе спецификаций, тестировщик не только отрабатывает навыки написания и анализа SQL запросов, он еще и учится понимать постановку, что так же способствует быстрому поиску дефектов на уровне документации.
После тестирования данных необходимо проверить их отображение непосредственно в самом отчете. Здесь тестировщикам объясняем, насколько важно проверить всё то, что было протестировано на предыдущих этапах, теперь обрабатывается и правильно отображается в отчетах для конечного пользователя. Для закрепления этой группы проверок в плане адаптации нового сотрудника выделяем следующие этапы:
Функциональное тестирование. При использовании определенной функциональности данные могут перестроиться, но они по-прежнему должны быть корректными, и это обязательно нужно проверить тестировщику. Для удобства разберем на примере, в качестве тестируемого объекта возьмем простой элемент тестирования - фильтр. При выборе определенного значения данные должны перестроиться в соответствии с этим значением. Следовательно, какими бы банальными не были функциональные возможности BI систем, пренебрегать их тестированием нельзя.
Тестирование пользовательского интерфейса. Всякий раз, когда пользователь просматривает отчет, чтобы получить некоторую информацию, пользовательский интерфейс отчета должен быть понятным и это тоже неотъемлемая часть проверок, которые необходимо выполнять команде тестирования. Тестировщик должен проверить отображение элементарных, но в то же время важных объектов отчета (например, название отчета, расположение осей на графиках и диаграммах, отображение данных в корректном месте, наличие опции печати и т.д.)
Тестирование производительности. Конечно, если возможности на проекте позволяют, широкое тестирование производительности никогда не окажется лишним. Но и даже при самых скромных возможностях, тестировщику необходимо проводить проверку времени загрузки данных из источника. Важно отметить, что с ростом количества данных, и время получения их будет увеличиваться, следовательно, обязательно настанет тот день, когда отчет не откроется, например, из-за того, что время ожидания превысило тайм-аут. Поэтому тестировщику важно в отчете не забывать проверять такие моменты как, время загрузки страницы, время загрузки данных, время навигации при детализации отчета и т.д.
Регрессионное тестирование. Проверка отчета не ограничивается выполнением кейсов после его разработки или внесения изменений. Необходимо выполнять регрессионное тестирование, с определенной периодичностью для того, чтобы выявить или спрогнозировать ошибки, которые могут возникнуть из-за роста количества данных.
Тестирование уровней доступа и ролей. При проверке уровней доступа и ролей, тестировщику необходимо уделить внимание отображению различной функциональности или скрытия данных в соответствии с определенной ролью или уровнем доступа.
Для реализации этой группы проверок тестировщику необходимо уметь работать с системой визуализации данных – iDVP Analytics. На данном этапе погружения, тестировщику рассказываем, какие есть основные возможности Analytics и как их необходимо использовать при тестировании отчетов. Так же на том же этапе тестировщику показываем функционал iDVP Admin. Для того чтобы у него сложилось понимание об уровнях доступа и ролях, используемых в аналитической подсистеме.
Последним и очень важным этапом в погружении тестировщика является демонстрация полученных знаний и навыков. В завершении мы ожидаем, что тестировщик свободно владеет знаниями об особенностях архитектуры аналитической подсистемы, понимает, как устроена модель базы данных и демонстрирует уверенные навыки владения SQL. Если тестировщик демонстрирует должный уровень знаний и умений, процесс погружения завершается, и он приступает к самостоятельному выполнению производственных задач.
Заключение
Для будущего тестировщика очень важно иметь максимально полное представление об особенностях тестируемой BI системы. Постараться во время адаптационного периода углубиться в тонкости работы с отчетами. Да, вероятно, невозможно за время адаптации понять все нюансы работы, но то, что мы рассказываем, несомненно остается в памяти тестировщика и обязательно приходит время, когда эти знания используются в полной мере…
