Меню

Тестування програм охорони здоров’я - Поради та важливі сценарії тестування (Частина 2)

testing healthcare applications tips

Спробуйте Наш Інструмент Для Усунення Проблем

В останній статті ми зробили важку справу з точки зору розуміння сфери охорони здоров’я. Ми готові знову надіти наш «капелюх тестувальника», а тепер спробуємо зрозуміти, як перевірити програми охорони здоров’я.

=> Якщо ви не читали частину 1, будь ласка, прочитайте її тут: Як перевірити заявку на охорону здоров’я - Вступ

Зараз ми збираємось вибрати кожну програму / систему та висунути умови, які ми будемо перевіряти в кожній із них.

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

Тестування програм охорони здоров’я

Давайте розпочнемо!

Що ви дізнаєтесь:

Тестування заявок на охорону здоров'я - Зразок Тестові сценарії

Це зразки сценаріїв випробувань для:

Система медичного страхування - компоненти тестування

Тестування системи постачальника

# 1) Система провайдера повинна мати можливість вводити, редагувати та зберігати дані провайдера.

# два) Позитивний потік Тестування системи: включати сценарії введення різних типів Постачальників, зміни, збереження та запитування про них.

# 3) Негативний потік Тестування системи: включити сценарії до

  • Збережіть постачальника з неповними даними.
  • Збережіть постачальника з датою набуття контракту, меншою за дату ліцензії постачальника.
  • Введіть дані провайдера, які вже доступні в системі, та збережіть.

# 4) Тестування системної інтеграції повинні включати сценарії для

  • Перевірте подачу до нижчих систем, таких як подача до системи-члена, порталу постачальника, системи вимог та системи фінансів.
  • Перевірте, чи зміни з порталу постачальника включені у відповідний запис постачальника.

Тестування брокерської системи

# 1) Брокерська система повинна мати такі можливості:

  • Вводити, редагувати та зберігати дані брокера.
  • Розрахуйте комісію брокера, виходячи з реквізитів оплати премій із системи-члена.

# два) Позитивний потік Тестування системи повинно включати сценарії для

  • Введіть, відредагуйте та збережіть запис брокера для різних типів брокера.
  • Розрахуйте комісію для активного брокера, створивши файл фіду з відповідним записом для членів з іншим планом.

# 3) Негативний потік Тестування системи повинно включати сценарії для

  • Введіть запис брокера з недостатньою кількістю даних та збережіть для різних типів брокера.
  • Розрахуйте комісію для брокера, який припинив свою діяльність, створивши файл фіду з відповідним записом для членів з іншим планом
  • Розрахуйте комісію для недійсного брокера, створивши файл фіду з відповідним записом для членів з іншим планом

# 4) Тестування системи повинні включати сценарії для

  • Перевірте канали для нижчих систем, таких як портал брокерів, система фінансів та система членів.
  • Перевірте, чи зміни з порталу Брокер включені у відповідний запис брокера.

Тестування системи членів

Система-член повинна мати такі можливості:

яка фаза впровадження в sdlc?
  1. Зареєструйте, припиніть, відновіть і повторно зареєструйте учасника
  2. Додавання та видалення залежного
  3. Сформувати рахунок за премією
  4. Обробляйте виплати премій

Реєстрація: В Індивідуальному полісі страхувальник додається за планом із датою набрання чинності, з якої він / вона буде платити премію за виплати, надані страховиком, і з якої він / вона має право подавати претензії та отримувати покриття.

У груповій політиці член додається до групи (яка вже додана за планом) з датою набрання чинності, з якої він / вона має право подавати претензії та отримувати покриття.

Припинення: В Індивідуальному полісі поліс припиняється з датою припинення дії, страхувальник якої не охоплюється страховим планом.

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

Відновлення: Якщо учасник, який припинив свою діяльність, просить політику знову активуватись, а поточна дата перебуває у межах пільгового періоду з дати припинення, член може бути відновлений без розриву в охопленні. Датою набрання чинності полісом буде однакова стара дата набрання чинності, а не поточна дата.

Повторна реєстрація: Якщо учасник, який припинив свою діяльність, просить політику знову активуватись, а поточна дата перевищує пільговий період з дати припинення, член може бути повторно зареєстрований із розривом у покритті. Датою набрання чинності політикою буде поточна / майбутня дата, а не однакова стара дата набрання чинності.

як боротися з певними ситуаціями

Наприклад , Член зареєстрований у полісі з датою набрання чинності 1/1/2013 та припинено 31.12.2013. дозволяє взяти 30 днів як пільговий період, встановлений страховою компанією.

Випадок 1: Якщо член повернеться 15.01.2014 і хоче, щоб політика була ефективною, тоді це так Відновлення якщо учасник сплачує премію за період з 31.12.2013 р. по 15.01.2014 р., то датою набрання чинності полісу буде така сама стара старіша 01.01.2013 р.

Випадок 2: Якщо учасник повернеться 01.02.2014 і хоче, щоб політика знову стала ефективною, тоді це так Повторне зарахування а датою набрання чинності політики буде 01.02.2014. Тут існує розрив у охопленні (з 01.01.2014 по 31.01.2014).

Позитивний потік Тестування системи повинно включати сценарії для

  • Зареєструйте різні типи учасників із датою набрання чинності в минулому, поточному та майбутньому.
  • Змінюйтесь і цікавіться про учасників.
  • Створіть рахунок на премію для активного учасника на наступний місяць.
  • Припинити активного учасника з минулою, поточною та майбутньою датою припинення, більшою за дату набрання чинності.
  • Повторно зареєструйте учасника, який припинив свою діяльність, із минулими, поточними та майбутніми датами набрання чинності.
  • Поновити учасника, який припинив свою діяльність.

Негативний потік Тестування системи повинно включати сценарії для

  • Зареєструйте учасника з недостатньою кількістю даних.
  • Створіть рахунок за премію на наступний місяць для учасника, який припинив свою діяльність.

Тестування системної інтеграції повинні включати сценарії для

  • Перевірте подачу до нижчих систем, таких як портал учасників, портал постачальників, брокерська система, система вимог та система фінансів.
  • Перевірте, чи зміни на порталі учасників включені у відповідний запис учасника.
  • Обробляйте оплату згенерованого преміум-рахунку за допомогою стрічки з порталу-учасника, де є деталі сплаченого платежу.

Тестування системи претензій

Претензії в галузі охорони здоров’я мають код діагностики та код процедури, щоб заява була детальною.

  • Код діагностики: Посилається на хворобу, яку мав пацієнт.
  • Процедурний кодекс: Відноситься до лікування, яке надається пацієнту.

Система розгляду претензій повинна мати таке:

  • Вводити, редагувати та обробляти претензії до учасника, а також до залежного.
  • Якщо виникають помилки щодо недійсних претензій на основі введених неправильних даних.

Позитивний потік Системне тестування повинно включати сценарії введення, редагування та обробки заявок для учасника, а також для залежного.

Негативний потік Тестування системи повинно включати сценарії для

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

Тестування системної інтеграції повинно включати сценарії перевірки каналу для нижчих систем, таких як фінанси та портал постачальників.

Тестування фінансової системи

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

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

Негативний потік Тестування системи повинно включати сценарії для

  • Перевірте, чи здійснюється платіж за недійсного члена, постачальника або брокера, створивши відповідні записи у стрічці.
  • Перевірте, чи здійснено оплату за недійсну суму (нульову чи від’ємну) для учасника, провайдера чи брокера, створивши відповідні записи у стрічці.

Тестування системної інтеграції не потрібне, оскільки в ньому відсутні будь-які попередні системи, а канали вищого рівня перевіряються під час тестування системної інтеграції відповідних систем.

Тестування порталу учасників

Портал учасників повинен мати таке:

  • Перегляньте деталі політики та статус претензії.
  • Вносити запити на зміни в деталях політики.
  • Здійснюйте преміальні платежі.

Позитивний потік Тестування системи повинно включати сценарії для

  • Увійдіть і перегляньте деталі політики та статус претензії.
  • Зробіть запит на зміну, щоб змінити адресу, ім’я, номер телефону тощо.
  • Здійснюйте преміальні платежі.

Негативний потік Тестування системи повинно включати сценарії для

  • Увійдіть із недійсними обліковими даними.
  • Здійснити оплату за рахунок сплаченої премії.
  • Здійснюйте оплату за допомогою недійсного чека.

Тестування системної інтеграції не потрібне, оскільки в ньому відсутні будь-які попередні системи, а канали вихідних систем перевіряються при тестуванні системної інтеграції відповідних систем.

Тестування порталу постачальників

Портал постачальників повинен мати таке:

  • Перегляньте деталі постачальника, дані учасника та статус претензії.
  • Робіть запити на зміну в даних про постачальника

Позитивний потік Тестування системи повинно включати сценарії для

  • Увійдіть і перегляньте деталі постачальника, дані учасника та статус претензії.
  • Зробіть запит на зміну, щоб змінити адресу, ім’я, номер телефону тощо.

Негативний потік Тестування системи повинно включати сценарії для

  • Увійти з недійсними обліковими даними
  • Перегляньте деталі учасника з недійсним ідентифікатором учасника

Тестування системної інтеграції не потрібне, оскільки в ньому відсутні будь-які попередні системи, а канали вихідної системи перевіряються при тестуванні системної інтеграції відповідних систем.

Тестування брокерського порталу

Брокерський портал повинен мати таке:

  • Переглянути деталі брокера та оплату комісії.
  • Вносити запити на зміну в деталях брокера.

Позитивний потік Тестування системи повинно включати сценарії для

  • Увійдіть і перегляньте деталі брокера та оплату комісії.
  • Зробіть запит на зміну, щоб змінити адресу, ім’я, номер телефону тощо.

Негативний потік Тестування системи повинно включати сценарії входу з недійсними обліковими даними.

як запрограмувати комп'ютер для початківців -

Тестування системної інтеграції не потрібне, оскільки в ньому відсутні будь-які попередні системи, а канали вищого рівня перевіряються у Тестуванні системної інтеграції відповідних систем.

Ось і все - це всі модулі та аспекти, які ми б у них перевірили.

Важливі поради щодо тестування програмного забезпечення для охорони здоров’я

Порада No1) Дати важливі і повинні бути точними, оскільки незначна зміна дати може призвести до того, що великий дефект не буде помічений.

Порада No2) В охороні здоров’я існує безліч параметрів тестування, таких як різні типи плану, учасники, провайдери, брокери, метод розрахунку комісії тощо, - тому слід бути обережним, проектування тестових кейсів шляхом охоплення і не охоплення доріжки параметрів.

Порада No3) Знати бізнес-користувачів відповідних систем та мислити з їхньої точки зору знайти найкращі дефекти.

Порада No4) Не потрібно дотримуватися того самого порядку тестування системи, а наведені тут сценарії просто охоплюють загальну функціональність програми охорони здоров’я. Можливо, вам доведеться включити ще кілька сценаріїв (більше підказок щодо це пост) на основі вимог, які ви отримуєте.

Порада No5) Зараз охорона здоров’я рухається до економічно ефективного способу надання допомоги. Таким чином, вони запровадили модель обміну, за якою абонент може бачити плани всіх страховиків, що підвищує конкурентний характер страховиків, тим самим опосередковано заявляючи про необхідність зменшення витрат.

У міру розвитку охорони здоров’я виникне потреба у зміні програмного забезпечення, яке використовується, і приходить дохід для ІТ шляхом створення, модифікації та тестування програмних програм, що беруть участь, - що означає, що ми можемо передбачити більше проектів у цій галузі. Тож стежте за тим, якщо це вас цікавить.

Порада No6) Запорукою успіху в тестуванні заявок на охорону здоров’я є претензії - їхнє повне знання та спосіб їх винесення тощо.

Висновок

Ну, це охоплює основи сфери охорони здоров’я та спосіб тестування медичних програм.

Як тестувальники, ми знаємо, що ніщо не містить дефектів. Ця стаття також може мати деякі дефекти. Якщо ви виявите дефект або маєте запитання, залиште коментар. Ми вітаємо ваш цінний відгук про статтю, оскільки він підштовхне нас до вдосконалення та вдосконалення.

Бажаю вам усього найкращого у ваших майбутніх починаннях як тестера охорони здоров’я. Побачимося!

Рекомендована література

^