Больничная Игра Или Как Мы Изучали И Тестировали Систему Здравоохранения Одной Из Европейских Стран

Роли пользователей: Врачи, Секретари, Расшифровщики, Секретари-редакторы (следят за качеством текста), полиграфический отдел.

Список систем интеграции Общий жизненный цикл документов Эти данные стали основой для дальнейшей работы и определили для нас приоритеты в изучении приложения с 400 000 строк кода.

В результате мы нарисовали следующую схему:



2. Поддержка как источник знаний.

К тому моменту, когда мы начали хоть немного разбираться в бизнес-логике, на голову службы поддержки посыпались многочисленные тикеты с багами и проблемами от пользователей.

Эти билеты стали нашим вторым источником данных.

Такие приложения обладают невероятным количеством возможностей.

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

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

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

Ситуация была такова, что десять серверов использовали сотни настроек, которые влияли на бизнес-логику клиентского приложения.

Вместе с разработчиками мы изучили каждый из них через код и, конечно же, задокументировали.

3. Все должно быть максимально приближено к реальности.

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

В основном это такие устройства, как речевой микрофон и видеорегистратор, а также педали для управления звуком во время транскрипции.

Филипс LFH3200/00



Видеорегистратор Philips DPM8000



Ножное управление «Бесконечность» Эмуляция систем интеграции стала еще одним важным моментом для эффективного тестирования.

Мы постарались свести к минимуму «черные ящики» во всем процессе тестирования и изучить, с какими входными данными работают сторонние сервисы.

Например, Mirth Connector (интерфейс для работы с сообщениями HL7), WinDip (система электронной документации), Docman (электронный сервис для отправки писем).

Каждый сервис имеет свои форматы, и очень важно предоставить им правильные данные для дальнейшей обработки.

Мы опирались на простое правило: чем ближе к реальности проводятся тесты, тем более критичными и важными являются ошибки, а значит и само тестирование становится более эффективным.

4. Ищите лояльных пользователей.

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

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

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

Нам удалось построить полную картину того, как работает приложение, а также увидеть скорость работы и проблемы с производительностью.

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

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

5. Сквозное тестирование.

Одним из масштабных тестов для нас было End-to-End тестирование.

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

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

Мы выбрали наиболее близкие по размеру тексты, изучили статистику размеров аудио и посмотрели, какие виды форматирования чаще всего используются в письмах.

В общем, устроили настоящую ролевую игру, оставалось только надеть белые халаты.

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

6. Итого Результатом этой работы стал солидный отчет, объясняющий заказчику, как работает наша система и какие в ней есть проблемы.

Мы также добились осознанного тестирования, дополнив Jira (Zephyr) и Confluence многочисленными тест-кейсами (более 1000), чек-листами, спецификациями и даже руководствами пользователя (более 50 статей) для наших клиентов.

Но самым главным достижением для нас стало то, что заказчик начал доверять нам как экспертам и очень внимательно относился к нашим советам.

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

В заключение хотелось бы сказать, что это лишь малая часть всех мер, обеспечивающих качественное, информированное и, самое главное, ориентированное на пользователя тестирование.

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

Также показано, как можно осуществить самый сложный этап — «Вход в проект» с минимальной поддержкой со стороны заказчика, отсутствием аналитиков и с максимальной эффективностью.