Почему 200 OK в медицинском ПО может быть опаснее ошибки: опыт тестировщика БАРС Груп

В медицинском программном обеспечении (ПО) за каждым назначением, статусом госпитализации или результатом анализа стоит реальный пациент. Система может вернуть HTTP-статус 200 OK, сохранить запись и не показать ни одного сбоя, но медицинский процесс при этом не завершится: назначение останется в неверном случае лечения, лаборатория не получит заявку, или врач увидит старый статус. Такие дефекты не останавливают работу, а позволяют продолжить её с неверными данными, что особенно опасно.

Статья опубликована в блоге компании «БАРС Груп» на Хабре. Её автор — Ольга Ришко, старший специалист по тестированию медицинской информационной системы (МИС) «БАРС Груп». Она делится опытом выявления скрытых дефектов, которые не видны при проверке отдельных экранов и API-методов.

Одна кнопка — несколько процессов

Простой сценарий — врач назначает лабораторное исследование и нажимает «Сохранить». Для пользователя это одно действие, но внутри системы оно может включать цепочку: проверку полей и прав, создание назначения, изменение статуса документа, формирование задания для лаборатории, отправку события в интеграционную шину, обновление списков на экране и запись в историю изменений. Часть шагов выполняется в одной транзакции, часть — отдельными сервисами, часть — уходит в очередь и завершается позже. У модулей могут быть разные владельцы данных, свои правила обработки и журналы. Добавив кэш, несколько открытых вкладок и внешнюю лабораторную систему, получаем типичную архитектуру большой МИС.

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

Четыре способа получить «успешную» операцию с неверным результатом

1. Данные сохранились не в том контексте

У одного пациента могут одновременно существовать разные эпизоды лечения: амбулаторное обращение, госпитализация, дневной стационар. Назначение связано с карточкой пациента, конкретным случаем, подразделением, врачом и этапом помощи. Если интерфейс переключился на госпитализацию, а вложенный блок продолжил использовать идентификатор амбулаторного случая, запись создастся и будет валидной для базы. В результате есть факт формирования направления, получение результатов, запись в БД, запрос возвращает 200 OK, логи в порядке, но сотрудники стационара не увидят запись в своём рабочем списке, так как система считает, что пациент был в поликлинике.

2. Основная запись обновилась, а связанные данные — нет

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

3. Интерфейс показывает старое состояние

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

4. Зависимая операция упала, но пользователь об этом не узнал

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

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

Что на самом деле означает 200 OK

HTTP-статус 200 OK сообщает, что конкретный запрос был принят и обработан без явной ошибки на уровне протокола. Это полезный факт, но он не отвечает на более важные вопросы: завершились ли фоновые действия, обновились ли зависимые объекты, увидел ли результат следующий участник процесса и соответствует ли итог бизнес-правилам.

В тестировании МИС 200 OK воспринимается как промежуточная точка. После него начинается проверка результата: что записалось, с какими связями, какой статус увидят другие роли и можно ли продолжить сценарий до ожидаемого конца. Иногда API дополнительно возвращает бизнес-статус или идентификаторы созданных объектов, но это не отменяет сквозную проверку.

Роль ручного тестирования

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

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

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

Как локализовать расхождение

Процесс поиска места, где сценарий разошёлся, включает несколько шагов:

• повторение сценария на интерфейсе и фиксация момента расхождения;
• просмотр в DevTools запроса, полезной нагрузки, ответа и последующих обращений экрана;
• при необходимости повторение запроса через Postman для отделения поведения API от состояния интерфейса;
• сверка в БД статуса назначения, связи с заданием и времени изменений;
• поиск в логах и/или журнале историй запросов события и результата его обработки;
• проверка рабочего места лаборатории для понимания, какое состояние дошло до следующего участника процесса.

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

Чек-лист не умеет задавать вопросы

Чек-листы, тест-кейсы, дымовое и регрессионное тестирование остаются основой работы. Но формальный сценарий чаще всего описывает ожидаемый путь: открыть, заполнить, сохранить, проверить статус. Риск возникает между этими шагами или после них. К готовому тест-кейсу добавляются вопросы, которых может не быть в требованиях: что считается завершением операции для пользователя, а не только для API; как система обозначает частично выполненный процесс; какие данные увидит другая роль; что произойдёт при задержке или недоступности зависимости; не подменяет ли интерфейс неопределённое состояние словом «успешно».

Что изменил опыт работы с МИС

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

1. Ни интерфейс, ни API, ни запись в базе сами по себе не доказывают, что сценарий завершён корректно.
2. Чем тише дефект, тем важнее проверить последствия. Явная ошибка останавливает пользователя, скрытая позволяет ему идти дальше.
3. Ручное тестирование особенно ценно там, где нужно сопоставить технический результат с реальным действием врача, регистратора, лаборатории или другого участника процесса.

Качество медицинской системы живёт на стыке интерфейса, данных, фоновых процессов, интеграций и человеческого решения. Поэтому 200 OK — не финал проверки, а всего лишь подтверждение, что один шаг не упал.

Что это значит

Статья Ольги Ришко демонстрирует, что в медицинских информационных системах формальный успех операции (200 OK) не гарантирует корректного завершения клинического сценария. Скрытые дефекты на стыках модулей, при асинхронных вызовах или из-за кэширования могут приводить к расхождению данных, которое не видно ни пользователю, ни системе мониторинга. Ручное тестирование, ориентированное на сквозные сценарии и граничные условия, остаётся необходимым инструментом для выявления таких проблем.