Гра в лікарню або як ми вивчали і тестували роботу системи охорони здоров'я однієї з європейських країн

Стаття «Як впоратися з проблемами в успадкованому проекті після 3 інших команд» розповідає, через що довелося пройти команді розробників, щоб через півтора року одержати досить стабільний програмний продукт.
Тут ми хочемо розповісти, чим займалася команда тестування, щоб ефективно перевіряти всі зміни, внесені розробниками, і гарантувати, що продукт відповідає очікуванням замовників і кінцевих користувачів.
Успадкований продукт без аналітиків, документації, процесів тестування та в цілому кишить багами – справжній виклик для будь-якої команди. І залучення тестувальників до такого продукту було лише справою згоди замовника.
Хочеться зауважити, що вивчення вузьконаправленої бізнес логіки, та ще й для конкретної іноземної держави, може виявитися річчю вельми нетривіальним. На це можна дивитися, як якщо б ви встановили на машину американського інженера – 1С «Бухгалтерії» і попросили б з нею попрацювати, причому саме так, як це роблять росіяни бухгалтера.

1. З чого почати тестировщику, якщо є тільки код.

Перше, що ми зробили, це уважно вивчили всі можливі статті і сайти, присвячені охороні здоров'я. Починаючи з того, які бувають стандарти обміну електронної медичної інформації, і закінчуючи переглядом фотографій госпіталів, де встановлено передане в наші руки. Звичайно, повз нас не пройшли потенційні конкуренти і просто додатку для голосового розшифровки.
Другим етапом знайомства з додатком було тісне спілкування з замовником. Завдяки перепискам і отриманим накиданнях help-документації (4 слайда презентації), нам вдалося виявити кілька критичних моментів:
  • Як відбувається запис (девайси, формати аудіо)
  • Шаблони листів, які формуються з розшифровок, надиктованих лікарями.
  • Ролі користувачів: Доктора, Секретарі, Транскрайберы, Секретарі-редактори (стежать за якістю тексту), відділ друку
  • Список інтеграційних систем
  • Загальний ЖЦ документів
Ці дані стали опорними для подальшої роботи і розставили нам пріоритети у вивченні програми з 400.000 рядків коду. У підсумку ми намалювали таку схему:



2. Саппорт як джерело знань.

До того часу, як ми почали хоч трохи розуміти бізнес-логіку, на голову саппорта падали численні тікети з багами і проблемами у користувачів. Ці тікети стали нашим другим джерелом даних. Подібні програми мають неймовірну кількість особливостей. Наприклад, нам потрібно було ретельно вивчити специфікації для OMR кодів, особливості подвійних імен і прізвищ, шаблони документів і багато іншого. Нам навіть надсилали фотографії з вже роздрукованими листами, щоб ми чітко уявляли, як листи складаються і якого формату іноземні конверти.
Але найбільш корисними були набори налаштувань та конфігурації, які використовуються на реальних серверах. Ситуація була така, що для десяти серверів використовувалися сотні налаштувань, які впливали на бізнес-логіку клієнтського додатку. Разом з розробниками через код вивчали кожну з них і, звичайно ж, документували.

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

Після того, як ми зрозуміли, що простими мікрофонами весь функціонал вікна для запису не протестируешь, ми запросили девайси, якими користуються лікарі.
В основному, це пристрої типу speechmike і DVR, а також педальки для управління аудіо при транскрибировании.


Philips LFH3200/00

DVR Philips DPM8000

Infinity foot control

Ще важливим моментом для ефективного тестування стали емуляції інтеграційних систем.
Ми намагалися мінімізувати «чорні скриньки» у всьому процесі тестування і вивчати, з якими вихідними даними працюють сторонні сервіси. Наприклад, Mirth Connector (інтерфейс для роботи з HL7 повідомленнями), WinDip (система електронної документації), Docman (електронний сервіс для відправки листів). Кожен сервіс має свої формати, і дуже важливо надавати їм правильні дані для подальшої обробки.
Ми спиралися на просте правило: чим ближче до реальності проводяться тести, тим критичніше і важливіше знаходяться баги, а отже, і саме тестування стає більш ефективно.

4. Шукайте лояльних користувачів.

У будь-якого додатка знайдуться користувачі, готові співпрацювати з командою розробки. Ми просили записати всі дії з додатком, а потім вислати нам на аналіз. Разом у нас набралося близько десяти записів, причому від користувачів з різними ролями. Нам вдалося побудувати повну картину роботи з додатком, а також побачити швидкість роботи і проблеми продуктивності. На той момент швидкість роботи програми була жалюгідною, і команді розробки довелося попотіти над оптимізацією.
Отримані відео переводили в тест-кесы, які в подальшому використовувалися для регресійного тестування.

5. End-to-End тестування.

Одним з масштабних тестів для нас стало End-to-End тестування. Воно означало провести повну перевірку програми, починаючи від установки на чисту машину з драйверами для пристроїв і закінчуючи роздрукуванням листів і пакуванням їх у конверт. End-to-end тести дозволили нам чітко зрозуміти, які прогалини в знаннях по системі у нас все ще присутні, яких тестових серверів нам не вистачає і правильне ми маємо уявлення про адмінської частини програми.
Найголовніше було відтворити повну роботу госпіталів, відправку документів на розшифрування, перевірку цих робіт, обробку листів з наступною роздруківкою і пересиланням в різні інтеграційні системи. Ми підбирали найбільш наближені за розмірами тексти, вивчили статистику за розмірами аудіо, подивилися, які види форматування найбільш часто застосовуються в листах. Загалом влаштували справжню рольову гру, залишилося одягнути тільки білі халати.
Звичайно ж, після цього ми відправили наші звіти замовнику, вказавши на найбільш значущі вади програми, а також вказали, яких даних не вистачає для вивчення систем.

6. Разом

Підсумком даної роботи був солідний звіт, що пояснює замовнику, як працює наша система і які в неї є проблеми. Також ми домоглися усвідомленого тестування, доповнивши Jira (Zephyr) і Confluence численними тест-кейсами (понад 1000), чек-листами, специфікаціями і навіть юзер-гайдами (понад 50 статей) для наших замовників.
Але найголовнішим досягненням для нас став той факт, що замовник нам став довіряти як експертам і дуже уважно ставиться до наших порад. Тепер ні одна специфікація не розробляється без нашого статичного тестування, а ми, в свою чергу, дотримуємося контроль, щоб вся документація зберігалася в актуальному стані в нашій вікі.
На закінчення хочеться сказати, що це лише мала частина всіх заходів, які забезпечують якісне, усвідомлене і найголовніше юзер-орієнтоване тестування. Паралельно цим діям відбуваються налагодження процесів тестування всередині команди, розгортання автоматизованого тестування, підбір інструментів, налагодження і стабілізація тестових стендів і багато багато іншого.
Тут же показано, як можна проводити найскладніший етап – «Входження в проект» за мінімальної підтримки з боку замовника, відсутністю аналітиків і з максимальною ефективністю.

Дякую за увагу!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.