Меню

Тестване на приложения за здравеопазване - съвети и важни сценарии за тестване (част 2)

testing healthcare applications tips

Опитайте Нашия Инструмент За Премахване На Проблемите

В последната статия направихме няколко тежки стъпки по отношение на разбирането на областта на здравеопазването. Готови сме да сложим отново „шапката на тестера“ и сега се опитаме да разберем как да тестваме приложенията за здравеопазване.

=> Ако не сте прочели част 1, моля, прочетете я тук: Как да тествате приложението за здравни грижи - Въведение

Сега ще изберем всяко приложение / система и ще изготвим условия, които ще валидираме във всяка една от тях.

Тази статия е полезна за тестерите, които вече са в домейна на здравеопазването, или тези, които искат да влязат в това най-горещо поле за кариера.

Тестване на приложения за здравеопазване

Да започваме!

Какво ще научите:

Тестване на приложения в здравеопазването - Проба Тестови сценарии

Това са примерни тестови сценарии за:

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

Тестване на системата на доставчика

# 1) Системата на доставчика трябва да ни позволи да въвеждаме, редактираме и запазваме данни на доставчика.

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

# 3) Отрицателен поток Тестване на системата: включва сценарии за

  • Запазете доставчик с непълни данни.
  • Запазете доставчик с дата на влизане в сила на договора, по-малка от датата на лиценза на доставчика.
  • Въведете данни на доставчика, които вече са налични в системата, и запазете.

# 4) Тестване на системната интеграция трябва да включва сценарии за

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

Тестване на брокерска система

# 1) Брокерската система трябва да е способна на следното:

  • Въведете, редактирайте и запазете данните на брокера.
  • Изчислете комисионната на брокера въз основа на данните за плащане на премията от системата-член.

# две) Положителен поток Системното тестване трябва да включва сценарии за

  • Въведете, редактирайте и запазете записа на брокер за различни видове брокер.
  • Изчислете комисионната за активния брокер, като създадете файл за емисия със съответния запис за членове с различен план.

# 3) Отрицателен поток Системното тестване трябва да включва сценарии за

  • Въведете запис на брокер с недостатъчно данни и запазете за различни видове брокер.
  • Изчислете комисионната за прекратения брокер, като създадете файл с емисия със съответния запис за членове с различен план
  • Изчислете комисионната за невалидния брокер, като създадете файл за емисия със съответния запис за членове с различен план

# 4) Тестване на системата трябва да включва сценарии за

  • Проверете емисиите към системите надолу по веригата, като портала за брокери, финансовата система и системата за членове.
  • Проверете дали промените от портала за брокер са включени в съответния запис на брокер.

Тестване на членска система

Системата за членове трябва да има следните възможности:

най-добрият софтуер за почистване за Windows 7
  1. Регистрирайте, прекратете, възстановете и повторно регистрирайте член
  2. Добавете и премахнете зависим
  3. Генериране на сметка за премия
  4. Обработвайте плащания на премии

Записване: В Индивидуална полица притежателят на полица се добавя по план с влязла в сила дата, от която той / тя ще плаща премия за обезщетенията, осигурени от застрахователя и от която той / тя има право да подава искове и да получи покритие.

В груповата политика член се добавя към групата (която вече е добавена по план) с датата на влизане в сила, на която той / тя отговаря на условията за подаване на искове и получаване на покритие.

Прекратяване на договора: В Индивидуална полица полицата се прекратява с дата на прекратяване, на която притежателят на полица няма да бъде покрит от застрахователния план.

В груповите правила или самият член може да бъде прекратен с дата на прекратяване, или цялата група може да бъде прекратена.

Възстановяване: Ако прекратен член поиска политиката да бъде активна отново и текущата дата е в рамките на гратисния период от датата на прекратяване, тогава членът може да бъде възстановен без пропуск в покритието. Датата на влизане в сила на политиката ще бъде същата стара дата на влизане в сила, а не текущата дата.

Повторно записване: Ако прекратен член поиска политиката да бъде активна отново и текущата дата е след гратисния период от датата на прекратяване, тогава членът може да бъде повторно записан с пропуск в покритието. Датата на влизане в сила на политиката ще бъде текущата / бъдещата дата, а не същата стара дата на влизане в сила.

Например , Членът е записан в полица с дата на влизане в сила от 01.01.2013 г. и прекратен на 31.12.2013 г. ни позволява да вземем 30 дни като гратисен период, определен от застрахователната компания.

Случай 1: Ако членът се върне на 15.01.2014 г. и иска политиката да бъде ефективна, тогава е така Възстановяване ако членът плати премията за периода 31.12.2013 г. до 15.1.2014 г., тогава датата на влизане в сила на политиката ще бъде същата стара 1/1/2013.

Случай 2: Ако членът се върне на 1.2.2014 г. и иска политиката да бъде ефективна отново, тогава е така Презаписване и датата на влизане в сила на политиката ще бъде 1/2/2014. Тук има разлика в покритието (от 1.01.2014 г. до 31.01.2014 г.).

Положителен поток Системното тестване трябва да включва сценарии за

  • Запишете различни типове членове с минали, настоящи и бъдещи дати на влизане в сила.
  • Промяна и запитване за членовете.
  • Генерирайте премиум сметка за активен член за следващия месец.
  • Прекратяване на активен член с минала, настояща и бъдеща дата на прекратяване, по-голяма от датата на влизане в сила.
  • Презапишете прекратен член с минали, настоящи и бъдещи дати на влизане в сила.
  • Възстановете прекратен член.

Отрицателен поток Системното тестване трябва да включва сценарии за

c ++ грешка неопределена препратка към
  • Запишете член с недостатъчно данни.
  • Генерирайте сметка за премия за следващия месец за прекратен член.

Тестване на системната интеграция трябва да включва сценарии за

  • Проверете емисията към системи надолу по веригата, като портал за членове, портал за доставчици, брокерска система, система за вземания и финансова система.
  • Проверете дали промените от портала за членове са включени в съответния запис на членове.
  • Обработете плащането на генерирана премиална сметка с емисията от портала за членове, която съдържа подробности за извършеното плащане.

Тестване на система за искове

Исковете в здравеопазването имат диагнозен код и процедурен код, за да бъде искът подробен.

  • Код за диагностика: Отнася се за заболяването, което пациентът е имал.
  • Процедурен кодекс: Отнася се за лечението, предоставяно на пациента.

Системата за искове трябва да може да:

  • Въвеждайте, редактирайте и обработвайте искове за член, както и за зависим.
  • Трябва да изхвърля грешки за невалидни искове въз основа на неправилно въведените данни.

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

Отрицателен поток Системното тестване трябва да включва сценарии за

  • Въведете и потвърдете иск с невалиден диагностичен код и код на процедурата.
  • Въведете и потвърдете иск с неактивен идентификатор на доставчик.
  • Въведете и потвърдете иск с прекратен член.

Тестването на системна интеграция трябва да включва сценарии за валидиране на емисията към системи надолу по веригата, като например портал за финанси и доставчик.

Тестване на финансова система

Финансовата система трябва да бъде способна да записва заплати и да извършва плащания по електронен трансфер на съответния получател чрез обработка на емисиите от различни системи нагоре по веригата, като искове, член, доставчик и брокерска система.

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

Отрицателен поток Системното тестване трябва да включва сценарии за

  • Проверете дали плащането е извършено за невалиден идентификатор на член, доставчик или брокер, като създадете съответни записи в емисията.
  • Проверете дали плащането е извършено за невалидната сума (нула или отрицателна) за члена, доставчика или брокера, като създадете съответни записи в емисията.

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

Тестване на портал за членове

Порталът за членове трябва да може да:

  • Преглеждайте подробности за правилата и състояние на искането.
  • Направете заявки за промяна в подробности за политиката.
  • Извършвайте премиум плащания.

Положителен поток Системното тестване трябва да включва сценарии за

  • Влезте и прегледайте подробности за политиката и статус на искането.
  • Направете заявка за промяна, за да промените адрес, име, телефонен номер и др.
  • Извършвайте премиум плащания.

Отрицателен поток Системното тестване трябва да включва сценарии за

  • Влезте с невалидни идентификационни данни.
  • Направете плащане за платена сметка за премия.
  • Извършете плащане с невалиден чек.

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

Тестване на портала на доставчика

Порталът за доставчици трябва да може да:

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

Положителен поток Системното тестване трябва да включва сценарии за

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

Отрицателен поток Системното тестване трябва да включва сценарии за

  • Влезте с невалидни идентификационни данни
  • Преглеждайте подробности за члена с невалиден идентификатор на член

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

Тестване на брокерския портал

Брокерският портал трябва да е способен на следното:

  • Вижте подробности за брокера и плащане на комисионна.
  • Направете заявки за промяна в подробности за брокера.

Положителен поток Системното тестване трябва да включва сценарии за

  • Влезте и вижте подробности за брокера и плащане на комисионна.
  • Направете заявка за промяна, за да промените адрес, име, телефонен номер и др.

Отрицателен поток Системното тестване трябва да включва сценарии за влизане с невалидни идентификационни данни.

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

Това е всичко - това са всички модули и аспектите, които бихме тествали в тях.

Важни съвети за тестване на здравен софтуер

Съвет # 1) Датите са важни и трябва да са точни, защото малка промяна в датата може да доведе до незабелязване на голям дефект.

Съвет # 2) В здравеопазването има много тестови параметри като различни видове план, членове, доставчици, брокери, метод за изчисляване на комисионни и т.н., така че трябва да се внимава, докато проектиране на тестови случаи като има обхванати и непокрити следи от параметри.

Съвет # 3) Познайте бизнес потребителите за съответните системи и мислете от тяхна гледна точка за да намерите най-добрите дефекти.

кое е най-доброто приложение за виртуална реалност

Съвет # 4) Не е необходимо да се следва същият ред за системно тестване и предоставените тук сценарии просто обхващат цялостната функционалност на приложение за здравеопазване. Може да се наложи да включите още няколко сценария (повече намеци за това пост) въз основа на изискванията, които получавате.

Съвет # 5) Сега здравните грижи се насочват към икономически ефективен начин за предоставяне на грижи. По този начин те въведоха модел на обмен, при който абонатът може да има оглед на плановете, дадени от всички застрахователи, което увеличава конкурентния характер на застрахователите, като по този начин индиректно посочва необходимостта от намаляване на разходите.

С развитието на здравеопазването ще има нужда от промяна в използвания софтуер и идва доходът за ИТ чрез създаване, модифициране и тестване на участващите софтуерни приложения - което означава, че можем да очакваме повече проекти в тази област. Така че, внимавайте, ако това ви интересува.

Съвет # 6) Ключът към успеха в тестването на приложения за здравни грижи са исковете - пълното познаване на тях и как те се произнасят и т.н.

Заключение

Е, това обхваща основите на здравеопазването и начин за тестване на приложенията в здравеопазването.

Като тестери знаем, че нищо не е без дефекти. Тази статия може да има и някои дефекти, ако откриете някакъв дефект или имате въпрос, моля оставете коментар. Приветстваме ценната ви обратна връзка за статията, тъй като тя ще ни насочи към върхови постижения и подобрения.

Желая ви всичко най-добро за бъдещите ви начинания като тестер за здравеопазване. Ще се видим!

Препоръчително четене

^