testing healthcare applications tips
У прошлом чланку смо направили тежак потез у смислу разумевања домена здравствене заштите. Спремни смо да поново вратимо „шешир тестера“ и сада покушавамо да разумемо како да тестирамо апликације за здравствену заштиту.
=> Ако нисте прочитали 1. део, прочитајте га овде: Како тестирати здравствену заштиту - Увод
Сада ћемо одабрати сваку апликацију / систем и поставити услове које ћемо потврдити у сваком од њих.
Овај чланак је користан за тестере који су већ у домену здравствене заштите или оне који желе да уђу у ово најтоплије поље каријере.
Хајде да почнемо!
Шта ћете научити:
- Тестирање здравствених апликација - узорци сценарија испитивања
- Тестирање система добављача
- Тестирање брокерског система
- Тестирање система чланова
- Тестирање система потраживања
- Тестирање финансијског система
- Тестирање портала за чланове
- Тестирање портала добављача
- Тестирање брокерског портала
- Важни савети за тестирање здравственог софтвера
- Закључак
- Препоручено читање
Тестирање апликација у здравству - Узорак Тест сценарији
Ово су примери сценарија теста за:
Тестирање система добављача
# 1) Систем провајдера треба нам дозволити да уносимо, уређујемо и чувамо податке добављача.
#два) Позитиван проток Тестирање система: укључују сценарије за улазак у различите типове добављача, промену, чување и распитивање о њима.
# 3) Негативан проток Тестирање система: укључују сценарије да
- Сачувајте добављача са непотпуним подацима.
- Сачувајте добављача са датумом важења уговора мањим од датума лиценце за добављача.
- Унесите податке добављача који су већ доступни у систему и сачувајте.
# 4) Испитивање системске интеграције треба да укључује сценарије да
- Потврдите феед за низводне системе као што је феед за систем чланова, портал добављача, систем потраживања и систем финансија.
- Потврдите да ли су промене са портала добављача уграђене у одговарајућу евиденцију добављача.
Тестирање брокерског система
# 1) Брокерски систем треба да буде способан за следеће:
- Унесите, измените и сачувајте податке о посреднику.
- Израчунајте провизију брокера на основу детаља о исплати премије из система члана.
#два) Позитиван проток Тестирање система треба да укључује сценарије за
- Унесите, уредите и сачувајте евиденцију брокера за различите типове брокера.
- Израчунајте провизију за активног брокера тако што ћете створити датотеку феед-а са одговарајућим записом за чланове са другим планом.
# 3) Негативан проток Тестирање система треба да укључује сценарије за
- Унесите евиденцију брокера са недовољним подацима и сачувајте за различите типове брокера.
- Израчунајте провизију за окончаног брокера тако што ћете створити датотеку феед-а са одговарајућим записом за чланове са другим планом
- Израчунајте провизију за неваљаног посредника тако што ћете створити датотеку феед-а са одговарајућим записом за чланове са другим планом
# 4) Тестирање система треба да укључује сценарије да
- Потврдите феедове за низводне системе као што су портал за посредовање, финансијски систем и систем чланова.
- Потврдите да ли су промене на порталу Брокер укључене у одговарајућу евиденцију брокера.
Тестирање система чланова
Систем чланова треба да буде способан за следеће:
алати за тестирање стреса за веб апликацију
- Региструјте, откажите, вратите и поново региструјте члана
- Додајте и уклоните зависну особу
- Генеришите рачун за премију
- Обрадите плаћања премија
Упис: У појединачној полиси, уговарач осигурања додаје се према плану са датумом ступања на снагу од ког ће плаћати премију за бенефиције осигуравача и од којих испуњава услове за подношење потраживања и добијање покрића.
У смерницама групе, члан се додаје у групу (што је већ додато према плану) с датумом ступања на снагу који испуњава услове за подношење захтева и примање покрића.
Прекид: У Индивидуалној полиси, полиса се раскида са датумом раскида чији уговарач осигурања неће бити обухваћен планом осигурања.
У смерницама групе, или само члан може бити раскинут са датумом престанка или цела група може бити раскинута.
Враћање: Ако прекинути члан тражи да полиса поново буде активна, а тренутни датум је унутар грејс периода од датума престанка, члан може да се врати без празнине у покривености. Датум ступања на снагу политике биће исти стари датум ступања на снагу, а не тренутни датум.
Поновни упис: Ако прекинути члан тражи да полиса поново буде активна, а тренутни датум прелази грејс период од датума престанка, члан може бити поново уписан са празнином у покривености. Датум ступања на снагу политике биће тренутни / будући датум и неће бити исти стари датум ступања на снагу.
На пример , Члан је уписан у полису која ступа на снагу 1.1.2013. И престаје 31.12.2013. омогућава нам да узмемо 30 дана грејс периода који је одредила осигуравајућа компанија.
Случај 1: Ако се члан врати 15. јануара 2014 и жели да политика буде ефикасна, онда јесте Поновно успостављање ако члан уплати премију за период 31.12.2013. до 15.1.2014., тада ће датум ступања на снагу полисе бити исти стари 1. 1. 2013.
Случај 2: Ако се члан врати 1.2.2014 и жели да политика поново буде ефикасна, онда је Поновни упис а датум ступања на снагу политике биће 1.2.2014. Овде постоји јаз у покривености (1.1.2014. До 31.1.2014.).
Позитиван проток Тестирање система треба да укључује сценарије за
- Региструјте различите типове чланова са прошлим, тренутним и будућим датумима ступања на снагу.
- Промена и распитивање о члановима.
- Створите премијски рачун за активног члана за следећи месец.
- Отказати активном члану са прошлим, тренутним и будућим датумом престанка важења од датума ступања на снагу.
- Поново упишите члана који је престао са прошлим, тренутним и будућим датумима ступања на снагу.
- Вратити прекинутог члана.
Негативан проток Тестирање система треба да укључује сценарије за
најбољи ддос метод за кућне везе
- Региструјте члана са недовољним подацима.
- Створите рачун за премију за следећег месеца за члана који је прекинут.
Тестирање системске интеграције треба да укључује сценарије да
- Потврдите феед за низводне системе као што су портал за чланове, портал за добављаче, брокерски систем, систем потраживања и систем финансија.
- Потврдите да ли су промене са портала за чланове укључене у одговарајућу евиденцију чланова.
- Обрадите уплату генерираног премијског рачуна помоћу фида са портала за чланове који садржи детаље о извршеном плаћању.
Тестирање система потраживања
Тврдње у здравству имају шифру дијагнозе и шифру поступка да би тврдња била детаљна.
- Дијагностички код: Односи се на болест коју је пацијент имао.
- Законик о поступку: Односи се на третман који се пружа пацијенту.
Систем потраживања треба да буде способан за следеће:
- Унос, уређивање и обрада захтева за члана као и за зависног члана.
- Треба да избаци грешке за неваљане захтеве на основу унетих нетачних података.
Позитиван проток Тестирање система треба да укључује сценарије за унос, уређивање и обраду захтева за члана, као и за зависног члана.
Негативни ток Тестирање система треба да укључује сценарије за
- Унесите и потврдите захтев са неважећим кодом дијагнозе и кодом поступка.
- Унесите и потврдите захтев са неактивним ИД-ом добављача.
- Унесите и потврдите захтев са прекинутим чланом.
Тестирање системске интеграције требало би да укључује сценарије за валидацију феед-а за низводне системе, као што су финансије и портал добављача.
Тестирање финансијског система
Финансијски систем треба да буде способан да уписује зараде и врши ЕФТ плаћања одговарајућем примаоцу обрађивањем извора из различитих узводних система као што су потраживања, члан, добављач и брокерски систем.
Позитиван проток Тестирање система треба да садржи сценарије за проверу да ли је тачна адреса или број рачуна одабран за одговарајућег добављача, члана или брокера за плаћање.
Негативан проток Тестирање система треба да укључује сценарије за
- Проверите да ли се плаћа за неважећи ИД члана, добављача или брокера тако што ћете направити одговарајуће записе у фиду.
- Проверите да ли се уплата врши за неважећи износ (нулти или негативни) за члана, добављача или брокера тако што ћете направити одговарајуће записе у фиду.
Тестирање системске интеграције није потребно, јер ово нема низводне системе, а извори узводно се потврђују у тестирању системске интеграције одговарајућих система.
Тестирање портала за чланове
Члански портал треба да буде способан за следеће:
- Погледајте детаље смерница и статус полагања права.
- Унесите захтеве за промену у детаље смерница.
- Уплатите премију.
Позитиван проток Тестирање система треба да укључује сценарије за
- Пријавите се и погледајте детаље смерница и статус захтева.
- Пошаљите захтев за промену адресе, имена, броја телефона итд.
- Уплатите премију.
Негативан проток Тестирање система треба да укључује сценарије за
- Пријавите се са неважећим акредитивима.
- Уплатите рачун за плаћену премију.
- Уплатите неважећим чеком.
Тестирање системске интеграције није потребно, јер ово нема низводне системе, а извори из узводних система се потврђују у тестирању системске интеграције одговарајућих система.
Тестирање портала добављача
Портал добављача треба да буде способан за следеће:
- Прегледајте детаље о добављачу, детаље о члану и статус захтева.
- Унесите захтеве за промену у детаље добављача.
Позитиван проток Тестирање система треба да укључује сценарије за
- Пријавите се и прегледајте детаље о добављачу, детаље о члану и статус захтева.
- Пошаљите захтев за промену адресе, имена, броја телефона итд.
Негативан проток Тестирање система треба да укључује сценарије за
- Пријавите се са неважећим акредитивима
- Прегледајте детаље о члану са неважећим ИД-ом члана
Тестирање системске интеграције није потребно, јер ово нема низводне системе, а извори из узводног система се потврђују у тестирању системске интеграције одговарајућих система.
Тестирање брокерског портала
Брокерски портал треба да буде способан за следеће:
- Погледајте детаље о брокеру и плаћање провизије.
- Пошаљите захтеве за промену у детаље о брокеру.
Позитиван проток Тестирање система треба да укључује сценарије за
- Пријавите се и погледајте детаље о брокеру и уплату провизије.
- Пошаљите захтев за промену адресе, имена, броја телефона итд.
Негативан проток Тестирање система треба да укључује сценарије за пријављивање са неважећим акредитивима.
Тестирање системске интеграције није потребно, јер ово нема низводне системе, а извори узводно су потврђени у Тестирању системске интеграције одговарајућих система.
То је то - то су сви модули и аспекти које бисмо у њима тестирали.
Важни савети за тестирање здравственог софтвера
Савет бр. 1) Датуми су важни и морају бити тачни, јер незнатна промена датума може проузроковати да се већи недостатак не примети.
Савет бр. 2) У здравству постоје многи параметри испитивања, као што су различите врсте плана, чланови, пружаоци услуга, брокери, начин израчунавања провизије итд., Па треба бити опрезан док дизајнирање тест случајева тако што покрива и не покрива колосек параметара.
Савет бр. 3) Познавање пословних корисника за одговарајуће системе и размишљати из њихове перспективе како би пронашли најбоље недостатке.
најбоље средство за чишћење регистра за Виндовс 7
Савет бр. 4) Није потребно следити исти редослед за тестирање система, а овде дати сценарији само покривају укупну функционалност здравствене апликације. Можда ћете морати да укључите још неколико сценарија (више савета о ово пост) на основу захтева које добијате.
Савет бр. 5) Здравствена заштита се сада креће ка економичном начину пружања неге. Стога су увели модел размене где претплатник може имати увид у планове свих осигуравача, што повећава конкурентну природу осигуравача, чиме индиректно указује на потребу смањења трошкова.
Како се здравствена заштита буде развијала, постојаће потреба за променом софтвера који се користи, а приход за ИТ доноси стварањем, модификовањем и тестирањем укључених софтверских апликација, што значи да можемо предвидети више пројеката у овој домени. Пазите, ако вас ово занима.
Савет бр. 6) Кључ успеха у тестирању апликација за здравствену заштиту су тврдње - потпуно знање о њима и како се пресуђује, итд.
Закључак
Па, то покрива основе домена здравствене заштите и начин за тестирање здравствених апликација.
Као тестери, знамо да ништа није без кварова. Овај чланак може имати и неке недостатке. Ако нађете било какав недостатак или имате питање, оставите коментар. Поздрављамо ваше драгоцене повратне информације о чланку, јер ће нас водити ка изврсности и побољшању.
Желим вам све најбоље за ваше будуће напоре као тестара здравствене заштите. Видимо се!
Препоручено читање
- Како тестирати апликацију за здравствену заштиту - 1. део
- Тест покривеност у тестирању софтвера (савети за максимизирање покривености тестирањем)
- Топ 20 практичних савета за тестирање софтвера које бисте требали прочитати пре тестирања било које апликације
- Како пронаћи грешку у апликацији? Савети и Трикови
- 7 основних савета за тестирање вишејезичних веб локација
- Како тестирати ЈАВА апликације - Савети са примерима тест примера (1. део)
- Инсталирање апликација и припрема за тестирање Аппиум-а
- Разлика између тестирања радне површине, клијентског сервера и веб тестирања