Meni

Testiranje zdravstvenih aplikacija - Savjeti i važni scenariji ispitivanja (2. dio)

testing healthcare applications tips

Isprobajte Naš Instrument Za Uklanjanje Problema

U prošlom članku učinili smo težak posao u smislu razumijevanja domene zdravstvene zaštite. Spremni smo vratiti svoj 'šešir testera' i sada pokušavamo razumjeti kako testirati zdravstvene programe.

=> Ako niste pročitali 1. dio, pročitajte ga ovdje: Kako testirati zdravstvenu zaštitu - Uvod

Sada ćemo odabrati svaku aplikaciju / sustav i postaviti uvjete koje ćemo provjeriti u svakom od njih.

Ovaj je članak koristan za testere koji su već u domeni Healthcare ili one koji žele ući u ovo najtoplije polje karijere.

Testiranje aplikacija u zdravstvu

Započnimo!

Što ćete naučiti:

Ispitivanje primjene u zdravstvu - Uzorak Testni scenariji

Ovo su uzorci scenarija ispitivanja za:

Sustav zdravstvenog osiguranja - dijelovi ispitivanja

Testiranje sustava davatelja

# 1) Sustav davatelja usluga trebao bi nam dopustiti unos, uređivanje i spremanje podataka davatelja usluga.

#dva) Pozitivan protok Ispitivanje sustava: uključuju scenarije za ulazak u različite vrste pružatelja usluga, promjenu, spremanje i raspitivanje o njima.

# 3) Negativan protok Ispitivanje sustava: uključuju scenarije za

  • Spremite davatelja usluga s nepotpunim podacima.
  • Spremite davatelja usluga s datumom stupanja na snagu ugovora manjim od datuma licence davatelja usluge.
  • Unesite podatke dobavljača koji su već dostupni u sustavu i spremite.

# 4) Ispitivanje integracije sustava treba uključivati ​​scenarije za

  • Potvrdite feed za nizvodne sustave kao što su feed za sustav članova, portal pružatelja, sustav potraživanja i sustav financija.
  • Potvrdite jesu li promjene s portala davatelja ugrađene u odgovarajući zapis davatelja.

Testiranje brokerskog sustava

# 1) Brokerski sustav trebao bi biti sposoban za sljedeće:

  • Unesite, uredite i spremite podatke o posredniku.
  • Izračunajte proviziju brokera na temelju detalja o plaćanju premije iz sustava člana.

#dva) Pozitivan protok Testiranje sustava mora uključivati ​​scenarije za

  • Unesite, uredite i spremite evidenciju brokera za različite vrste brokera.
  • Izračunajte proviziju za aktivnog posrednika tako što ćete stvoriti datoteku feeda s odgovarajućim zapisom za članove s drugim planom.

# 3) Negativan protok Testiranje sustava mora uključivati ​​scenarije za

  • Unesite evidenciju brokera s nedovoljnim podacima i spremite za različite vrste brokera.
  • Izračunajte proviziju za otkazanog brokera tako što ćete stvoriti datoteku feeda s odgovarajućim zapisom za članove s drugim planom
  • Izračunajte proviziju za nevaljanog posrednika tako što ćete stvoriti datoteku feeda s odgovarajućim zapisom za članove s drugim planom

# 4) Ispitivanje sustava treba uključivati ​​scenarije za

  • Potvrdite feedove za nizvodne sustave kao što su portal za posredovanje, sustav financija i sustav članova.
  • Potvrdite jesu li promjene s portala Broker uključene u odgovarajući zapis o brokeru.

Testiranje sustava članova

Sustav članova trebao bi biti sposoban za sljedeće:

softver za preuzimanje videozapisa s vaše cijevi
  1. Registrirajte, prekinite, vratite i ponovo upišite člana
  2. Dodajte i uklonite zavisnu osobu
  3. Generirajte račun za premiju
  4. Obradite isplate premija

Upis: U Individualnoj polisi, osiguranik se dodaje prema planu s datumom stupanja na snagu od kojeg će on / ona plaćati premiju za beneficije osiguravatelja i od kojih ispunjava uvjete za podnošenje šteta i pokriće.

U politici grupe, član se dodaje u grupu (što je već dodano prema planu) s datumom stupanja na snagu koji ispunjava uvjete za podnošenje zahtjeva i primanje pokrića.

Prestanak: U Pojedinačnoj polici, polica se ukida s datumom raskida čiji ugovaratelj osiguranja neće biti obuhvaćen planom osiguranja.

U pravilima grupe, ili samo član može biti raskinut s datumom prestanka ili cijela grupa.

Vraćanje: Ako prekinuti član zatraži da politika ponovno bude aktivna, a trenutni datum je unutar počeka od datuma prestanka, član se može vratiti bez praznine u pokrivenosti. Datum stupanja na snagu politike bit će isti stari datum stupanja na snagu, a ne trenutni datum.

Ponovni upis: Ako prekinuti član zatraži da politika ponovno bude aktivna, a trenutni datum premašuje poček od datuma prestanka, član se može ponovno prijaviti s prazninom u pokrivanju. Datum stupanja na snagu politike bit će trenutni / budući datum i neće biti isti stari datum stupanja na snagu.

Na primjer , Član je upisan u polisu s datumom stupanja na snagu 1.1.2013. I ukinut 31. 12. 2013. omogućuje nam da uzmemo 30 dana kao poček koji je utvrdilo osiguravajuće društvo.

Slučaj 1: Ako se član vrati 15.1.2014. I želi da politika bude učinkovita, onda je Ponovno uspostavljanje ako član plati premiju za razdoblje od 31.12.2013. do 15.1.2014., tada će datum stupanja na snagu police biti isti stari 1.1.2013.

Slučaj 2: Ako se član vrati 1.2.2014. I želi da politika ponovno stupi na snagu, onda je Ponovni upis a datum stupanja na snagu politike bit će 1.2.2014. Ovdje postoji jaz u pokrivenosti (1.1.2014. Do 31.1.2014.).

Pozitivan protok Testiranje sustava mora uključivati ​​scenarije za

  • Upišite različite vrste članova s ​​prošlim, trenutnim i budućim datumima stupanja na snagu.
  • Promijenite i raspitajte se o članovima.
  • Stvorite premijski račun za aktivnog člana za sljedeći mjesec.
  • Prekinuti aktivnog člana s prošlim, trenutnim i budućim datumom prestanka dužim od datuma stupanja na snagu.
  • Ponovno upišite prekinutog člana s prošlim, trenutnim i budućim datumima stupanja na snagu.
  • Vratite prekinutog člana.

Negativan protok Testiranje sustava mora uključivati ​​scenarije za

  • Registrirajte člana s nedovoljno podataka.
  • Stvorite račun za premiju za sljedećeg mjeseca za prekinutog člana.

Ispitivanje integracije sustava treba uključivati ​​scenarije za

  • Provjerite feed za nizvodne sustave poput portala za članove, portala za davatelje, brokerskog sustava, sustava potraživanja i sustava financija.
  • Potvrdite jesu li promjene s portala za članove ugrađene u odgovarajući zapis člana.
  • Obradite plaćanje generiranog premijskog računa sa feedom s portala za članove koji sadrži detalje o izvršenom plaćanju.

Testiranje sustava potraživanja

Tvrdnje u zdravstvu imaju dijagnostički kod i šifru postupka da bi zahtjev bio detaljan.

  • Dijagnostički kod: Odnosi se na bolest koju je pacijent imao.
  • Zakonik o postupku: Odnosi se na liječenje koje se pruža pacijentu.

Sustav potraživanja trebao bi biti sposoban za sljedeće:

  • Unesite, uredite i obradite zahtjeve za člana kao i za uzdržavanog člana.
  • Trebali bi izbaciti pogreške za nevaljane zahtjeve na temelju unesenih netočnih podataka.

Pozitivan protok Testiranje sustava treba uključivati ​​scenarije za unos, uređivanje i obradu zahtjeva za člana, kao i za ovisnog člana.

Negativan protok Testiranje sustava mora uključivati ​​scenarije za

  • Unesite i potvrdite zahtjev s neispravnim kodom dijagnoze i kodom postupka.
  • Unesite i potvrdite zahtjev s neaktivnim ID-om davatelja usluge.
  • Unesite i potvrdite zahtjev s prekinutim članom.

Testiranje integracije sustava trebalo bi obuhvaćati scenarije za provjeru valjanosti feed-a za nizvodne sustave kao što su financije i portal pružatelja usluga.

Testiranje financijskog sustava

Financijski sustav trebao bi biti sposoban za upisivanje plaća i izvršavanje EFT plaćanja odgovarajućem primatelju obrađivanjem feedova iz različitih uzvodnih sustava kao što su potraživanja, član, davatelj i brokerski sustav.

Pozitivan protok Testiranje sustava treba uključivati ​​scenarije za provjeru je li odabrana ispravna adresa ili broj računa za određenog davatelja usluga, člana ili brokera za plaćanje.

Negativan protok Testiranje sustava mora uključivati ​​scenarije za

  • Provjerite je li plaćanje izvršeno za nevaljani ID člana, davatelja usluge ili brokera stvaranjem odgovarajućih zapisa u feedu.
  • Provjerite je li plaćanje izvršeno za nevažeći iznos (nulti ili negativni) za člana, davatelja usluga ili brokera stvaranjem odgovarajućih zapisa u feedu.

Testiranje integracije sustava nije potrebno jer ovo ne sadrži nizvodne sustave, a izvori uzvodno se provjeravaju u testiranju integracije sustava odgovarajućih sustava.

koji je najbolji youtube u mp3 pretvarač

Testiranje portala za članove

Članski portal trebao bi biti sposoban za sljedeće:

  • Pogledajte detalje pravila i status zahtjeva.
  • Unesite zahtjeve za promjenu u pojedinostima pravila.
  • Uplatite premije.

Pozitivan protok Testiranje sustava mora uključivati ​​scenarije za

  • Prijavite se i pregledajte detalje pravila i status zahtjeva.
  • Pošaljite zahtjev za promjenu adrese, imena, telefonskog broja itd.
  • Uplatite premije.

Negativan protok Testiranje sustava mora uključivati ​​scenarije za

  • Prijavite se s nevažećim vjerodajnicama.
  • Uplatite račun za plaćenu premiju.
  • Uplatite nevažećim čekom.

Testiranje integracije sustava nije potrebno jer ovo ne sadrži nizvodne sustave, a izvori iz uzvodnih sustava provjeravaju se u testiranju integracije sustava pojedinih sustava.

Testiranje portala davatelja

Portal pružatelja usluga trebao bi biti sposoban za sljedeće:

kako pokrenuti povezani popis u javi -
  • Pregledajte pojedinosti davatelja usluga, podatke o članu i status zahtjeva.
  • Unesite zahtjeve za promjenu u pojedinostima davatelja usluge.

Pozitivan protok Testiranje sustava mora uključivati ​​scenarije za

  • Prijavite se i pregledajte pojedinosti davatelja usluga, podatke o članu i status zahtjeva.
  • Pošaljite zahtjev za promjenu adrese, imena, telefonskog broja itd.

Negativan protok Testiranje sustava mora uključivati ​​scenarije za

  • Prijava s nevažećim vjerodajnicama
  • Pregledajte detalje o članu s nevažećim ID-om člana

Testiranje integracije sustava nije potrebno jer ovo nema nizvodne sustave, a izvori iz uzvodnog sustava provjeravaju se u testiranju integracije sustava odgovarajućih sustava.

Testiranje brokerskog portala

Brokerski portal trebao bi biti sposoban za sljedeće:

  • Pogledajte detalje o brokeru i plaćanje provizije.
  • Pošaljite zahtjeve za promjenu u detalje o brokeru.

Pozitivan protok Testiranje sustava mora uključivati ​​scenarije za

  • Prijavite se i pregledajte detalje o brokeru i plaćanju provizije.
  • Pošaljite zahtjev za promjenu adrese, imena, telefonskog broja itd.

Negativan protok Testiranje sustava mora uključivati ​​scenarije za prijavu s nevažećim vjerodajnicama.

Testiranje integracije sustava nije potrebno jer ovo ne sadrži nizvodne sustave, a izvori uzvodno su provjereni u Testiranju integracije sustava pojedinih sustava.

To je to - to su svi moduli i aspekti koje bismo u njima testirali.

Važni savjeti za testiranje zdravstvenog softvera

Savjet br. 1) Datumi su važni i moraju biti točni jer neznatna promjena datuma može uzrokovati da se veći nedostatak ne primijeti.

Savjet br. 2) U zdravstvu postoje mnogi parametri ispitivanja kao što su različite vrste plana, članovi, pružatelji usluga, brokeri, metoda izračuna provizije itd., Pa treba biti oprezan dok dizajniranje test slučajeva tako što pokriva i ne pokriva trag parametara.

Savjet br. 3) Poznavati poslovne korisnike za pojedine sustave i razmišljati iz njihove perspektive pronaći najbolje nedostatke.

Savjet br. 4) Nije potrebno slijediti isti redoslijed za testiranje sustava, a ovdje dani scenariji samo pokrivaju cjelokupnu funkcionalnost zdravstvene aplikacije. Možda ćete također trebati uključiti još nekoliko scenarija (više savjeta o ovaj post) na temelju zahtjeva koje primite.

Savjet br. 5) Zdravstvena zaštita sada se kreće prema isplativom načinu pružanja njege. Stoga su uveli model razmjene u kojem pretplatnik može imati uvid u planove svih osiguravatelja, što povećava konkurentsku prirodu osiguravatelja, čime neizravno ukazuje na potrebu smanjenja troškova.

Kako se zdravstvo bude razvijalo, bit će potrebna promjena softvera koji se koristi, a prihod za IT donosi stvaranjem, modificiranjem i testiranjem uključenih softverskih aplikacija, što znači da možemo predvidjeti više projekata u ovoj domeni. Pazite, ako vas ovo zanima.

Savjet br. 6) Ključ uspjeha u testiranju zdravstvenih zahtjeva su tvrdnje - potpuno znanje o njima i kako se presuđuje, itd.

Zaključak

Pa, to pokriva osnove zdravstvene domene i način testiranja zdravstvenih aplikacija.

Kao testeri, znamo da ništa nije bez nedostataka. Ovaj članak može imati i neke nedostatke. Ako nađete bilo kakav nedostatak ili imate pitanje, ostavite komentar. Pozdravljamo vaše dragocjene povratne informacije o članku jer će nas voditi prema izvrsnosti i poboljšanju.

Želim vam sve najbolje za vaše buduće napore kao testara zdravstvene zaštite. Vidimo se oko!

Preporučena literatura

^