Meniu

Testarea aplicațiilor medicale - sfaturi și scenarii importante de testare (partea 2)

testing healthcare applications tips

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

În ultimul articol, am făcut ceva greutate în ceea ce privește înțelegerea domeniului asistenței medicale. Suntem gata să ne punem din nou „pălăria de tester” și acum încercăm să înțelegem cum să testăm aplicațiile de îngrijire a sănătății.

=> Dacă nu ați citit partea 1, vă rugăm să o citiți aici: Cum se testează aplicația pentru îngrijirea sănătății - Introducere

Acum vom alege fiecare aplicație / sistem și vom veni cu condiții pe care le vom valida în fiecare dintre ele.

Acest articol este util pentru testerii care se află deja în domeniul asistenței medicale sau pentru cei care doresc să intre în acest domeniu de carieră.

Testarea aplicațiilor medicale

Să începem!

Ce veți învăța:

Testarea aplicațiilor medicale - Probă Testează scenarii

Acesta este exemplul de scenarii de testare pentru:

Sistem de asigurări de sănătate - Componente de testare

Testarea sistemului furnizorului

# 1) Sistemul furnizor ar trebui să ne permită să introducem, să edităm și să salvăm datele furnizorului.

#Două) Flux pozitiv Testarea sistemului: includeți scenarii pentru a introduce diferite tipuri de furnizori, a modifica, a salva și a întreba despre ei.

# 3) Flux negativ Testarea sistemului: include scenarii pentru

  • Salvați un furnizor cu date incomplete.
  • Salvați un furnizor cu o dată de intrare în vigoare a contractului mai mică decât data licenței furnizorului.
  • Introduceți datele furnizorului care sunt deja disponibile în sistem și salvați.

# 4) Testarea integrării sistemului ar trebui să includă scenarii pentru

  • Validați alimentarea către sistemele din aval, cum ar fi alimentarea către sistemul membru, portalul furnizorului, sistemul de revendicare și sistemul financiar.
  • Validați dacă modificările din portalul furnizorului sunt încorporate în înregistrarea furnizorului respectiv.

Testarea sistemului de broker

# 1) Sistemul de broker ar trebui să fie capabil de următoarele:

  • Introduceți, editați și salvați datele brokerului.
  • Calculați comisionul brokerului pe baza detaliilor de plată premium din sistemul membru.

#Două) Flux pozitiv Testarea sistemului ar trebui să includă scenarii pentru

  • Introduceți, editați și salvați înregistrarea brokerului pentru diferite tipuri de broker.
  • Calculați comisionul pentru brokerul activ prin crearea unui fișier feed cu înregistrarea respectivă pentru membrii cu un plan diferit.

# 3) Flux negativ Testarea sistemului ar trebui să includă scenarii pentru

  • Introduceți o înregistrare de broker cu date insuficiente și salvați pentru diferite tipuri de broker.
  • Calculați comisionul pentru brokerul desființat prin crearea unui fișier feed cu înregistrarea respectivă pentru membrii cu un plan diferit
  • Calculați comisionul pentru brokerul nevalid prin crearea unui fișier feed cu înregistrarea respectivă pentru membrii cu un plan diferit

# 4) Testarea sistemului ar trebui să includă scenarii pentru

  • Validați fluxurile către sistemele din aval, cum ar fi portalul brokerilor, sistemul financiar și sistemul membru.
  • Validați dacă modificările din portalul Brokerului sunt încorporate în evidența brokerului respectiv.

Testarea sistemului membru

Sistemul membru ar trebui să fie capabil de următoarele:

care este cheia dvs. de securitate a rețelei
  1. Înscrieți, revocați, restabiliți și reînscrieți un membru
  2. Adăugați și eliminați un dependent
  3. Generați factură premium
  4. Procesați plăți de primă

Înscriere: Într-o poliță individuală, un asigurat este adăugat în cadrul unui plan cu o dată efectivă de la care va plăti o primă pentru beneficiile oferite de asigurător și de la care este eligibil pentru depunerea daunelor și pentru a primi acoperire.

În Politica de grup, un membru este adăugat la grup (care este deja adăugat în cadrul unui plan) cu o dată efectivă pentru care este eligibil pentru depunerea cererilor și pentru a primi acoperire.

Reziliere: Într-o poliță individuală, polița este reziliată cu o dată de reziliere a cărei asigurat nu va fi acoperit de planul de asigurare.

În politica de grup, fie singurul membru poate fi reziliat cu o dată de reziliere, fie întregul grup poate fi reziliat.

Reintegrare: Dacă un membru reziliat solicită ca polița să fie din nou activă, iar data curentă se încadrează în perioada de grație de la data rezilierii, atunci membrul poate fi reintegrat fără o lacună în acoperire. Data efectivă a politicii va fi aceeași dată efectivă veche și nu data curentă.

Reînscriere: Dacă un membru reziliat cere ca polița să fie din nou activă și data curentă depășește perioada de grație de la data rezilierii, atunci membrul poate fi reînscris cu un decalaj de acoperire. Data efectivă a politicii va fi data curentă / viitoare și nu va fi aceeași dată efectivă veche.

De exemplu , Un membru este înscris într-o poliță cu o dată efectivă la 01.01.2013 și încetată la 31.12.2013. ne permite să luăm 30 de zile ca perioada de grație stabilită de compania de asigurări.

Cazul 1: Dacă membrul se întoarce la 15.01.2014 și dorește ca politica să fie eficientă, atunci este Reintegrare dacă membrul plătește prima pentru perioada 31.12.2013 - 15.01.2014, atunci data intrării în vigoare a poliței va fi aceeași veche 01.01.2013.

Cazul 2: Dacă membrul revine pe 01.02.2014 și dorește ca politica să fie din nou eficientă, atunci este Reînscriere iar data intrării în vigoare a politicii va fi 01.02.2014. Aici există un decalaj în acoperire (01.01.2014 - 31.01.2014).

Flux pozitiv Testarea sistemului ar trebui să includă scenarii pentru

  • Înscrieți diferite tipuri de membri cu date efective trecute, actuale și viitoare.
  • Schimbați și întrebați despre membri.
  • Generați o factură premium pentru un membru activ pentru luna viitoare.
  • Încheiați un membru activ cu data de reziliere trecută, actuală și viitoare mai mare decât data efectivă.
  • Reînscrieți un membru reziliat cu datele efective trecute, actuale și viitoare.
  • Restabiliți un membru reziliat.

Flux negativ Testarea sistemului ar trebui să includă scenarii pentru

  • Înscrieți un membru cu date insuficiente.
  • Generați o factură premium pentru luna viitoare pentru un membru reziliat.

Testarea integrării sistemului ar trebui să includă scenarii pentru

  • Validați fluxul către sistemele din aval, cum ar fi portalul membrilor, portalul furnizorului, sistemul de broker, sistemul de revendicare și sistemul de finanțare.
  • Validați dacă modificările din portalul pentru membri sunt încorporate în înregistrarea respectivă a membrilor.
  • Procesați plata unei facturi premium generate cu fluxul de pe portalul membrilor care are detalii despre plată efectuate.

Testarea sistemului de creanțe

Revendicările din asistența medicală au cod de diagnostic și cod de procedură pentru ca reclamația să fie detaliată.

  • Cod de diagnostic: Se referă la boala pe care a avut-o pacientul.
  • Cod procedură: Se referă la tratamentul oferit pacientului.

Sistemul de creanțe ar trebui să fie capabil de următoarele:

  • Introduceți, editați și procesați revendicările pentru membru, precum și pentru un dependent.
  • Ar trebui să arunce erori pentru revendicările nevalide pe baza datelor incorecte introduse.

Flux pozitiv Testarea sistemului ar trebui să includă scenarii pentru introducerea, editarea și procesarea revendicărilor pentru membru, precum și pentru un dependent.

Flux negativ Testarea sistemului ar trebui să includă scenarii pentru

  • Introduceți și validați o reclamație cu cod de diagnostic și cod de procedură nevalide.
  • Introduceți și validați o revendicare cu un ID de furnizor inactiv.
  • Introduceți și validați o revendicare cu un membru reziliat.

Testarea integrării sistemului ar trebui să includă scenarii pentru validarea fluxului către sistemele din aval, cum ar fi finanțarea și portalul furnizorilor.

Testarea sistemului financiar

Sistemul financiar ar trebui să fie capabil să scrie salarii și să efectueze plăți prin TEF către destinatarul respectiv prin procesarea fluxurilor din diferite sisteme din amonte, cum ar fi creanțele, membrul, furnizorul și sistemul de broker.

Flux pozitiv Testarea sistemului ar trebui să includă scenarii pentru a verifica dacă adresa corectă sau numărul de cont este ales pentru furnizorul, membrul sau brokerul respectiv pentru plată.

Flux negativ Testarea sistemului ar trebui să includă scenarii pentru

cel mai bun downloader mp3 pentru telefoane Android
  • Verificați dacă plata se face pentru ID-ul de membru, furnizor sau broker nevalid prin crearea înregistrărilor respective în flux.
  • Verificați dacă plata se face pentru suma nevalidă (zero sau negativă) pentru membru, furnizor sau broker prin crearea înregistrărilor respective în flux.

Testarea integrării sistemului nu este necesară, deoarece nu are niciun sistem din aval, iar fluxurile din amonte sunt validate în testarea integrării sistemului a sistemelor respective.

Testarea portalului membrilor

Portalul membrilor ar trebui să fie capabil de următoarele:

  • Vedeți detaliile politicii și starea revendicării.
  • Faceți cereri de modificare în detaliile politicii.
  • Efectuați plăți de primă.

Flux pozitiv Testarea sistemului ar trebui să includă scenarii pentru

  • Conectați-vă și vizualizați detaliile politicii și starea revendicării.
  • Faceți cerere de modificare pentru a schimba adresa, numele, numărul de telefon etc.
  • Efectuați plăți de primă.

Flux negativ Testarea sistemului ar trebui să includă scenarii pentru

  • Conectați-vă cu acreditări nevalide.
  • Efectuați plata pentru o factură premium plătită.
  • Efectuați plata cu un cec nevalid.

Testarea integrării sistemului nu este necesară, deoarece aceasta nu are niciun sistem din aval, iar fluxurile din sistemele din amonte sunt validate în testarea integrării sistemului a sistemelor respective.

cel mai bun Windows 10 anti spyware gratuit

Testarea portalului furnizorului

Portalul furnizorului ar trebui să fie capabil de următoarele:

  • Vizualizați detaliile furnizorului, detaliile membrilor și starea revendicării.
  • Faceți cereri de modificare în detaliile furnizorului.

Flux pozitiv Testarea sistemului ar trebui să includă scenarii pentru

  • Conectați-vă și vizualizați detaliile furnizorului, detaliile membrilor și starea revendicării.
  • Faceți cerere de modificare pentru a schimba adresa, numele, numărul de telefon etc.

Flux negativ Testarea sistemului ar trebui să includă scenarii pentru

  • Conectați-vă cu acreditări nevalide
  • Vizualizați detaliile de membru cu un ID de membru nevalid

Testarea integrării sistemului nu este necesară, deoarece aceasta nu are niciun sistem din aval, iar fluxurile din sistemul din amonte sunt validate în testarea integrării sistemului a sistemelor respective.

Testarea portalului brokerilor

Portalul brokerilor trebuie să fie capabil de următoarele:

  • Vedeți detaliile brokerului și plata comisioanelor.
  • Faceți cereri de modificare în detaliile brokerului.

Flux pozitiv Testarea sistemului ar trebui să includă scenarii pentru

  • Conectați-vă și vizualizați detaliile brokerului și plata comisioanelor.
  • Faceți cerere de modificare pentru a schimba adresa, numele, numărul de telefon etc.

Flux negativ Testarea sistemului ar trebui să includă scenarii de autentificare cu acreditări nevalide.

Testarea integrării sistemului nu este necesară, deoarece aceasta nu are sisteme din aval, iar fluxurile din amonte sunt validate în testarea integrării sistemului a sistemelor respective.

Asta e - asta sunt toate modulele și aspectele pe care le-am testa în ele.

Sfaturi importante pentru testarea software-ului medical

Sfatul nr. 1) Datele sunt importante și trebuie să fie corecte, deoarece o ușoară modificare a datei poate determina nerespectarea unui defect major.

Sfatul nr. 2) În asistența medicală, există mulți parametri de testare, cum ar fi diferite tipuri de planuri, membri, furnizori, brokeri, metoda de calcul a comisioanelor etc. - deci trebuie să aveți grijă în timp ce proiectarea de cazuri de testare având o urmărire a parametrilor acoperiți și neacoperiți.

Sfatul nr. 3) Cunoașteți utilizatorii de afaceri pentru sistemele respective și gândiți din perspectiva lor pentru a găsi cele mai bune defecte.

Sfatul nr. 4) Nu este necesar să urmați aceeași ordine pentru testarea sistemului și scenariile furnizate aici acoperă doar funcționalitatea generală a unei aplicații de asistență medicală. Poate fi necesar să mai includeți câteva scenarii (mai multe sugestii la acest post) pe baza cerințelor pe care le primiți.

Sfatul nr. 5) Asistența medicală se îndreaptă acum către un mod rentabil de a oferi îngrijire. Astfel, au introdus un model de schimb în care abonatul poate avea o viziune asupra planurilor oferite de toți asigurătorii, ceea ce sporește caracterul competitiv al asigurătorilor, declarând astfel indirect nevoia de reducere a costurilor.

Pe măsură ce asistența medicală evoluează, va fi nevoie de schimbarea software-ului utilizat și vor veni veniturile pentru IT prin crearea, modificarea și testarea aplicațiilor software implicate - ceea ce înseamnă că putem anticipa mai multe proiecte în acest domeniu. Așadar, păstrați o privire, dacă acest lucru vă interesează.

Sfatul nr. 6) Cheia succesului în testarea aplicațiilor de îngrijire a sănătății este revendicările - cunoașterea completă a acestora și modul în care sunt judecate etc.

Concluzie

Ei bine, aceasta acoperă elementele de bază ale domeniului asistenței medicale și o modalitate de testare a aplicațiilor medicale.

În calitate de testeri, știm că nimic nu are defecte. Acest articol poate avea și unele defecte, dacă găsiți vreun defect sau aveți o întrebare, vă rugăm să lăsați un comentariu. Salutăm feedback-ul dvs. valoros cu privire la articol, deoarece ne va conduce spre excelență și îmbunătățire.

Vă doresc tot ce este mai bun pentru eforturile viitoare în calitate de tester medical. Ne mai vedem!

Lectură recomandată

^