Rambler's Top100
Статьи
Борис ЧУПРЯЕВ  10 февраля 2020

Ориентация на пациента: особенности тестирования медицинского ПО

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

Создавая программные продукты для здравоохранения, мы, как и многие, ориентируемся на ведущие практики. Работаем по гибким итеративным методологиям, когда за этапом разработки следует тестирование, а по его результатам может быть запущен новый цикл разработки – и все это сводится в единый непрерывный поток.

Моральный аспект, экспертиза и персональные данные

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

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

В наших решениях мы физически разделяем хранилища персональных и клинических данных. Таким образом, управление доступом и обработка персональных данных пациента и его клинических данных – это разные процессы. И при тестировании мы проверяем, в частности, возможность запросить данные из базы в обход авторизации. 

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

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

Наконец, четвертая особенность нашей работы – ориентация на пользователей медицинских сервисов. На мой взгляд, разработчик любой информационной системы должен учитывать в первую очередь именно их интересы. Тестировщику нужно вжиться в роль конечного пользователя и выдать необычные сценарии, которые потом трансформируются в тестовые. Например, мы можем представить себе очень занятого профессора или неопытного пользователя, который не разбирается в компьютерах и для которого любые новые решения только усложняют жизнь, и провести UX-тестирование. Возможно, результатом станет изменение интерфейса, логики, уменьшение количества кликов до целевой страницы. Другой пример: врач, который долгое время заполняет карточку пациента. Конечно, он может не знать о такой опасности, как «протухание» интернет-сессии, грозящее потерей всех введенных данных, – и мы должны добавить в систему функцию автосохранения. Таким образом, иногда мы вынуждены отходить от принципа атомарных тестов и исследовать длинные пользовательские сценарии, большие пласты бизнес-логики. 

Ручной труд или зачет автоматом?

В публикациях наших коллег часто можно встретить утверждение, что полностью автоматизировать процесс тестирования программного обеспечения невозможно. Во многом это утверждение справедливо: например, чтобы написать сценарий для автоматизации, сначала его необходимо «прогнать» вручную. То же самое касается тестирования контента, когда мы привлекаем экспертов: база для теста формируется вручную. 

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

Подводя итог, отмечу, что проблемы автоматизации тестирования сегодня кроются не в технологиях, а в методологии: насколько она будет дорогой и трудозатратной. Ее необходимость зависит от отрасли применения, сроков, имеющихся ресурсов. В последнее время автоматизированное тестирование стало более выгодным, поскольку им управлять легче, чем командой тестировщиков. Кроме того, на определенном этапе мы можем встроить его в процесс непрерывного внедрения (continuous integration) и тем самым обеспечить более короткие циклы этого внедрения. 

Борис Чупряев, специалист по автоматизированному тестированию, «ТехЛАБ»
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!