Борис Чупряев, специалист по автоматизированному тестированию ООО “ТехЛАБ”, рассказал “Икс Медия” об особенностях тестирования медицинского ПО.
Создавая программные продукты для здравоохранения, мы, как и многие, ориентируемся на ведущие практики. Работаем по гибким итеративным методологиям, когда за этапом разработки следует тестирование, а по его результатам может быть запущен новый цикл разработки – и все это сводится в единый непрерывный поток.
Моральный аспект, экспертиза и персональные данные
Пожалуй, первая «болевая точка» тестировщика медицинского ПО – это повышенная ответственность за результат своего труда. Наши информационные системы предоставляют врачам различные инструменты, облегчающие принятие решений: расчет дозировки препаратов, назначение той или иной терапии. Но они не принимают эти решения за врача. Последнее слово всегда остается за специалистом, и в ближайшее время в этом плане вряд ли что-либо изменится. Поэтому, с одной стороны, разработчик медицинского софта формально не отвечает за врачебное решение, но с другой – обязан сделать все возможное, чтобы информационная система не давала сбоев и приносила только пользу.
Вторая особенность тестирования медицинского ПО – большой объем персональных данных, подлежащих обработке и хранению. Кроме того, здесь мы сталкиваемся с данными, составляющими врачебную тайну: они требуют повышенного уровня защиты. Если специалисты по информационной безопасности выявляют общие, очевидные сценарии утечек, то отдел тестирования должен также проверить отсутствие критических ошибок в коде, в бизнес-логике.
В наших решениях мы физически разделяем хранилища персональных и клинических данных. Таким образом, управление доступом и обработка персональных данных пациента и его клинических данных – это разные процессы. И при тестировании мы проверяем, в частности, возможность запросить данные из базы в обход авторизации.
Третья особенность – специфический контент медицинских сервисов: например, карточки пациентов с результатами анализов и осмотров, диагнозами и предлагаемыми видами терапии. Все эти факторы, которые взаимно влияют друг на друга, не позволяют при разработке софта тестировать его формально, используя некие условные параметры. Приходится углубляться в предметную область, выявлять взаимосвязи между параметрами.
В наших решениях нам нередко приходится корректно преобразовывать в цифровую форму и обрабатывать контент, который сгенерирован специалистами отрасли здравоохранения. Мы работаем с нормативной документацией и клиническими рекомендациями Минздрава, Российского общества клинической онкологии, зарубежными источниками. Для этого мы привлекаем собственных медицинских экспертов и врачей медорганизаций-партнеров. Тестировщики в процессе написания тестов выбирают несколько максимально широких сценариев, а медицинский эксперт объясняет, какие существуют входные данные и что необходимо получить на выходе.
Наконец, четвертая особенность нашей работы – ориентация на пользователей медицинских сервисов. На мой взгляд, разработчик любой информационной системы должен учитывать в первую очередь именно их интересы. Тестировщику нужно вжиться в роль конечного пользователя и выдать необычные сценарии, которые потом трансформируются в тестовые. Например, мы можем представить себе очень занятого профессора или неопытного пользователя, который не разбирается в компьютерах и для которого любые новые решения только усложняют жизнь, и провести UX-тестирование. Возможно, результатом станет изменение интерфейса, логики, уменьшение количества кликов до целевой страницы. Другой пример: врач, который долгое время заполняет карточку пациента. Конечно, он может не знать о такой опасности, как «протухание» интернет-сессии, грозящее потерей всех введенных данных, – и мы должны добавить в систему функцию автосохранения. Таким образом, иногда мы вынуждены отходить от принципа атомарных тестов и исследовать длинные пользовательские сценарии, большие пласты бизнес-логики.
Ручной труд или зачет автоматом?
В публикациях наших коллег часто можно встретить утверждение, что полностью автоматизировать процесс тестирования программного обеспечения невозможно. Во многом это утверждение справедливо: например, чтобы написать сценарий для автоматизации, сначала его необходимо «прогнать» вручную. То же самое касается тестирования контента, когда мы привлекаем экспертов: база для теста формируется вручную.
С другой стороны, при хорошо выстроенном процессе автоматизация может исключить тестировщика из рутинных процессов, а обработать данные автотеста сможет любой участник разработки. В идеале мы способны даже тестировать изменение кода конкретного разработчика до того, как он внес его в общую кодовую базу. Но в первую очередь, конечно же, мы стараемся автоматизировать регрессионное тестирование: исследование той части программы, которая не подвергается активным изменениям.
Подводя итог, отмечу, что проблемы автоматизации тестирования сегодня кроются не в технологиях, а в методологии: насколько она будет дорогой и трудозатратной. Ее необходимость зависит от отрасли применения, сроков, имеющихся ресурсов. В последнее время автоматизированное тестирование стало более выгодным, поскольку им управлять легче, чем командой тестировщиков. Кроме того, на определенном этапе мы можем встроить его в процесс непрерывного внедрения (continuous integration) и тем самым обеспечить более короткие циклы этого внедрения.
Подробнее на IKSMEDIA.RU
